There is also a privacy angle. From a privacy point of view, it is very nice that PSK cannot be distinguished from session resumption.
-- Christian Huitema > On Sep 19, 2019, at 5:57 AM, Richard Barnes <[email protected]> wrote: > > As nice as that requirement would be, I'm not sure it's really compatible > with the way people want to build software. For example, OpenSSL right now > gets external PSKs by calling out to an external callback. Given that degree > of separation, proactively assuring no collisions would be hard. > >> On Thu, Sep 19, 2019 at 11:43 AM Jonathan Hoyland >> <[email protected]> wrote: >> 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 <[email protected]> wrote: >>>> 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- >>>>> > 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
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
