On Fri, 2018-07-20 at 08:42 -0400, David Benjamin wrote: > > > 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. :-) I wouldn't expect much from formal analysis here, though in the past I've been positively surprised. I'd expect "don't mix algorithms", as with RSA and RSA-PSS. > > 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. The derivation makes sense to be part of the draft. It makes sense to me the whole draft to be part or referred from TLS1.3. regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
