<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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).<div class=""><div class=""><div class=""><div><br class=""></div><div>Is this intentional and implementers are expected to hardcode these new patterns?</div><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 13, 2018, at 1:42 AM, Trevor Perrin <<a href="mailto:trevp@trevp.net" class="">trevp@trevp.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Hi all,</div><div class=""><br class=""></div>Quick status update for the Noise spec revision 34:<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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):</div><div class=""><br class=""></div><div class=""><div class=""><div class=""><a href="https://github.com/noiseprotocol/noise_spec/tree/rev34" class="">https://github.com/noiseprotocol/noise_spec/tree/rev34</a></div><div class=""><a href="https://github.com/noiseprotocol/noise_spec/blob/rev34/output/noise.pdf" class="">https://github.com/noiseprotocol/noise_spec/blob/rev34/output/noise.pdf</a></div></div><div class=""><br class=""></div></div><div class=""><br class=""></div><div class="">Trevor</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, May 29, 2018 at 2:18 AM, Trevor Perrin <span dir="ltr" class=""><<a href="mailto:trevp@trevp.net" target="_blank" class="">trevp@trevp.net</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I updated revision 34 draft with:<br class=""> <br class=""> * Security properties for deferred patterns in appendix, taken from<br class=""> Noise Explorer.<br class=""> <br class=""> * Renamed "authentication" / "confidentiality" security properties in<br class=""> spec to "source" / "destination", since the Noise Explorer team<br class=""> pointed out these categories don't map directly to the previous terms.<br class=""> <br class=""> * In section 10, clarified the distinction between "switch protocols"<br class=""> (a protocol that Bob switches to) and "fallback protocols" (a protocol<br class=""> that uses the fallback modifier).<br class=""> <br class=""> * In section 10, removed some of the description of a "type byte";<br class=""> and generalized/renamed the "Type fields" discussion in "Application<br class=""> responsibilities" to discuss "Negotiation data".<br class=""> <br class=""> * Added X1N pattern (which I forgot somehow; so needs to be added to<br class=""> Noise Explorer too).<br class=""> <br class=""> <br class=""> For the first two points, I'd like to follow-up with Noise Explorer<br class=""> team and see whether they agree with how the spec presents these<br class=""> properties. In particular, do they still want 2 additional<br class=""> categories? [1].<br class=""> <br class=""> For the next 2 points: we don't want to put NoiseSocket/NLS stuff in<br class=""> this spec, but I think exploring those things has improved our<br class=""> understanding of how to build things around Noise, so reflecting that<br class=""> better understanding in this spec makes sense.<br class=""> <br class=""> We could use proof-reading of the security properties table, that's a<br class=""> lot for me to transcribe from Noise Explorer..<br class=""> <br class=""> Other comments?<br class=""> <br class=""> I keep saying this, but hopefully we can publish this week.<br class=""> <br class=""> <br class=""> <a href="https://github.com/noiseprotocol/noise_spec/tree/rev34" rel="noreferrer" target="_blank" class="">https://github.com/<wbr class="">noiseprotocol/noise_spec/tree/<wbr class="">rev34</a><br class=""> <a href="https://github.com/noiseprotocol/noise_spec/blob/rev34/output/noise.pdf" rel="noreferrer" target="_blank" class="">https://github.com/<wbr class="">noiseprotocol/noise_spec/blob/<wbr class="">rev34/output/noise.pdf</a><br class=""> <br class=""> <br class=""> Trevor<br class=""> <br class=""> [1] <a href="https://github.com/noiseprotocol/noise_spec/tree/rev34" rel="noreferrer" target="_blank" class="">https://github.com/<wbr class="">noiseprotocol/noise_spec/tree/<wbr class="">rev34</a><br class=""> </blockquote></div><br class=""></div> _______________________________________________<br class="">Noise mailing list<br class=""><a href="mailto:Noise@moderncrypto.org" class="">Noise@moderncrypto.org</a><br class="">https://moderncrypto.org/mailman/listinfo/noise<br class=""></div></blockquote></div><br class=""></div></div></div></div></body></html>