[noise] Revision 33 draft

[Trevor Perrin]

Great feedback, thanks, comments below:

On Sat, Sep 23, 2017 at 9:13 AM, David Wong <davidwong.crypto at gmail.com>
wrote:

>
> 1.
>
> I find it weird to specify the function `SetNonce` in the
> `CipherState` section. I see that section as a "mandatory" set of
> functions to implement, which doesn't make sense if I do not want to
> create a Noise protocol over UDP. Can't this function be defined in
> the relevant section?
>
> (I have the same critic for `MixKeyAndHash` btw.)
>

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.

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.

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:

https://moderncrypto.org/mail-archive/noise/2017/001252.html

[This reminds me channel-binding was accessing 'h' directly, so I added a
SymmetricState.GetHandshakeHash()].



> 2.
>
> For naming, I'd much prefer something along these lines:
>
> "you concatenate the ASCII names for the handshake pattern, the
> asymmetric functions, the symmetric functions"
>

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)?



> with the "symmetric functions" being something like "AESGCM_SHA256" or
> "STROBEvX_Keccak1600"
>

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.

#1) Noise_XX_25519_STROBEvX_Keccak1660
#2) Noise_XX_25519_STROBEvX/Keccak1660
#3) Noise_XX_25519_(STROBEvX_Keccak1660)
#4) Noise_XX_25519_STROBEvX-Keccak1660

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?

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.



> 3.
>
> The "Out-of-order transport messages" section is small, and maybe
> dangerous as it is not that trivial to implement a secure protocol
> over UDP. You have to mind other details like "Am I sure this message
> is coming from the right origin?" via things like cookies. Obviously I
> don't know much about that, probably Jason has more to add to it, but
> a warning might be relevant in this section.
>

Added a sentence, does this cover it?

"""
Note that lossy and out-of-order message delivery introduces many other
concerns
(including out-of-order handshake messages and denial of service risks)
which
are outside the scope of this document.
"""

Trevor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170923/e44aaa42/attachment.html>