Re: [TLS] Binder key labels for imported PSKs

Hi Rob,

The situation we are trying to prevent is when both the client and server
think they have completed a handshake with each other, but disagree on what
happened.
In this case, for example, the client might have used a PSK importer, but
the server might believe the client has used a vanilla PSK.

This type of mismatch can lead to channel synchronization attacks, where an
attacker establishes two separate sessions, one with the client and one
with the server, that both have the same key.
There were attacks on early drafts of TLS 1.3 that you can describe in this
way (e.g. the triple handshake attack
<https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6956559> or the
attack on draft-10+
<https://tls13tamarin.github.io/TLS13Tamarin/docs/tls13tamarin.pdf>.).
Especially if we use later extend this mechanism to chain together
different imports we could introduce subtle and difficult to detect flaws.
This change reduces the potential for this type of problem.

A more direct reason for this change is to do with the goals of TLS 1.3.
One of the properties TLS 1.3 tries to provide (see appendix E.1 [p. 143])
is "Uniqueness of the Session Keys".
Without this change a client using a vanilla PSK that happens to have the
same PSK_ID and key as an imported PSK would produce the same session keys
as a client using the equivalent imported PSK.
This violates the desired property.

Does that make things clearer?

Regards,

Jonathan

On Wed, 6 Nov 2019 at 02:08, Rob Sayre <sayrer@gmail.com> wrote:

> On Tue, Nov 5, 2019 at 6:03 PM Salz, Rich <rsalz@akamai.com> wrote:
>
>> > Do people agree that we want to prevent PSK Importers from being
>> confused with standard OOB PSKs and that we should do this by changing the
>> label used in the computation of the PSK binder key?
>>
>> Obviously.
>>
>
> For the slower folks on the list, such as myself, could someone explain
> why confusing these two types of PSKs would be bad?
>
> thanks,
> Rob
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>