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 <say...@gmail.com> wrote: > On Tue, Nov 5, 2019 at 6:03 PM Salz, Rich <rs...@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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
