Ah yes, Richard is right, the PSK IDs do not have a defined structure. Having two different PSKs attached to a single PSK_ID should be banned if it isn't already.
Regards, Jonathan On Thu, 19 Sep 2019 at 16:26, Richard Barnes <r...@ipv.sx> wrote: > On Thu, Sep 19, 2019 at 10:26 AM Jonathan Hoyland < > jonathan.hoyl...@gmail.com> 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) <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- >>> <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 >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
