Re: [TLS] Universal PSKs

[David Benjamin <[e-mail]>]

On Fri, Jun 15, 2018 at 7:37 AM Nikos Mavrogiannopoulos <[e-mail]>
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!)