Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3

[Nikos Mavrogiannopoulos <[e-mail]>]

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