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.

Does that answer your question?

Regards,

Jonathan

On Thu, 19 Sep 2019 at 11:52, Owen Friel (ofriel) <[email protected]> wrote:

>
> > -----Original Message-----
> > From: TLS <[email protected]> On Behalf Of Martin Thomson
> > Sent: 04 September 2019 02:46
> > To: [email protected]
> > 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls

Reply via email to