On Mon, Sep 19, 2016 at 2:49 AM, David Woodhouse <dw...@infradead.org> wrote:
> On Mon, 2016-09-19 at 10:29 +0200, Nikos Mavrogiannopoulos wrote: > > On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote: > > > More compact and makes the option where server sends some bad option > > > more clear. > > Note that if we really want to be more compact, we might also observe > that there is a redundant length field in the extension as sent by the > client: > case client_hello: > PskIdentity identities<6..2^16-1>; > > Each extension has at least four bytes on the wire — the extension_type > itself, and the length field of the extension_data in a uint16. > > If I am interpreting the spec correctly, then the data for the > PreSharedKeyIdentity extension in the ClientHello then follows that > with another uint16, which is *always* a value two lower than the one > which immediately precedes it. > > e.g. > > 0x00 0x29 // ExtensionType extension_type == 41 > 0x00 0x14 // opaque extension_data<0..2^16-1> > // This length field is entirely redundant: > 0x00 0x12 // PskIdentity identities<6..2^16-1> > // First identity: > 0x00 0x00 // PskKeyExchangeMode, PskAuthenticationMode > 0x00 0x04 // opaque identity<0..2^16-1> > 0x44 0x61 0x76 0x65 // "Dave" > // Second identity: > 0x00 0x00 // PskKeyExchangeMode, PskAuthenticationMode > 0x00 0x06 // opaque identity<0..2^16-1)> > 0x43 0x68 0x6c 0x6f 0xc3 0xab // "Chloë" > > Do we care that the '0x00 0x12' bytes on my third line above are > entirely redundant on the wire? Or have I interpreted it wrong? > Not enough to fix it, this is just the way TLS rolls. > Is there no way the PSK identities for session resumption could be made > smaller? Of the data which RFC5077 suggests that we put into a session > ticket (and thus the PSK identity), is there *none* of it which could > be sent later in a ClientKeyExchange packet? No. Also, there isn't a CKE record in TLS 1.3. All information needed to derive the key needs to be in the CH. Is it permitted, and what is the meaning, to request a cipher suite of > (e.g.) TLS_PSK_WITH_AES_256_CBC_SHA and set PskKeyExchangeMode in the > identity to 'psk_dhe_ke'? Or conversely, to use the cipher suite > TLS_DHE_PSK_WITH_AES_256_CBC_SHA with PskKeyExchangeMode set to > 'psk_ke'? > > This seems redundant to me at first glance (unless some combinations > really do mean that you end up doing DHE *twice*) and could probably do > with some clarification. > TLS 1.3 cipher suites do not convey key exchange mode, just AED and KDF. See https://tlswg.github.io/tls13-spec/#cryptographic-negotiation for an overview of negotiation. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
