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-boun...@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-d...@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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
