[noise] expected length of messages during handshake
piotr.lizonczyk at gmail.com
Thu Nov 9 15:29:32 PST 2017
Makes perfect sense. :)
2017-11-10 0:28 GMT+01:00 Trevor Perrin <trevp at trevp.net>:
> 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
> > 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).
> > 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
> > 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
> > 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
> pattern/DH/cipher/hash breakdown:
> > 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
> > 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?
>  https://moderncrypto.org/mail-archive/noise/2017/001211.html
>  https://moderncrypto.org/mail-archive/noise/2017/001215.html
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Noise