Re: [TLS] TLS1.3 + PSK with multiple identities

[Hannes Tschofenig <[e-mail]>]

Hi Andreas,

I am not sure that people ignore the redundant length fields on purpose.
I think that the strange syntax that TLS uses invites these types of
mistakes and I had run into those myself as well.

Ciao
Hannes


On 10/05/2016 02:03 PM, Andreas Walz wrote:
> Hi Olivier,
> 
> your findings are interesting as they pretty much match with what we
> have found when studying TLS implementations for embedded systems. In
> many implementations there is a tendency to ignore redundant length
> fields (or at least to not enforce consistency). There has been some
> discussion about this on the list, see thread "Suspicious behaviour of
> TLS server implementations".
> 
> We are currently refining our study and in the process of writing a
> paper. I hopefully can give more details on results soon.
> 
> Cheers,
> Andi
> 
> ___________________________________
> 
> Andreas Walz
> Research Engineer
> Institute of reliable Embedded Systems and Communication Electronics (ivESK)
> Offenburg University of Applied Sciences, 77652 Offenburg, Germany
> 
> 
>>>> Olivier Levillain <[e-mail]> 10/04/16 5:51 AM >>>
> Hi list,
> 
> I have been working in the labs at ANSSI (the French Network and
> Information System Agency) for several years and I just defended my PhD
> thesis on the TLS ecosystem (documents are available at
> http://paperstreet.picty.org/~yeye/2016/phdthesis-Levillain16/).
> 
>>> 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.
> 
> Sorry if I am a little late to the party, but I noticed that even if
> this is generally true, I believe it has not always been enforced in TLS
> extensions.
> 
> In 2006, the IETF standardised the session tickets extension, allowing
> for session resumption without server-side state (RFC 4507).
> However, no TLS stack implements the specification correctly: even
> if the specification described the _content_ of the extension as
> a variable-length object (that is an opaque object prefixed by its
> length), every implementation ignores this second (useless) length
> field. The RFC 5077, published in 2008, fixes the gap
> between the specification and the implementations.
> 
> RFC 4507 :
> 
> The SessionTicket extension has been assigned
> the number 35. The format of the SessionTicket
> extension is given at the end of this section.
> 
> struct {
> opaque ticket<0..2^16-1>;
> } SessionTicket;
> 
> 00 23 Ticket Extension type 35
> 01 02 Length of extension contents
> 01 00 Length of ticket
> FF FF .. .. Actual ticket
> 
> RFC 5077
> 
> The SessionTicket extension has been assigned
> the number 35. The extension_data field of
> SessionTicket extension contains the ticket.
> 
> 00 23 Ticket Extension type 35
> 01 00 Length of extension contents (ticket)
> FF FF .. .. Actual ticket
> 
> 
> Best regards,
> olivier
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>