Re: [TLS] TLS 1.3 multiple PSKs (was session tickets) from the client?

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

> -----Original Message-----
> From: TLS <tls-bounces@ietf.org> On Behalf Of Martin Thomson
> Sent: Thursday, May 10, 2018 5:31 PM
> To: <tls@ietf.org> <tls@ietf.org>
> Subject: Re: [TLS] TLS 1.3 multiple PSKs (was session tickets) from the
client?
> 
> On Fri, May 11, 2018 at 9:08 AM Viktor Dukhovni <ietf-dane@dukhovni.org>
> wrote:
> >   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?
> 
> 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.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls