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) <ofr...@cisco.com> wrote: > > > > -----Original Message----- > > From: Jonathan Hoyland <jonathan.hoyl...@gmail.com> > > Sent: 19 September 2019 14:32 > > To: Owen Friel (ofriel) <ofr...@cisco.com> > > Cc: Martin Thomson <m...@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: > ofr...@cisco.com> > > wrote: > > > > > -----Original Message----- > > > From: TLS <mailto:tls-boun...@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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
