[noise] rev34 status

[Katriel Cohn-Gordon]

Relatedly, is there an expected relationship between the rows in the
security properties table for a protocol and its deferred version?

On Mon, 18 Jun 2018, at 10:13 AM, jake mcginty 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180618/314df6ce/attachment.html>