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

[David Benjamin <[e-mail]>]

On Fri, Jul 20, 2018 at 7:39 AM Nikos Mavrogiannopoulos <[e-mail]>
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