[noise] rev34 status

[Trevor Perrin]

The properties should be the same before the line where the
authentication token is moved.  And they should end up the same.

There might be something smarter you could say, but those were the
quick things I looked for as a sanity-check.

Trevor


On Mon, Jun 18, 2018 at 9:22 AM, Katriel Cohn-Gordon <me at katriel.co.uk> wrote:
> 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
>
>
>
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
>