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? I also find it interesting to note that the total permitted length of a single PskIdentity (65539 bytes) is such that you might not be able to fit even *one* of them into the PreSharedKeyIdentity extension at all, let alone multiple such. > > > 2. Why does the client send multiple identities? In TLS-SRP a single > > > identity is sent, and the same in the existing TLS-PSK rfc. How is this > > > envisioned to be used? A client sends: I'm probably one of Bob, Nikos, > > > George, take a look on that list and tell me who I really am? In that > > > case why not allow the server, to reply with a username outside that > > > list (i.e., assign a new one to be used at the next session - see point > > > 1). > > You already need multiple if you try to "resume"[1] DHE-PSK session > > (since "resumption" shares the PSK space). > > That's very awkward. That way the protocol mandates code like: > > if (!id_in_resumption_db()) { > if (!valid_ticket()) > if (!try_find_user_in_psk_userfile()) > proceed_with_random_psk(); /* hide the fact that username > doesn't exist in db */ > } > > which is not really sane code. Not only that, but servers who would > like to prevent valid username testing in their PSK key file as above, > would be forced to make resumption attempts with unknown or long- > expired tickets fail. > > A protocol must have clarity on the data sent on the wire and their > purpose. Cross protocol attacks work by exploiting data which may be > interpreted in multiple ways and such generic purpose identifiers seem > to be like a good candidate for that. > > I think at minimum identities known to the protocol (e.g., resumption) > should be distinguishable from PSK usernames. The draft leaves that to > the server implementor to do, but I do think such identifiers should be > tagged at the protocol level since it affects all implementations. > > > > > 3. The maximum size of the username is 2^16. Isn't that excessive > > > > > > for a > > > user name or a user identifier? Why not set 2^8? That would fit a > > > uuid > > > or anything similarly large. > > If one wants to do the equivalent of tickets in TLS 1.2, one needs > > pretty large usernames. > > I find that, as another unfortunate side-effect of combining unrelated > protocol fields. Oh, it's more fun than that. RFC4279 §5.1 currently says that the PSK identity MUST be a UTF-8 character string. Libraries such as OpenSSL and GnuTLS already handle identities as NUL-terminated strings. The current TLSv1.3 draft appears to relax that requirement without any form of explicit compatibility note about it — I'd expect to see *some* mention in the 'Major Differences from TLS 1.2" section. Perhaps one way to resolve much of this is to put the traditional PSK identities into one PreSharedKeyExtension and maintain the UTF-8 requirement there, and to put the "identity" used for session resumption into a different extension. Perhaps allowing the latter to appear multiple times in a ClientHello and for their contents to be concatenated, which partly addresses the problem of their total size. 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? Does the server need *all* of it, for every session being offered for resumption by the client, in the ClientHello? My final comment on the PSK identities for now... I see the TLSv1.3 draft now contains a PskKeyExchangeMode which is absent from the (once-)corresponding draft-jay-tls-psk-identity-extension. It's not entirely obvious to me how this interacts with the selected cipher suite, which itself may or may not use (EC)DHE. 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. Or is the intent that when requesting offering both DHE and non-DHE cipher suites, the client should offer *two* identities, one with each possible value of PskKeyExchangeMode? In which case do we want a third value for PskKeyExchangeMode which indicates that a given identity may be used in either mode? -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls