Re: [TLS] Distinguishing between external/resumption PSKs

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 <rlb@ipv.sx> wrote:

> On Thu, Sep 19, 2019 at 10:26 AM Jonathan Hoyland <
> jonathan.hoyland@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) <ofriel@cisco.com>
>> wrote:
>>
>>>
>>>
>>> > -----Original Message-----
>>> > From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
>>> > Sent: 19 September 2019 14:32
>>> > To: Owen Friel (ofriel) <ofriel@cisco.com>
>>> > Cc: Martin Thomson <mt@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:
>>> ofriel@cisco.com>
>>> > wrote:
>>> >
>>> > > -----Original Message-----
>>> > > From: TLS <mailto:tls-bounces@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
>>
>