[noise] rev34 status

[Justin Cormack]

There is a logic to them. It might be a nice exercise to make a tool
to generate them, and formalize the rules.

Roughly I think it is:
1. Send e if you have not done this yet
2. Perform ee if possible
3. Perform es, se if possible and not deferred
4. Perform ss if possible, unless es and se already performed
5. If doing X, send s if ee has been sent
6. If doing I, send s

So for NK1, the send e and perform ee rules get priority over the es,
while for XX1 es should be done due to 3, it was just deferred but the
data is available and this takes priority over sending s.

The rationale is
a. ephemerals first to get forward secrecy, encryption early
b. DH as soon as possible, ie when you have keys, unless moved to to deferral
c. X requires s is encrypted, I sends anyway regardless.
d. ss is redundant after es, se

Justin


On 18 June 2018 at 10:13, jake mcginty <me at jake.su> wrote:
> On the new deferred patterns: although an appendix is included with the
> exact patterns definitions, the spec itself is unspecific about how deferred
> patterns are generated from the fundamentals.
>
> It doesn't strictly define where the authenticating DH operations are moved
> to from their original position, and the appendix patterns don't seem to
> follow a consistent pattern (ex: XX1 *prepends* the "es" token to the next
> message, whereas NK1 *appends* the "es" token to the next message).
>
> Is this intentional and implementers are expected to hardcode these new
> patterns?
>
> On Jun 13, 2018, at 1:42 AM, Trevor Perrin <trevp at trevp.net> wrote:
>
>
> Hi all,
>
> Quick status update for the Noise spec revision 34:
>
> Noise Explorer is finishing an updated analysis, sounds like we'll get it
> this week.  If everything checks out, I'll publish the spec afterwards.
>
> Thus it's a great time to do last-minute proof-reading, if anyone's so
> inclined.  There's a change log, so you can focus on the parts that were
> updated (or look at diffs):
>
> https://github.com/noiseprotocol/noise_spec/tree/rev34
> https://github.com/noiseprotocol/noise_spec/blob/rev34/output/noise.pdf
>
>
> Trevor
>
>
> On Tue, May 29, 2018 at 2:18 AM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>> I updated revision 34 draft with:
>>
>>  * Security properties for deferred patterns in appendix, taken from
>> Noise Explorer.
>>
>>  * Renamed "authentication" / "confidentiality" security properties in
>> spec to "source" / "destination", since the Noise Explorer team
>> pointed out these categories don't map directly to the previous terms.
>>
>>  * In section 10, clarified the distinction between "switch protocols"
>> (a protocol that Bob switches to) and "fallback protocols" (a protocol
>> that uses the fallback modifier).
>>
>>  * In section 10, removed some of the description of a "type byte";
>> and generalized/renamed the "Type fields" discussion in "Application
>> responsibilities" to discuss "Negotiation data".
>>
>>  * Added X1N pattern (which I forgot somehow; so needs to be added to
>> Noise Explorer too).
>>
>>
>> For the first two points, I'd like to follow-up with Noise Explorer
>> team and see whether they agree with how the spec presents these
>> properties.  In particular, do they still want 2 additional
>> categories? [1].
>>
>> For the next 2 points:  we don't want to put NoiseSocket/NLS stuff in
>> this spec, but I think exploring those things has improved our
>> understanding of how to build things around Noise, so reflecting that
>> better understanding in this spec makes sense.
>>
>> We could use proof-reading of the security properties table, that's a
>> lot for me to transcribe from Noise Explorer..
>>
>> Other comments?
>>
>> I keep saying this, but hopefully we can publish this week.
>>
>>
>> https://github.com/noiseprotocol/noise_spec/tree/rev34
>> https://github.com/noiseprotocol/noise_spec/blob/rev34/output/noise.pdf
>>
>>
>> Trevor
>>
>> [1] https://github.com/noiseprotocol/noise_spec/tree/rev34
>
>
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
>
>
>
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
>