<div dir="ltr"><div><div>Hi everyone,<br><br></div>I've been reading through rev33, and I wanted to send in the following minor comments which I hope will lead to improvements in rev34:<br><br></div>1. I think it would be a good idea to expand 7.1.2 to mention that no token may occur twice in the same message flight.<br><div><br></div><div>2. Section 9 seems oddly isolated and describes a single token in a way that seems artificially distinct from the other tokens. It can likely be (and should be) merged into Section 5, which already contains statements describing the methodical parsing of every other token that's not a psk token.<br><br></div><div>3. Probably my least favorite thing about rev33 is the isolation of certain validity rules. Since 7.1 already describes validity rules with one being necessary to avoid "catastrophic" errors, it makes a lot of sense to also merge the "catastrophe"-avoiding validity rules in 9.3 (and perhaps even 11.5) into the same section.<br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Nadim Kobeissi<div>Symbolic Software <span style="color:rgb(84,84,84);font-size:small">• <a href="https://symbolic.software" target="_blank">https://symbolic.software</a></span></div><div><span style="color:rgb(84,84,84);font-size:small">Sent from office</span></div></div></div></div>
<br><div class="gmail_quote">On Tue, Apr 10, 2018 at 7:29 AM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Apr 9, 2018 at 8:13 PM, Justin Cormack<br>
<<a href="mailto:justin@specialbusservice.com">justin@specialbusservice.com</a>> wrote:<br>
><br>
> A brief changelog alongside the spec would be helpful.<br>
<br>
</span>I'll add that when I find the time.<br>
<span class=""><br>
<br>
> Its marked official/stable in the html and pdf outputs.<br>
<br>
</span>Fixed.<br>
<br>
<br>
One small change I forgot to mention:  I removed the reference to KEA+<br>
as originating the idea of hashing identity information into session<br>
keys.  I did a little research (prompted by Douglas Stebila) and<br>
realized the idea of hashing identifiers into session keys for UKS<br>
resistance was well-known substantially before KEA+, e.g. from Colin<br>
Boyd's 2003 book:<br>
<br>
 "A general method to ensure that unknown key-share attacks do not<br>
apply is to include both principal identities within the key<br>
derivation function."<br>
<br>
Or from the original paper on UKS by Blake-Wilson and Menezes in 1999:<br>
<br>
"Instead of including the identities of the entities in the signed<br>
message, one could include them in the key derivation function".<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Trevor<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Noise mailing list<br>
<a href="mailto:Noise@moderncrypto.org">Noise@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer" target="_blank">https://moderncrypto.org/<wbr>mailman/listinfo/noise</a><br>
</div></div></blockquote></div><br></div>