Re: [TLS] TLS1.3 + PSK with multiple identities
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 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 + PSK with multiple identities
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 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 23FF FF .. ..Actual ticket
Best regards,
olivier
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 + PSK with multiple identities
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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 + PSK with multiple identities
On Mon, Sep 19, 2016 at 1:35 PM, David Woodhouse wrote: > On Mon, 2016-09-19 at 09:53 -0700, Eric Rescorla wrote: > > > > > I would address this either by: > > > > > > > > 1. Registering a new extension which is used to indicate the right > worker > > > > process, but using existing TLS 1.2 PSK. > > > > > > OK... except this basically *is* the PSK identity. So the new extension > > > we'd want to register, if we want to make it something that's useful in > > > the general case rather than an application-specific hack, *is* > > > basically draft-jay-tls-psk-identity-extension :) > > > > No, I don't think that's true. That extension also attempts to actually > > negotiate the keys in that layer. I'm just talking about a hint. > > It's more than just a hint. It is saying precisely which client it is, > which has a 1:1 correspondence with which PSK it's using. > Call it a promise, if you prefer. One that you fulfill with the CE. It is purely a matter of software architecture — the initial incoming > UDP packets reach a dispatcher that needs to hand the connection off to > the appropriate worker process for that client and *really* wants > to make that decision based on the ClientHello alone. > > If we *start* the handshake in the main dispatcher and get to the point > of seeing the ClientKeyExchange, we have to hand over the partially- > completed handshake (or keep going and then hand over a fully-completed > handshake) to the appropriate worker. And in fact I don't even think > the dispatcher *has* the actual keys; only the identities so that it > knows where to dispatch connections to. > See above. The key advantage of what I am proposing here is that it has exactly the same cryptographic properties as current TLS-PSK, with the indicator just serving as a routing-ID. > > So I really do think that draft-jay-tls-psk-identity-extension was > *exactly* what I wanted. I don't care about *negotiating* the PSK > identity per se; I'm happy to support only one. It's purely about > *telling* the server, in the ClientHello, which identity I'm using. > See above. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 + PSK with multiple identities
On Mon, 2016-09-19 at 09:53 -0700, Eric Rescorla wrote: > > Perhaps I should turn your question round, and ask: if PSK is a first- > > class citizen as a key exchange and authentication method, why *should* > > we be forbidden from resuming sessions which started that way... > > Well, I'm not saying you can't do that. As I said, you can use HRR if the > resumption > fails. I suppose that's an answer in the general case too, isn't it? If you want to try multiple identities, you can just keep trying with HRR until you find one that the server accepts. In fact, it doesn't even need to be "keep trying until...". You could still offer multiple PSK identities in the ClientHello, and only offer a hello_finished MAC for the *first* (preferred) one. If the server doesn't want that one, it can send a HRR with a PreSharedKeyExtension that tells the client which one it *does* want. You preserve the original behaviour of negotiating which PSK identity to use, while also fixing the problem that limits you to just one. < ...context switching to my actual use case... > > > > I would address this either by: > > > > > > 1. Registering a new extension which is used to indicate the right worker > > > process, but using existing TLS 1.2 PSK. > > > > OK... except this basically *is* the PSK identity. So the new extension > > we'd want to register, if we want to make it something that's useful in > > the general case rather than an application-specific hack, *is* > > basically draft-jay-tls-psk-identity-extension :) > > No, I don't think that's true. That extension also attempts to actually > negotiate the keys in that layer. I'm just talking about a hint. It's more than just a hint. It is saying precisely which client it is, which has a 1:1 correspondence with which PSK it's using. In theory it would work to use the existing identity in the ClientKeyExchange in TLS1.2. However, in practice it becomes extremely painful to do so because the ClientKeyExchange comes in too late. It is purely a matter of software architecture — the initial incoming UDP packets reach a dispatcher that needs to hand the connection off to the appropriate worker process for that client and *really* wants to make that decision based on the ClientHello alone. If we *start* the handshake in the main dispatcher and get to the point of seeing the ClientKeyExchange, we have to hand over the partially- completed handshake (or keep going and then hand over a fully-completed handshake) to the appropriate worker. And in fact I don't even think the dispatcher *has* the actual keys; only the identities so that it knows where to dispatch connections to. So I really do think that draft-jay-tls-psk-identity-extension was *exactly* what I wanted. I don't care about *negotiating* the PSK identity per se; I'm happy to support only one. It's purely about *telling* the server, in the ClientHello, which identity I'm using. I suppose I can just say 'screw it' and continue to abuse the session-id for this without actually resuming a session :) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 + PSK with multiple identities
On Mon, Sep 19, 2016 at 8:37 AM, David Woodhouse wrote: > On Mon, 2016-09-19 at 07:55 -0700, Eric Rescorla wrote: > > > What if my client authenticates with an actual pre-shared key, and I > > > also want to resume a session? As it stands, that means I really do > > > need to offer two PSK identities — one for the real identity, and one > > > for the session resumption attempt. Are you saying that won't be > > > permitted? > > > > I should start by saying that it's not entirely clear why this is useful. > > Can you elaborate? > > I should start by pointing out that I have no personal *need* for this; > it just seems strange and wrong to forbid it > > I assume you're not asking why one would use PSK in the first place, in > place of public keys? I think the introduction to RFC4279 fairly much > covers that and is still relevant. > > So I interpret your question as asking why it's useful to *resume* a > session which was initiated with PSK? > Yes. Even though the cryptographic operations are basically the same — > there's none of the heavyweight asymmetric key operations, it's also > the case that resumed sessions may carry more application-specific > context than a newly-authenticated connection. > > Consider IMAP, as an example. It has a large amount of per-connection > state. This *could* be maintained even when the client disconnects — > you can imagine a mobile client which resumes an existing TLS session > and is *immediately* presented with all the status updates which have > occurred since it disconnected, without any need for re-building the > application-session state (or using any of the protocol extensions like > QRESYNC which help to reduce the connection startup time). > > (Note: I'm not suggesting a *stateless* resume could do that.) > This doesn't seem like the kind of behavior we want to encourage in applications. Perhaps I should turn your question round, and ask: if PSK is a first- > class citizen as a key exchange and authentication method, why *should* we be forbidden from resuming sessions which started that way... Well, I'm not saying you can't do that. As I said, you can use HRR if the resumption fails. just > because you've chosen to conflate PSK identities and session resumption > on the wire? :) > As I said before, that's not the reason to restrict to a single identity. > I would address this either by: > > > > 1. Registering a new extension which is used to indicate the right worker > > process, but using existing TLS 1.2 PSK. > > OK... except this basically *is* the PSK identity. So the new extension > we'd want to register, if we want to make it something that's useful in > the general case rather than an application-specific hack, *is* > basically draft-jay-tls-psk-identity-extension :) > No, I don't think that's true. That extension also attempts to actually negotiate the keys in that layer. I'm just talking about a hint. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 + PSK with multiple identities
On Mon, 2016-09-19 at 07:55 -0700, Eric Rescorla wrote: > > What if my client authenticates with an actual pre-shared key, and I > > also want to resume a session? As it stands, that means I really do > > need to offer two PSK identities — one for the real identity, and one > > for the session resumption attempt. Are you saying that won't be > > permitted? > > I should start by saying that it's not entirely clear why this is useful. > Can you elaborate? I should start by pointing out that I have no personal *need* for this; it just seems strange and wrong to forbid it. I assume you're not asking why one would use PSK in the first place, in place of public keys? I think the introduction to RFC4279 fairly much covers that and is still relevant. So I interpret your question as asking why it's useful to *resume* a session which was initiated with PSK? Even though the cryptographic operations are basically the same — there's none of the heavyweight asymmetric key operations, it's also the case that resumed sessions may carry more application-specific context than a newly-authenticated connection. Consider IMAP, as an example. It has a large amount of per-connection state. This *could* be maintained even when the client disconnects — you can imagine a mobile client which resumes an existing TLS session and is *immediately* presented with all the status updates which have occurred since it disconnected, without any need for re-building the application-session state (or using any of the protocol extensions like QRESYNC which help to reduce the connection startup time). (Note: I'm not suggesting a *stateless* resume could do that.) Perhaps I should turn your question round, and ask: if PSK is a first- class citizen as a key exchange and authentication method, why *should* we be forbidden from resuming sessions which started that way... just because you've chosen to conflate PSK identities and session resumption on the wire? :) > > Or do we [need] to stop conflating the two types of PSK-identity, so that > > we can allow only one of each? > > That doesn't address the reasons for only allowing one, unfortunately. See > the thread on Finished stuffing. OK, I'll read up on that; thanks. > I would address this either by: > > 1. Registering a new extension which is used to indicate the right worker > process, but using existing TLS 1.2 PSK. OK... except this basically *is* the PSK identity. So the new extension we'd want to register, if we want to make it something that's useful in the general case rather than an application-specific hack, *is* basically draft-jay-tls-psk-identity-extension :) If we do anything else, we might as well stick with some of the horrid hacks we already have (like abusing the session-id and not actually *resuming* that session). > 2. Wait for DTLS 1.3. It's certainly *tempting* to manually add chacha20 to our ever-growing list and *then* wait for DTLS1.3 :) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 + PSK with multiple identities
On Mon, Sep 19, 2016 at 7:07 AM, David Woodhouse wrote: > On Mon, 2016-09-19 at 05:46 -0700, Eric Rescorla wrote: > > > > > And then the client only needs to supply one copy of it for the > > > identity which the server actually selected, not one for *each* > > > identity which was being offered by the client. > > > > We're most likely going to allow only on PSK anyway. > > You mean "only one", I assume? > Yes. > What if my client authenticates with an actual pre-shared key, and I > also want to resume a session? As it stands, that means I really do > need to offer two PSK identities — one for the real identity, and one > for the session resumption attempt. Are you saying that won't be > permitted? > I should start by saying that it's not entirely clear why this is useful. Can you elaborate? Or do we stop to stop conflating the two types of PSK-identity, so that > we can allow only one of each? That doesn't address the reasons for only allowing one, unfortunately. See the thread on Finished stuffing. > > > I share Nikos's concern about using the PSK identity for two completely > > > different types of identifiers — especially given that one type has > > > historically been defined as UTF-8 text, while the other is binary. > > > > > > The reason I care about this right now is that we're looking at using > > > PSK to bootstrap a DTLS connection in the context of an SSL VPN, > > > currently using DTLS 1.2 and draft-jay-tls-psk-identity-extension. > > > > I recommend against this: I very much doubt that we are going to adopt > this > > draft in TLS. > > That is useful feedback; thank you. Although I'm slightly confused — > although the draft is out of date, I thought the point of it was to > simply document what you *are* adopting in TLS1.3, for use in TLS1.2. > Are you saying that the extension will never be retroactively 'blessed' > for TLS1.2 even when it's part of TLS1.3? > I can't speak for the motivations of the authors of this draft. It's not a WG item. However, I'm not generally in favor of backporting pieces of TLS 1.3 into 1.2 like this. What we're trying to do is move away from the existing model, inherited > from Cisco AnyConnect, where the DTLS ciphersuite is negotiated out-of- > band along with a master secret, and then we 'resume' a DTLS session > that never really existed. > > It took us a *long* time to gain support for DTLS1.2 and AEAD cipher > suites because of that, and it would be much better just to let DTLS > negotiate as $DEITY intended. > > But the architecture of our server is such that it *really* wants to > know from the very first ClientHello packet which client it's talking > to, so that the packet can be dispatched to the correct worker > process. > > The first prototype of this continued to abuse the Session-ID to > identify the client — making it *look* like a session resume attempt > when in fact we weren't prepared to resume the session at all, and we > rely on the server *not* doing so. > > I kind of threw my toys out of the pram at that — if we're going to > attempt to use the protocol properly, then I really do want to do it > *properly*. Hence the interest in draft-jay-tls-psk-identity-extension. > > If that's not going to be viable, then I'm starting to wonder if we > should just wait for DTLS1.3. After all we *already* support the fun > parts of DTLS1.2, and AEAD ciphersuites, so there's no desperate rush > to start using proper negotiation. I would address this either by: 1. Registering a new extension which is used to indicate the right worker process, but using existing TLS 1.2 PSK. 2. Wait for DTLS 1.3. -Ekr > -- > dwmw2 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 + PSK with multiple identities
On Mon, 2016-09-19 at 05:46 -0700, Eric Rescorla wrote: > > > And then the client only needs to supply one copy of it for the > > identity which the server actually selected, not one for *each* > > identity which was being offered by the client. > > We're most likely going to allow only on PSK anyway. You mean "only one", I assume? What if my client authenticates with an actual pre-shared key, and I also want to resume a session? As it stands, that means I really do need to offer two PSK identities — one for the real identity, and one for the session resumption attempt. Are you saying that won't be permitted? Or do we stop to stop conflating the two types of PSK-identity, so that we can allow only one of each? > > I share Nikos's concern about using the PSK identity for two completely > > different types of identifiers — especially given that one type has > > historically been defined as UTF-8 text, while the other is binary. > > > > The reason I care about this right now is that we're looking at using > > PSK to bootstrap a DTLS connection in the context of an SSL VPN, > > currently using DTLS 1.2 and draft-jay-tls-psk-identity-extension. > > I recommend against this: I very much doubt that we are going to adopt this > draft in TLS. That is useful feedback; thank you. Although I'm slightly confused — although the draft is out of date, I thought the point of it was to simply document what you *are* adopting in TLS1.3, for use in TLS1.2. Are you saying that the extension will never be retroactively 'blessed' for TLS1.2 even when it's part of TLS1.3? What we're trying to do is move away from the existing model, inherited from Cisco AnyConnect, where the DTLS ciphersuite is negotiated out-of- band along with a master secret, and then we 'resume' a DTLS session that never really existed. It took us a *long* time to gain support for DTLS1.2 and AEAD cipher suites because of that, and it would be much better just to let DTLS negotiate as $DEITY intended. But the architecture of our server is such that it *really* wants to know from the very first ClientHello packet which client it's talking to, so that the packet can be dispatched to the correct worker process. The first prototype of this continued to abuse the Session-ID to identify the client — making it *look* like a session resume attempt when in fact we weren't prepared to resume the session at all, and we rely on the server *not* doing so. I kind of threw my toys out of the pram at that — if we're going to attempt to use the protocol properly, then I really do want to do it *properly*. Hence the interest in draft-jay-tls-psk-identity-extension. If that's not going to be viable, then I'm starting to wonder if we should just wait for DTLS1.3. After all we *already* support the fun parts of DTLS1.2, and AEAD ciphersuites, so there's no desperate rush to start using proper negotiation. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 + PSK with multiple identities
On Mon, Sep 19, 2016 at 5:26 AM, David Woodhouse
wrote:
> On Mon, 2016-09-19 at 04:41 -0700, Eric Rescorla wrote:
> > > 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.
>
> An interesting contrast to Nikos's observation that using the index in
> the response is "used nowhere else in TLS" — which he could have
> phrased using similar words. But I suppose in that case you're saving a
> *lot* more than two bytes in the ServerHello, so it makes sense to
> deviate from "the way TLS rolls" :)
>
Yes.
> > 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.
>
> Well, that was kind of my point. Information needed to derive the *key*
> needs to be in the ClientHello.
>
> But if it's auxiliary information which isn't actually *needed* to
> derive the key or to select which {identity to use,session to resume},
> then perhaps the client could be required to supply it afterwards.
>
You need the complete ticket to make sensible decisions.
And then the client only needs to supply one copy of it for the
> identity which the server actually selected, not one for *each*
> identity which was being offered by the client.
>
We're most likely going to allow only on PSK anyway.
I share Nikos's concern about using the PSK identity for two completely
> different types of identifiers — especially given that one type has
> historically been defined as UTF-8 text, while the other is binary.
>
> The reason I care about this right now is that we're looking at using
> PSK to bootstrap a DTLS connection in the context of an SSL VPN,
> currently using DTLS 1.2 and draft-jay-tls-psk-identity-extension.
I recommend against this: I very much doubt that we are going to adopt this
draft in TLS.
So it would be useful to have some clarity on the UTF-8 requirement
> from RFC4279, and whether it's being completely abandoned with TLS 1.3.
>
It's being abandoned. PR welcome.
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 + PSK with multiple identities
On Mon, 2016-09-19 at 04:41 -0700, Eric Rescorla wrote:
> > 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.
An interesting contrast to Nikos's observation that using the index in
the response is "used nowhere else in TLS" — which he could have
phrased using similar words. But I suppose in that case you're saving a
*lot* more than two bytes in the ServerHello, so it makes sense to
deviate from "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.
Well, that was kind of my point. Information needed to derive the *key*
needs to be in the ClientHello.
But if it's auxiliary information which isn't actually *needed* to
derive the key or to select which {identity to use,session to resume},
then perhaps the client could be required to supply it afterwards.
And then the client only needs to supply one copy of it for the
identity which the server actually selected, not one for *each*
identity which was being offered by the client.
But OK, if none of the information included by RFC5077 is in that
category then we really do need to cope with PSK identity fields which
can theoretically *each* be larger than the amount you can fit into a
single TLS extension...
I share Nikos's concern about using the PSK identity for two completely
different types of identifiers — especially given that one type has
historically been defined as UTF-8 text, while the other is binary.
The reason I care about this right now is that we're looking at using
PSK to bootstrap a DTLS connection in the context of an SSL VPN,
currently using DTLS 1.2 and draft-jay-tls-psk-identity-extension. And
the binary nature of 'session resumption' PSK identities will have an
effect on the crypto library APIs used to manage that — which as I
said, currently assume that they can use NUL-terminated strings.
So it would be useful to have some clarity on the UTF-8 requirement
from RFC4279, and whether it's being completely abandoned with TLS 1.3.
> > 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.
Ah, thanks. That makes more sense now.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 + PSK with multiple identities
On Mon, Sep 19, 2016 at 2:49 AM, David Woodhouse 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
Re: [TLS] TLS1.3 + PSK with multiple identities
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 offe
Re: [TLS] TLS1.3 + PSK with multiple identities
On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote:
> On Mon, Aug 08, 2016 at 10:17:40AM +0200, Nikos Mavrogiannopoulos
> wrote:
> >
> > Hello,
> > I'm reading the "Pre-Shared Key Extension" section of the TLS 1.3
> > draft [0], and I noticed quite some deviations (IMO) from typical
> > TLS
> > protocol behavior. No rationale is given about them so I ask on
> > list.
> >
> > To summarize, the client sends a list of identitities and the
> > server
> > replies with an index indicating which identity is approved.
> >
> > 1. The server reply with an index is unique in TLS. It is not used
> > in
> > ciphersuite selection or in any other negotiation in TLS where the
> > client sends multiple options. Why not have the server reply with
> > the
> > selected username.
>
> More compact and makes the option where server sends some bad option
> more clear.
I'm not sure about being more clear. What I immediately notice is that
it requires the client to remember not only the values that it sent,
but also the indexes. I guess that's no big deal, but it is used
nowhere else in TLS.
> > 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.
regards,
Nikos
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 + PSK with multiple identities
On Mon, Aug 08, 2016 at 10:17:40AM +0200, Nikos Mavrogiannopoulos wrote: > Hello, > I'm reading the "Pre-Shared Key Extension" section of the TLS 1.3 > draft [0], and I noticed quite some deviations (IMO) from typical TLS > protocol behavior. No rationale is given about them so I ask on list. > > To summarize, the client sends a list of identitities and the server > replies with an index indicating which identity is approved. > > 1. The server reply with an index is unique in TLS. It is not used in > ciphersuite selection or in any other negotiation in TLS where the > client sends multiple options. Why not have the server reply with the > selected username. More compact and makes the option where server sends some bad option more clear. > 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). Additionally, TLS 1.2 had identity hint, but TLS 1.3 eliminates that due to flight limits. > 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. [1] IMO, TLS 1.3 does not have session resumption (doesn't stop others from calling the relevant features "resumption"). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
