Re: [TLS] Distinguishing between external/resumption PSKs

That's how I would interpret the spec yes.
You could argue that there's a distinguishing attack where the attacker
measures the response time on PSKs to determine if it was an OOB PSK or a
resumption, but I think you could do equally well just by looking at the
PSK lengths, because resumption PSKs have a defined structure.

Regards,

Jonathan

On Thu, 19 Sep 2019 at 15:04, Owen Friel (ofriel) <ofriel@cisco.com> wrote:

>
>
> > -----Original Message-----
> > From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
> > Sent: 19 September 2019 14:32
> > To: Owen Friel (ofriel) <ofriel@cisco.com>
> > Cc: Martin Thomson <mt@lowentropy.net>; tls@ietf.org
> > Subject: Re: [TLS] Distinguishing between external/resumption PSKs
> >
> > Hi Owen,
> >
> > If I understand your question correctly the distinguishing is done
> implicitly
> > (not explicitly) through the key schedule.
> > If the client and server do not agree on whether the PSK is a resumption
> or
> > an OOB PSK then the `binder_key` will not match, and the handshake will
> fail.
> >
> > See pp. 93-94 of the spec.
>
> And we only even get that far on the off chance that an ext
> PskIdentity.identity is exactly the same as a res PskIdentity.identity.
> e.g. a client presents an ext PskIdentity.identity, the server somehow
> thinks it’s a res PskIdentity.identity, and then handshaking will fail, not
> only because the actual raw PSK is likely different but the binders will
> not match due to different labels.
>
> But my question was before we even get that far - its an internal server
> implementation decision how it determines whether the presented
> PskIdentity.identity is ext or res, or whether e.g. to try lookup an ext DB
> table vs. a res cache first to find a PskIdentity.identity match. And say
> it fails to find an ext match then it tries to find a res match, and if it
> finds a match, then it knows what binder label to use.
>
>
> >
> > Does that answer your question?
> >
> > Regards,
> >
> > Jonathan
> >
> > On Thu, 19 Sep 2019 at 11:52, Owen Friel (ofriel) <mailto:
> ofriel@cisco.com>
> > wrote:
> >
> > > -----Original Message-----
> > > From: TLS <mailto:tls-bounces@ietf.org> On Behalf Of Martin Thomson
> > > Sent: 04 September 2019 02:46
> > > To: mailto:tls@ietf.org
> > > Subject: Re: [TLS] Binder key labels for imported PSKs
> > >
> > >
> > > When we built the ext/res distinction, there was a clear problem
> > expressed.
> > > We had the potential for both to be used by the same servers at the
> same
> > > time (though not for the same connection) and distinguishing between
> > them
> > > was important
> >
> > Martin, maybe I am missing something in the threads on this. Is there
> > anything explicit planned in ClientHello PreSharedKeyExtension or
> > PskKeyExchangeModes to explicitly distinguish between ext/res PSKs? Or is
> > it up to server implementation and how the server handles the opaque
> > PskIdentity.identity? e.g. ImportedIdentity.external_identity fields
> could be
> > stored in one DB table, and (ignoring
> https://tools.ietf.org/html/draft-ietf-
> > tls-external-psk-importer-00#section-9 for now) the server on receipt of
> a
> > ClientHello searches for PskIdentity.identity in its
> > ImportedIdentity.external_identity  table and if that lookup fails, then
> try to
> > parse PskIdentity.identity  as a NewSessionTicket.ticket? And the order
> of
> > those two operations is of course implementation specific too.
> >
> >
> > _______________________________________________
> > TLS mailing list
> > mailto:TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>