[noise] expected length of messages during handshake
trevp at trevp.net
Thu Nov 9 15:28:20 PST 2017
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,
Earlier I suggested separate lists .
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
> 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 , 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
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?
More information about the Noise