On Fri, Jul 20, 2018 at 7:39 AM Nikos Mavrogiannopoulos <n...@redhat.com> wrote:
> On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote: > > > > > > > This is somewhat timely, as if we do want to introduce a > > > restriction, > > > > it > > > > would ideally be in the form of some text in the TLS 1.3 > > > > specification, > > > > which is very nearly done. > > > > > > > > It would be good to hear more opinions on this question, > > > particularly > > > > from those who have worked on the formal verification directly. > > > > > > > > If I can attempt to summarize some discussion that occurred in > > > the > > > > mic > > > > line today, Hannes was surprised that we would care, likening > > > this > > > > case > > > > to the regular version negotiation, where we are happy to use the > > > > same > > > > certificate to sign messages for both TLS 1.2 and 1.3. David > > > > Benjamin > > > > points out that we explicitly go to the trouble of putting 64 > > > bytes > > > > of > > > > 0x20 padding at the front of the content that gets signed for > > > > CertificateVerify, to enforce separation between the TLS > > > versions. > > > > > > > > My own personal opinion is that we should enforce a domain > > > separation > > > > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's > > > "Universal > > > > PSKs" > > > > proposal seems like a potential mechanism by which to do so > > > without > > > > doubling the provisioning needs. > > > > > > I think the same rules should apply for PSK and RSA/ECDSA/EdDSA > > > keys. > > > There is no inherent difference between the two keys types. I could > > > have deployed TLS with PKI or TLS with PSK. I should be able to > > > upgrade > > > protocols the same way. > > > > > > If RSA keys can be re-used between TLS1.2 and TLS1.3, then so > > > should > > > PSK keys. The current document specifically allows that re-use, and > > > if > > > you fear that the current document did not take cross-protocol > > > attacks > > > in mind during design, then let's fix that instead. > > > > The issue is not cross-protocol attacks; it's the reuse of PSKs with > > different KDFs, which we don't have any analysis for > > I understand, but as I have already mentioned that argument also > applies for RSA keys which can be used e.g., for RSA encryption under > TLS1.2 and for RSA-PSS signatures under TLS1.3. ECDSA keys can be used > with multiple hashes under TLS1.2 while only one under TLS1.3. > TLS 1.3 did not enforce protocol separation for that ugly scenario, so > I wouldn't expect the treatment of PSKs differently. > PSKs are much easier to fix this with than signing algorithms, given that we don't want to reprovision either to deploy TLS 1.3. ECDSA in TLS didn't get worse with TLS 1.3. We didn't add a new hash to mixup, just restricted the set from TLS 1.2. If we left it alone, we'd still have the same effect. For RSA, you're right that we introduced an extra pair of algorithms to worry about. The options there are: (1) Add PSS, forbid PKCS1, and forbid PSS with id-rsaEncryption. Cost: TLS 1.3 requires reprovisioning RSA keys. (2) Add PSS, forbid PKCS1, but allow PSS with id-rsaEncryption. Cost: We have two algorithms with one key. (3) Don't forbid PKCS1. Cost: We don't get rid of PKCS#1. (1)'s cost is clearly fatal, given 1.3's goals. I'm personally fine with either (2) or (3), but the WG chose (2). With PSKs, I think we can get both. If we consider 1.2 PSKs to be paired with the 1.2 PRF, we can allocate a new label, and derive a separate thing to stick in 1.3, and not require reprovisioning. It's basically free, so I think it makes sense to do it. (I suspect using the same key with TLS1.2-PRF-SHA256 and HKDF-SHA256 is probably *more* risky than mixing HKDF-SHA256 and HKDF-SHA384. I don't think we actually believe SHA256 and SHA384 give related output. It's just nice to avoid the assumption. Whereas TLS1.2-PRF-SHA256 and HKDF-SHA256 actually a chance of misbehavior. Perhaps it's worth doing that analysis?) Of course, I don't actually know what I'm talking about. Opinions from the formal analysis folks would be great. :-) > Said that, I want to clarify that I wouldn't necessarily object to an > improvement the situation for externally established PSKs. The issue I > see is that TLS1.3 already gives a "good enough" solution with re-using > the key, and I'm afraid we're going to have interoperation issues if > some implementations move to universal psks and some do not, defeating > the purpose of a standard. > I think that's the point of deciding this immediate question now, so we can get some text in the specification. If we decide to fix this, we'd instruct implementations to (temporary!) turn off TLS 1.3 if 1.2 PSKs are configured and then, once the fixup document is published, implement it and remove the version logic. This is interoperable at all combinations as version negotiation runs first. Personally, I actually don't care much about 1.2 PSKs as I don't work with anything that uses them. I do care about allowing new protocols to use 1.3 external PSKs cleanly---new protocols can just mandate 1.3 and avoid 1.2, but the hash rule makes the whole thing unusable and it is unclear whether 1.3 PSKs will be usable in a future 1.4. I figured it'd be easy to patch the 1.2 issue while I was at it, thus the construction in my draft. But the exact derivation can be worked out separately, my draft or not. The immediate question is whether we think 1.2 PSKs should be reusable in 1.3 as-is or whether we should stick a derivation step to separate them. (Thanks, Ben, for making this thread. I failed to call out the immediate question in mine and then didn't had time to catch up on it.) David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
