<div dir="ltr"><div><br></div>Great feedback, thanks, comments below:<br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 23, 2017 at 9:13 AM, David Wong <span dir="ltr"><<a href="mailto:davidwong.crypto@gmail.com" target="_blank">davidwong.crypto@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
1.<br>
<br>
I find it weird to specify the function `SetNonce` in the<br>
`CipherState` section. I see that section as a "mandatory" set of<br>
functions to implement, which doesn't make sense if I do not want to<br>
create a Noise protocol over UDP. Can't this function be defined in<br>
the relevant section?<br>
<br>
(I have the same critic for `MixKeyAndHash` btw.)<br></blockquote><div><br></div><div><div>One goal for the CipherState and SymmetricState functions is to specify the complete interface between the symmetric crypto and the rest of Noise. I.e. if you implement these functions (with Strobe or anything else) then you will fully support all Noise features.</div><div><br></div><div>So assuming we want to make nonce-based AEAD a requirement, so that out-of-order transport messages are possible with all crypto, I think specifying a SetNonce() function is a good way to do it.</div><div><br></div><div>Whether requiring nonce-based AEAD is the right choice is another question. I argued for that, but we should keep that discussion going if you're not convinced:</div><div><br></div><div><a href="https://moderncrypto.org/mail-archive/noise/2017/001252.html">https://moderncrypto.org/mail-archive/noise/2017/001252.html</a></div><div><br></div><div>[This reminds me channel-binding was accessing 'h' directly, so I added a SymmetricState.GetHandshakeHash()].</div><div><br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2.<br>
<br>
For naming, I'd much prefer something along these lines:<br>
<br>
"you concatenate the ASCII names for the handshake pattern, the<br>
asymmetric functions, the symmetric functions"<br></blockquote><div><br></div><div><div>I agree that we ultimately want "Asymmetric functions" instead of "DH functions". But it might make sense to introduce that along with examples (e.g. the hybrid forward secrecy spec could talk about asymmetric functions as a generalization of DH and KEMs). So maybe this should wait for a different spec (or future revision)?</div><div><br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
with the "symmetric functions" being something like "AESGCM_SHA256" or<br>
"STROBEvX_Keccak1600"<br></blockquote><div><br></div><div><div>Agreed we should have some way to indicate symmetric-crypto layers like Disco that don't fit our current CIPHER_HASH convention. There's a lot of ways we could do that, e.g.</div><div><br></div><div>#1) Noise_XX_25519_STROBEvX_Keccak1660</div><div>#2) Noise_XX_25519_STROBEvX/Keccak1660</div><div>#3) Noise_XX_25519_(STROBEvX_Keccak1660)</div><div>#4) Noise_XX_25519_STROBEvX-Keccak1660</div><div><br></div><div>In your proposal (#1) it's not possible to generically parse the symmetric name, you'd have to recognize that "STROBEvX" is not a cipher and trigger different parsing for following components. So I might like #2 better, but it only allows a single separator character inside the name ("/"). If the symmetric crypto names have a lot of structure, maybe we need something like #3 or #4 that allows multiple separator characters?</div><div><br></div><div>Are we ready to make a decision here? I'm not sure, it might be worth holding off until we've looked into Disco etc some more.</div><div><br></div><div> </div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3.<br>
<br>
The "Out-of-order transport messages" section is small, and maybe<br>
dangerous as it is not that trivial to implement a secure protocol<br>
over UDP. You have to mind other details like "Am I sure this message<br>
is coming from the right origin?" via things like cookies. Obviously I<br>
don't know much about that, probably Jason has more to add to it, but<br>
a warning might be relevant in this section.<br></blockquote><div><br></div><div><div><div>Added a sentence, does this cover it?<br></div><div><br></div><div>"""</div><div>Note that lossy and out-of-order message delivery introduces many other concerns</div><div>(including out-of-order handshake messages and denial of service risks) which</div><div>are outside the scope of this document.</div><div>"""</div><div><br></div></div></div><div>Trevor</div><div><br></div></div></div></div>