Subject: [TLS] TLS 1.3 multiple session tickets from the client?

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 May 2018 00:10:40 -0400

TLS 1.3 allows clients to send multiple PSK identities, with the server
choosing one.  When, if every, might it make sense for the client to
send multiple session tickets to the server?  If this is not expected,
is it sufficiently odd for a server to ignore any tickets after the
first (if that one is not usable)?

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 May 2018 09:23:14 +0000

> first (if that one is not usable)?

NSS only looks at the first PSK offered by clients.  That is because we
primarily use PSK for session resumption.  I think that others do the
same.  I don't think that it makes a whole lot of sense to attempt to use
multiple PSKs in the context of resumption.

The option for multiple PSKs is something that is used in pure PSK modes,
but I confess to not fully understanding the reasons you might use multiple
PSKs.  I suspect that they are most useful during a key rollover.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 May 2018 04:48:26 -0700

> PSKs.  I suspect that they are most useful during a key rollover.

Also, resumption of sessions created with PSKs

-Ekr

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 May 2018 09:46:44 -0400

> On May 10, 2018, at 7:48 AM, Eric Rescorla <[email-masked]> wrote:
> 

So I am not hearing any intent to support multiple resumption PSKs
(session tickets) in the same handshake.

How are TLS 1.3 server implementations approaching distinguishing
between external PSK identities and (RFC5077) resumption PSKs, so
that one does not end up looking for RFC5077 key names to decrypt
an external PSK, or pass resumption PSKs to the code that implements
external PSKs?

Do you prepend some new "magic" to the (RFC5077 or similar) session
tickets?  Or just look for a matching STEK key name and let that be
the "magic"?

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 May 2018 07:17:56 -0700

> tickets?  Or just look for a matching STEK key name and let that be

I would imagine, but NSS, at least, doesn't support external PSKs.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 May 2018 11:46:40 -0400

> On May 10, 2018, at 10:17 AM, Eric Rescorla <[email-masked]> wrote:
> 

Good to know.  Does any implementation other than OpenSSL support
external PSKs?  How do you distinguish between external PSKs and
resumption PSKs?

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 May 2018 08:53:01 -0700

> external PSKs?  How do you distinguish between external PSKs and

Mint does, but it doesn't implement session tickets, so they're just in one
giant database.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 May 2018 13:28:45 -0400

> On May 10, 2018, at 11:46 AM, Viktor Dukhovni <[email-masked]> wrote:
> 

So no need to distinguish in either NSS or Mint.  Anyone else?

On a related note, should a client sending both a resumption and
an external PSK place the resumption PSK first in the list of
PSK identities?  My concern is that server implementations might
otherwise recognize the external PSK first, and then not even
look at the resumption PSK.  Is that a valid concern?

Should server implementations first see if any of the PSKs
are resumption PSKs before considering the rest?

-- 
	Viktor.

---

From: Jim Schaad <[email-masked]>
Date: Thu, 10 May 2018 15:57:01 -0700

> -----Original Message-----
> From: TLS <[email-masked]> On Behalf Of Viktor Dukhovni
> Sent: Thursday, May 10, 2018 8:47 AM
> To: TLS WG <[email-masked]>
> Subject: Re: [TLS] TLS 1.3 multiple session tickets from the client?
> 
> 
> 

This is going to be a lot more common with DTLS implementations.  I am not
sure how much resumption is going to be used for those cases.

Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 May 2018 19:08:11 -0400

> On May 10, 2018, at 1:28 PM, Viktor Dukhovni <[email-masked]> wrote:
> 

Perhaps a better question is:

 Should servers issue resumption tickets after an initial PSK handshake?
 And if so, should resumption be preferred for any reason when the client
 sends both a resumption ticket and the external PSK?

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 May 2018 10:31:11 +1000

>   sends both a resumption ticket and the external PSK?

I don't think that we can codify anything here, but the angle I approach
this from is in terms of what safeguards are placed on keys.

Ticket keys are typically stored in volatile or temporary storage with
their relatively brief validity interval being the primary safeguard
against theft.  That makes them easy to use, but they are consequently
unusable over long periods of time.

If an external PSK has a need to be viable over longer periods, then
perhaps you want to use it less often.  That might be to avoid having to
load it into memory and risk it being readable, or it might be because the
controls on its use are more onerous.  For instance, some might require
user input (for a PIN or the like), or have a performance cost involved in
access.

All speculation, but there you go.

---

From: Jim Schaad <[email-masked]>
Date: Thu, 10 May 2018 18:31:47 -0700

After thinking about this for a while, I would expect that sending an
external PSK w/ a ticket should be rare for those systems that are going to
want to do privacy protection.  Sending the external PSK would allow for
association of sessions that should not happen with just the ticket.

Jim

> From: TLS <[email-masked]> On Behalf Of Martin Thomson
> Sent: Thursday, May 10, 2018 5:31 PM
> To: <[email-masked]> <[email-masked]>
> Subject: Re: [TLS] TLS 1.3 multiple PSKs (was session tickets) from the
client?
> I don't think that we can codify anything here, but the angle I approach
this
> from is in terms of what safeguards are placed on keys.
> 
their
> relatively brief validity interval being the primary safeguard against
theft.
> That makes them easy to use, but they are consequently unusable over long
> periods of time.
> 
perhaps
> you want to use it less often.  That might be to avoid having to load it
into
> memory and risk it being readable, or it might be because the controls on
its
> use are more onerous.  For instance, some might require user input (for a
> PIN or the like), or have a performance cost involved in access.
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 11 May 2018 09:05:51 +0200

> external PSKs?  How do you distinguish between external PSKs and

gnutls does. For external PSKs It checks for ticket age being zero and
the username/identity within acceptable bounds.

regards,
Nikos

---

From: Hubert Kario <[email-masked]>
Date: Fri, 11 May 2018 13:14:26 +0200

> external PSKs?  How do you distinguish between external PSKs and

tlslite-ng does, but it is vulnerable to the enumeration attacks

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Hubert Kario <[email-masked]>
Date: Fri, 11 May 2018 13:22:43 +0200

> look at the resumption PSK.  Is that a valid concern?

I'd say so, the server should use the first identity for which the binder 
validates.
 
> are resumption PSKs before considering the rest?

all the value lists sent by client are supposed to be sorted by willingness to 
use by client, most wanted first

I don't see why PSK's shouldn't be like this too.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Ander Juaristi <[email-masked]>
Date: Wed, 16 May 2018 11:30:45 +0200

> the username/identity within acceptable bounds.

Hey Nikos,

I remember we had this discussion, but wanted to transfer it to the list 
as even though I believe that approach
will work almost always, by reading the current draft my understanding 
is that being the ticket age zero is no more than a hint
that it *might* be a PSK.

What's wrong with trying to decrypt it first and then if decryption 
fails treat it as an external PSK and look up
its identity in the database? GnuTLS encrypts the tickets with EtA so 
with "decrypt" I mean checking the MAC first,
and then decrypting. Isn't this a stronger check?

These and all the other mentioned checks are not mutually exclusive. You 
could check the ticket key name first before
even trying to verify the MAC to discard malformed tickets very early in 
the game.

Another option to remove some ambiguity out of here would just be to 
change the draft to say that externally set PSKs
MUST have a ticket age of zero (rather than SHOULD). This way a server 
can instantly recognize an external PSK. A real
ticket can never have an obfuscated ticket age of zero, right? Or it 
can?

I'm curious to hear what folks here think is wrong with either approach.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 17 May 2018 16:08:56 +0200

> and then decrypting. Isn't this a stronger check?

Decrypting a ticket may not always be possible. For example, server
keys may get rotated, or a server may receive key which were destined
for another server in the pool.

> ticket can never have an obfuscated ticket age of zero, right? Or it 

I think that ticket age could be zero even for non-preshared keys (not
very likely though).

A field which could potentially be used to distinguish tickets is the
key_name of an rfc5077 formatted ticket.

regards,
Nikos