[noise] expected length of messages during handshake

[Trevor Perrin]

On Thu, Nov 9, 2017 at 9:30 PM, Piotr Lizończyk
<piotr.lizonczyk at gmail.com> wrote:
> Separate document sounds reasonable - choosing to follow another philosophy
> for structuring negotiation data contents wouldn't mean diverging from
> NoiseSocket spec at all.

Yeah, exactly - there's lots of possible languages for negotiation,
versioning, etc, so NoiseSocket would be independent from that.


> I think that basic fields should include:
> 1) version (both noiseprotocol and noisesocket, i.e. spec revision). Version
> of NoiseLink could be useful too.
> 2) initial noise protocol
> 3) noise protocols supported
>
> Most reasonable format for 3) would consist of handshake
> patterns/cipher/dh/hash supported (quite small in size), though it would put
> some constraints on the user - inability to support only specific
> combinations of those, not every possible combination of supported
> algorithms. Not sure if it would have any reasonable usecase, but it's worth
> considering at the early stage of design.

Good question: Should the client advertise a single list of Noise
protocols she supports, or separate lists for pattern, DH, cipher,
hash.

Earlier I suggested separate lists [1].

But now I'm leaning towards a single list as the best starting point.
It gives us maximum flexibility, since a list of protocol strings
could contain anything, including names that wouldn't fit into a
pattern/DH/cipher/hash breakdown:
  "Noise_XX_25519_DiscoKeccak",
  "NoiseV2_XX_25519_AESGCM_SHA256",
  "TLS_13_25519_AESGCM_SHA256",
  etc


> By the way, had a quick glance at TLS's CLIENT_HELLO - it has session_id
> field in it

As David said, sending a SessionID / Session Ticket is how the TLS
client identifies a PSK for PSK-based resumption.  If we do 0-RTT
connections with public keys (e.g. ?K patterns), instead of PSK
resumption, we don't need it.

But at some point we'll hopefully spec out PSK resumption, probably
like [2], and that will require the client to send a SessionID /
Session Ticket field.

> I'd see this field as an optional one, so maybe we could have
> "optional data field" at the end of negotiation data that could contain such
> data.

What I'm thinking is we can describe the contents of our default
negotiation_data in abstract terms that can be translated into
protobufs, XML, JSON, or your favorite encoding language.  Then we get
parsing and extensibility mostly for free, and higher-level protocol
designers can use whatever they're already using.  Make sense?


Trevor

[1] https://moderncrypto.org/mail-archive/noise/2017/001211.html
[2] https://moderncrypto.org/mail-archive/noise/2017/001215.html