On Thu, Sep 19, 2019 at 10:26 AM Jonathan Hoyland < [email protected]> wrote:
> 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. > I don't think that's quite right. The PSKs resulting from NewSessionTicket have a defined structure, but the PSK *IDs* do not; they're specified by the server. AFAICT, existing server stacks generate their own PSK IDs for resumption PSKs, so from the application's perspective, the structure of the resumption PSKs is unknown (or at best, specific to the TLS library in use). If I understand correctly, the worst case here would be: 1. The server application wants to have some behavior change based on the use of an external PSK (not resumption) 2. The server TLS stack is configured with external and resumption PSKs with the same PSK ID 3. The client sends a ClientHello using the resumption PSK 4. The server TLS stack attempts to verify the binder with the resumption PSK and succeeds 5. The server application gets a session that is authenticated with the PSK ID and notes that the PSK ID matches one of its external PSKs 6. The server application improperly does the external PSK behavior when in fact resumption has happened I might be missing something, but I don't see anything in the spec that would prevent this situation from arising. So it's up to the application to choose its PSK IDs in such a way that they don't collide with resumption PSK IDs. But the fact that resumption PSK IDs are implementation-specific mean that this is tough to do with any generality, unless you're willing to rely on long pseudorandom strings not colliding with each other. Maybe the answer is just that TLS stacks that handle their own resumption caches need to signal to applications when that cache has been used vs. an external PSK. --Richard > Regards, > > Jonathan > > On Thu, 19 Sep 2019 at 15:04, Owen Friel (ofriel) <[email protected]> > wrote: > >> >> >> > -----Original Message----- >> > From: Jonathan Hoyland <[email protected]> >> > Sent: 19 September 2019 14:32 >> > To: Owen Friel (ofriel) <[email protected]> >> > Cc: Martin Thomson <[email protected]>; [email protected] >> > 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: >> [email protected]> >> > wrote: >> > >> > > -----Original Message----- >> > > From: TLS <mailto:[email protected]> On Behalf Of Martin Thomson >> > > Sent: 04 September 2019 02:46 >> > > To: mailto:[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- >> <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:[email protected] >> > https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
