[noise] Transport protocol spec finalizing

[Trevor Perrin]

One idea we discussed for NoiseSocket was the server sending a "retry
request" (initially proposed as version=0xFFFFFFFF, but now just an
empty noise_message).

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

This isn't in the current NoiseSocket draft.  I think it's probably
right to drop this feature.  It adds complexity and doesn't seem
necessary.  Taking a closer look at potential use cases for it:

 (1) Client advertises support for multiple DH choices, but doesn't
want to generate and send multiple DH ephemerals in its first message.
In this case, the server could indicate a DH choice with its retry
request, and the client could then "retry" an initial message with the
server's DH choice.

 (2) Client chooses an initial version using an ephemeral that the
server doesn't recognize, so the server isn't able to use a "fallback"
handshake.  In this case, the server indicates an error, and the
client could "retry" with an older version.

 (3) In TLS or WireGuard there's the idea of a server under DoS attack
responding with a cookie, to prove that the client's source address
isn't spoofed.  The client then "re-sends" the initial message with
the cookie.


To handle these without a "retry request":

For (1), instead of the server telling the client to start a new XX
handshake, it would be more efficient for the server to just start a
new XX handshake in the initiator role.

Case (2) is avoidable either by the client always offering an old
ephemeral, or by handling it the same as case (1), where the server
responds with an old ephemeral.

Case (3) might benefit from a more specialized design (like
WireGuard).  But if we wanted to handle it through this negotiation
mechanism, it would be easy enough for a server to reject the initial
message and return a cookie in negotiation_data.  The client would
then open a new connection and repeat its initial message plus the
cookie.  This wouldn't have the benefit of including the first
handshake's transcript in second handshake's prologue.  However, if
the client is careful to repeat the initial request and not process
anything from the server except the cookie, that shouldn't matter, and
seems overall simpler than having the server externalize the initial
transcript hash into the cookie (so that it can process the cookie
statelessly, later).

If we drop retry requests, we don't have to think about the state
machine "re-starting" or about chaining transcript hashes arbitrarily,
we just have a simple pattern of:

 -> CLIENT_CHOICE
 <- SERVER_ACCEPT or SERVER_CHOICE or ERROR

Where:
  SERVER_ACCEPT is indicated by empty negotiation_data
  ERROR is indicated by empty noise_message


Trevor



On Wed, Jul 19, 2017 at 7:46 PM, Trevor Perrin <trevp at trevp.net> wrote:
> On Wed, Jul 19, 2017 at 5:59 PM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
>> I've added some fixes, though not all of them. Same url.
>
> https://github.com/noisesocket/spec/blob/master/output/noisesocket.pdf
>
> At some point we can discuss linking this from the webpage or something.
>
> The technical details look good.
>
> I think this is still a difficult read for someone who doesn't already
> understand the Noise spec.
>
> Maybe there needs to be more Overview of what a Noise protocol is, and
> the rationale for negotiation_data and prologue / transcript hashing.
> Explaining all this in a simple way isn't easy.  Perhaps diagrams and
> more examples would help.
>
>
> Editorial:
>
> Abstract: "[+and] back-end applications"
>
> Overview:
>  - "Usually [2] or [3] messages"
>  - Fix formatting for "**negotiation_data**"
>  - Not sure you need the sentence about "Usage of negotiation_data
> without making it a part of the handshake" in this Overview, could be
> deleted or moved to a Security Considerations section at the end.
>  - This description is a step in the right direction, but it's still
> somewhat confusing.  For example, you say a handshake packet contains
> an optional field (negotiation_data) which is not part of the
> handshake message.  I know what you're saying, but I think most
> readers will have trouble with this.
>
> 2.2.
>  - Probably don't bold entire sentence "Padding contents are abitrary...".
>
> 2.3.
>  - I wouldn't mention the MixHash() option, since this isn't part of
> Noise, and people reading this spec might not know what MixHash()
> does.
>
>
> 5. API
>  - The "Common logic" for padded_len is confusing and dense, should
> probably be simplified.
>  - I wouldn't use the term "cleartext_body", since only the initial
> payload is technically cleartext.
>
> 6.
>  - Probably not a good idea to reference Noise-C for constants, I'm
> not sure Rhys intended this to be a permanent number registry.
>  - It might be worthwhile to give a fully-worked-out and
> self-contained Noise_XX example, i.e. just list out all the HMAC and
> AEAD steps, so someone could implement that directly without the Noise
> spec.
>
>
> Trevor