Agreement on a channel binding in the identity would prove, amongst other things, agreement on the KDF used to derive the PSK, whereas the TLS handshake proves agreement on the PSK itself, but says nothing about the derivation of it. This way means you don't have to worry about collisions between hash functions, as long as the channel binding is correctly constructed.
Because TLS 1.3 doesn't have an explicit interface for accepting channel bindings this isn't the most elegant of solutions, but I think it would at least fix the issue where the KDF used changes between the place where the PSK is generated and where it is used. I'm not sure I understand your point about formal analysis. Formal analysis's main strength is that is can consider all the possible interactions between use cases. Channel bindings are in fact designed for this exact purpose, to securely connect the values established in one protocol to the values used in another. More specifically they prove that the peer in the earlier run is the same actor as in the later run, and further that all values established in _both_ protocols are agreed upon, including which KDF was used in the earlier PSK establishing run. Using this method, you wouldn't take a PSK directly from TLS 1.2, you would transform it before using it in TLS 1.3, by changing the identity. You could also update the key at that point, by putting it through the KDF from TLS. That would give you a new <identity, key> pair that fixes the issue without requiring changes to the TLS key schedule. This ends up being very similar to the draft in terms of code, it merely separates the cases neatly, moving the entire transformation to before the TLS run, meaning the TLS key schedule doesn't need tweaking. You won't have one identity with two potential keys / key derivations, as in the current draft, you would have two distinct <identity, key> pairs, and by accepting the transformed one the server indicates that it understands the transformation. This makes it easier to migrate from one method to the other, because you could offer both keys to servers where you were unsure of support, and would learn about support based on its choice. Regards, Jonathan On Fri, 15 Jun 2018 at 15:57 David Benjamin <david...@chromium.org> wrote: > On Fri, Jun 15, 2018 at 7:37 AM Nikos Mavrogiannopoulos <n...@redhat.com > <n...@redhat..com>> wrote: > >> On Thu, 2018-06-14 at 15:46 -0400, David Benjamin wrote: >> > Hey all, >> > >> > So TLS 1.2 has a mechanism for PSKs. We attempted to mirror it in TLS >> > 1.3 via the external PSK mechanism, repurposing the resumption flow. >> > But the security proof requires PSKs be associated with a specific >> > hash for key separation. We use distinguishing labels in the key >> > schedule, but if that key is fed into a completely different KDF, >> > analysis must additionally consider interactions between the KDFs. >> > >> > The hash constraint, however, makes it difficult to actually use >> > external PSKs in applications. Usually the TLS stack and its >> > configuration evolves somewhat independently from the calling >> > application. But now the PSK provisioning process must short-circuit >> > part of the TLS parameter negotiation, despite it likely being >> > implemented in a separate library altogether. This is a leaky >> > abstraction. >> > >> > It also complicates server parameter selection. We've found the >> > cleanest algorithm is selecting the cipher suite first, and then >> > ignoring the PSKs that don't match. This is simple and avoids weird >> > behavior if a session is renewed across preference changes. However, >> > this only works for resumption PSK: if the session mismatches, a full >> > handshake is always an option. With external PSKs, the application >> > usually expects the PSK to be mandatory. >> >> > Finally, some libraries (e.g. OpenSSL) already TLS 1.2 PSK APIs and >> > wish to transparently upgrade to TLS 1.3. The specification does not >> > explicitly say if a TLS 1.2 PSK may be used directly as a TLS 1.3 PSK >> > and I believe some implementations are doing that. However that >> > violates TLS 1.3's key separation assumptions in the same way as >> > mixing hashes: the TLS 1.2 PRF is not the same as HKDF. >> >> I don't think that TLS1.3 has strict key separation assumptions, and >> they are nowhere spelled out. For example, RSA keys can be used for >> RSA-PSS or RSA PKCS#1 1.5 signatures or RSA encryption. >> > > I think it's a little more complex than that. Keys used in multiple ways > are affected by interactions between those uses, so formal analysis tends > to want to exclude these cases. So, yes, ideally we would separate every > key everywhere. But, as Hubert notes elsewhere in the thread, we wish for > the TLS 1.3 upgrade to be as smooth as possible, which includes being able > to reuse any externally-provisioned keys (RSA, symmetric, or whatever). > These two desires are in tension. > > For stuff like RSA, we don't have easy ways around this. If you have an > id-rsaEncryption key---which is common---that's what you've got. So the RFC > 4055 and TLS 1.3, for practicality's sake, allow this. > > For symmetric keys, we have more flexibility in playing games deriving > keys with labels. The entire TLS 1.3 key schedule is a tower of this stuff. > To that end, TLS 1.3 *does* include a hash-matching requirement for PSKs. > > However, in doing so, we failed to account for similar practicalities with > external PSKs, both with existing TLS 1.2 PSKs and also clean abstractions > for new uses. This draft is an attempt to fix this. > > >> > It's a bit late to completely redo external PSKs in 1.3, but I >> > believe we can fix this in a separate draft. The draft below proposes >> > "universal PSKs" which derive independent hash- and version-specific >> > secrets for TLS 1.3 (and later) as needed. For existing TLS 1.2 PSKs, >> > it includes a compatibility derivation to go from TLS 1.2 PSKs to >> > universal PSKs. >> > >> > (Thanks to Karthikeyan Bhargavan, Matt Caswell, Eric Rescorla, and >> > Victor Vasiliev for discussions which led to this design. Any >> > mistakes in it are mine.) >> > >> > Thoughts? >> >> It feels that's this is too little too late. Implementations which >> support PSKs will switch to TLS1.3 irrespective of this proposal. If >> this proposal takes on, we will have some implementations which support >> universal PSKs and others which don't leading to interoperability >> problems which we wouldn't have otherwise. >> > > Right, I think that's why we should get a quick clarification in the spec > that 1.2 PSKs shouldn't be used directly in 1.3 and a fix for this is > forthcoming in a later document. (Assuming, of course, we all conclude that > is how we want to do this. I chatted with Karthik about some of this when > writing the draft, but I certainly may messed things up or misunderstood > something!) > _______________________________________________ > 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
