[noise] expected length of messages during handshake

[Piotr Lizończyk]

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
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20171110/c5755237/attachment.html>