Subject: [TLS] Universal PSKs

From: David Benjamin <[email-masked]>
Date: Thu, 14 Jun 2018 15:46:27 -0400

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.

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? If the WG likes this design, I would suggest:

- Most folks who want to use TLS 1.3 with external PSKs should probably
design their protocols to provision universal PSKs instead, after it
stabilizes.

- Folks who want to use TLS 1.3 with existing TLS 1.2 PSKs should use the
compatibility derivation in this draft, after it stabilizes.

- Folks who want to ship TLS 1.3 before then and have a TLS 1.2 PSK API
should not use the 1.2 PSK as a 1.3 PSK. For now, just turn TLS 1.3 off by
default if that API is used and, in a future release, use the compatibility
derivation after it stabilizes.

- If it's not too late to clarify whether TLS 1.3 believes whether PSKs are
version-specific, it would be good to do that.

David

PS: Looking over the draft now, I see I mixed up some of the RFC 4279 and
RFC 5246 citations. I'll fixed that in the next iteration.

---------- Forwarded message ---------
From: <[email-masked]>
Date: Thu, Jun 14, 2018 at 3:21 PM
Subject: New Version Notification for
draft-davidben-tls-universal-psk-00.txt
To: David Benjamin <[email-masked]>

A new version of I-D, draft-davidben-tls-universal-psk-00.txt
has been successfully submitted by David Benjamin and posted to the
IETF repository.

Name:           draft-davidben-tls-universal-psk
Revision:       00
Title:          Universal PSKs for TLS
Document date:  2018-06-14
Group:          Individual Submission
Pages:          7
URL:
https://www.ietf.org/internet-drafts/draft-davidben-tls-universal-psk-00.txt
Status:
https://datatracker.ietf.org/doc/draft-davidben-tls-universal-psk/
Htmlized:
https://tools.ietf.org/html/draft-davidben-tls-universal-psk-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-davidben-tls-universal-psk

Abstract:
   This document describes universal PSKs (Pre-Shared Keys) for TLS.
   Universal PSKs abstract the TLS 1.3 requirement that each PSK can
   only be used with a single hash function.  This allows PSKs to be
   provisioned without depending on details of the TLS negotiation,
   which may change as TLS evolves.  Additionally, this document
   describes a compatibility profile for using TLS 1.3 with PSKs
   provisioned for the TLS 1.2 PSK mechanism.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Hubert Kario <[email-masked]>
Date: Fri, 15 Jun 2018 13:14:09 +0200

> derivation after it stabilizes.

that's not workable.

the reason why implementations chose to use old API to provision TLS 1.3 PSKs 
was to make the upgrade process as smooth as possible, disabling TLS 1.3 is 
quite antithetical to that

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 15 Jun 2018 13:37:53 +0200

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.

> 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.

regards,
Nikos

---

From: Matt Caswell <[email-masked]>
Date: Fri, 15 Jun 2018 13:00:17 +0100

> problems which we wouldn't have otherwise.

I'm not sure how many TLS1.3 implementations there are out there that
also have TLS1.2 PSK support. OpenSSL is one of them. We have APIs for
TLS1.2 PSKs and different APIs for TLS1.3 PSKs. Currently applications
using the old APIs can still expect those PSKs to work in TLS1.3. In
light of this proposal we are considering removing our TLS1.2 -> TLS1.3
PSK code and instead restricting applications using TLS1.2 PSK APIs to
only TLS1.2 until this is resolved (although unfortunately that would
mean removing it from our upcoming LTS release).

Matt

---

From: David Benjamin <[email-masked]>
Date: Fri, 15 Jun 2018 09:11:48 -0400

> quite antithetical to that

Indeed. That is why the TLS 1.2 compatibility section exists. :-) So that
implementations in that position can reuse TLS 1.2 PSK APIs in TLS 1.3
while honoring the security proof.

But, unfortunately, there's a slight timing issue. There's no way some
random draft published yesterday will be finalized before TLS 1.3. So
implementations with TLS 1.2 PSK APIs would need to either violate the TLS
1.3 security proof or not ship TLS 1.3 until this draft finalizes.

Neither seems great, so turning TLS 1.3 for PSK users in the initial TLS
1.3 implementation releases seems a reasonable stopgap approach, until the
solution for this issue is finalized, at which point a latter release can
enable TLS 1.3 across the board.

David

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 15 Jun 2018 14:24:58 +0000

>    that's not workable.
  
It's not great, however

Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect most uses, and seems the only way forward.

Do you have an alternative solution?

---

From: Jonathan Hoyland <[email-masked]>
Date: Fri, 15 Jun 2018 16:52:30 +0200

Is it not possible to construct a channel binding for whatever underlying
protocol was used to agree the PSK and use that as the PSK identity.
If the PSK was created in TLS 1.2 then that would be something derived from
`tls-unique`.

The security of a channel binding is not dependent on it being secret, and
thus using it as the PSK identity is safe.

Doing this would prove agreement on the KDF used, and would be bound to the
handshake by the PSK binders.
Assuming that the KDF was something acceptably secure, this would mitigate
the risk of collisions between hash outputs, because which hash function
was used to produce the PSK would be an agreed value.

That would also require no changes to the key schedule, which is perhaps
lower risk.

This of course assumes that both parties agree that this is how the PSK
identity was constructed,  so it would probably need an extension.

Regards,

Jonathan

On Fri, 15 Jun 2018 at 15:25 Salz, Rich <rsalz=[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: David Benjamin <[email-masked]>
Date: Fri, 15 Jun 2018 10:56:48 -0400

> 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.

> 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!)

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 15 Jun 2018 18:19:20 +0300

> 4055 and TLS 1.3, for practicality's sake, allow this.

I once calculated that it is extremely unlikely that there exists _any_
RSA plaintext that is valid signature (for possibly different messages)
as both RSA PKCS#1 v1.5 and RSA-PSS.

This is regardless of if such plaintext would be feasible to find or if
it was feasible to find one or both of the messages it signs.

However, straight out collision might not be realistic model of this. But
on the other hand, with hashes collision resistance of both hashes does not
imply one can not feasbily find cross-collisions or even cross-second-
preimages.

-Ilari

---

From: Jonathan Hoyland <[email-masked]>
Date: Fri, 15 Jun 2018 17:26:33 +0200

Agreement on a channel binding in the identity would prove, amongst other
things, agreement on the KDF used to derive the PSK, whereas the TLS
handshake proves agreement on the PSK itself, but says nothing about the
derivation of it.
This way means you don't have to worry about collisions between hash
functions, as long as the channel binding is correctly constructed.

Because TLS 1.3 doesn't have an explicit interface for accepting channel
bindings this isn't the most elegant of solutions, but I think it would at
least fix the issue where the KDF used changes between the place where the
PSK is generated and where it is used.

I'm not sure I understand your point about formal analysis.
Formal analysis's main strength is that is can consider all the possible
interactions between use cases.
Channel bindings are in fact designed for this exact purpose, to securely
connect the values established in one protocol to the values used in
another.
More specifically they prove that the peer in the earlier run is the same
actor as in the later run, and further that all values established in
_both_ protocols are agreed upon, including which KDF was used in the
earlier PSK establishing run.

Using this method, you wouldn't take a PSK directly from TLS 1.2, you would
transform it before using it in TLS 1.3, by changing the identity.
You could also update the key at that point, by putting it through the KDF
from TLS.
That would give you a new <identity, key> pair that fixes the issue without
requiring changes to the TLS key schedule.
This ends up being very similar to the draft in terms of code, it merely
separates the cases neatly, moving the entire transformation to before the
TLS run, meaning the TLS key schedule doesn't need tweaking.

You won't have one identity with two potential keys / key derivations, as
in the current draft, you would have two distinct <identity, key> pairs,
and by accepting the transformed one the server indicates that it
understands the transformation.
This makes it easier to migrate from one method to the other, because you
could offer both keys to servers where you were unsure of support, and
would learn about support based on its choice.

Regards,

Jonathan

On Fri, 15 Jun 2018 at 15:57 David Benjamin <[email-masked]> wrote:

> On Fri, Jun 15, 2018 at 7:37 AM Nikos Mavrogiannopoulos <[email-masked]
> <nmav@redhat..com>> wrote:
>
> 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.
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 15 Jun 2018 11:13:52 -0500

> functions, as long as the channel binding is correctly constructed.

While this is an interesting way to think about things, it's unclear to me
how general it is for framing the problem.  That is to say, there is not
necessarily a "channel" used to provision what TLS 1.3 calls "external PSKs".
My model for them includes an administrator typing a hex string into a configuration
file on both ends of the connection, or a manufacturer burning a key into ROM
for an IoT device -- what would the "channel" be those cases?  (Or do I completely
misunderstand what you're trying to do?)

-Ben

---

From: Jonathan Hoyland <[email-masked]>
Date: Fri, 15 Jun 2018 17:20:39 +0100

Channel bindings are generally just horribly named.

The `channel` in that case would consist solely of the agreed key, and
agreement on it would prove that not only was that the key, but also that
nothing else was established.
Therefore you wouldn't be able to convince one side that it was just a
manually entered key, and the other that it was a TLS 1.2 PSK, which is
obviously a plausible threat.

Regards,

Jonathan

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 18 Jun 2018 11:47:25 +0200

On Fri, 2018-06-15 at 14:24 +0000, Salz, Rich wrote:
> Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect
> most uses, and seems the only way forward.
> 

TLS 1.3 provides a solution. These secrets under TLS1.3 are restricted
to using the SHA256 PRF. That's how we have implemented it in gnutls.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 18 Jun 2018 12:03:21 +0200

On Fri, 2018-06-15 at 09:11 -0400, David Benjamin wrote:
> Indeed. That is why the TLS 1.2 compatibility section exists. :-) So
> that implementations in that position can reuse TLS 1.2 PSK APIs in
> TLS 1.3 while honoring the security proof.
> 
> But, unfortunately, there's a slight timing issue. There's no way
> some random draft published yesterday will be finalized before TLS
> 1.3. So implementations with TLS 1.2 PSK APIs would need to either
> violate the TLS 1.3 security proof or not ship TLS 1.3 until this
> draft finalizes.

Is key separation between TLS1.3 and TLS1.2 something that TLS1.3
provides or intended to provide? As I mentioned in my reply TLS1.3
design goals were very apparent that keys will be re-used from TLS1.2,
and this is what is happening today for any kind of keys from RSA to
PSKs. I'm not sure I see a new cross-protocol violation here that was
not discussed during the TLS1.3 process.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 18 Jun 2018 12:05:39 +0200

On Fri, 2018-06-15 at 13:00 +0100, Matt Caswell wrote:
> also have TLS1.2 PSK support. OpenSSL is one of them. We have APIs
> for TLS1.2 PSKs and different APIs for TLS1.3 PSKs. Currently
> applications

In gnutls [0] we have the same APIs for PSK under TLS1.2 and TLS1.3 and
the transition is quite smooth, but in contrast to David's algorithm,
we  select a PSK before selecting the ciphersuite in order to make that
work. The problem I see is that PSKs are restricted to SHA256 KDF and
thus AES128 which is somewhat ugly but we can live with it until we
provide a better way to mark a specific PRF in our key files.

regards,
Nikos

[0]. https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html (PSK
key exchange)

---

From: Hubert Kario <[email-masked]>
Date: Mon, 18 Jun 2018 13:22:04 +0200

On Friday, 15 June 2018 16:24:58 CEST Salz, Rich wrote:
> >    was to make the upgrade process as smooth as possible, disabling TLS
> >    1.3 is quite antithetical to that
>   
 
> Do you have an alternative solution?

I don't see a reason to fragment the TLS 1.3 landscape "5 minutes" after the 
release TLS 1.3, even if you consider it small fragmentation.

Correct solution was to include it in the TLS 1.3 proper.

Now we have a TLS 1.3 draft which says:

   Prior to accepting PSK key establishment, the server MUST validate
   the corresponding binder value (see Section 4.2.11.2 below).  If this
   value is not present or does not validate, the server MUST abort the
   handshake. 

and a proposed change to it that doesn't say anything about differentiating 
between universal binders and regular binders. And forces those new binders to 
SHA-256 where previously it was selectable.

So, either it is a severe issue and we should rework TLS 1.3 draft, or this 
draft needs to be significantly reworked before it will not cause huge 
interoperability headaches – signalling extension is the bare minimum, most 
likely a new PSK extension is necessary.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Jonathan Hoyland <[email-masked]>
Date: Mon, 18 Jun 2018 13:56:01 +0200

The issue with the current draft is that it leaves a single PSK with two
potential interpretations.
If the draft also changed the PSK identity value then each PSK would have a
single interpretation.
If the draft changes the identity then it can also change the PSK key
without having to change the manner in which the binder is computed.
In that case universal PSKs and regular PSKs do not need to be
distinguished, because they are both validated in the same way.

A server unaware of universal PSKs would simply see an unrecognised PSK
identity.
If both the unmodified and the modified PSKs are sent, then it can simply
select the unmodified version, ignoring the other.
A server that recognises both values can choose which to use.

If the modified PSK identity was a channel binding, then the modified
version would have stronger security properties, and thus presumably would
be preferable.
In this case the hash function used for the binder remains selectable.

Would that resolve your issue?

Regards,

Jonathan Hoyland

On Mon, 18 Jun 2018 at 12:22 Hubert Kario <[email-masked]> wrote:

> > Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect most
> uses,
> > and seems the only way forward.
>
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech
> Republic_______________________________________________
> TLS mailing list
> [email-masked]

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 18 Jun 2018 15:18:19 +0200

On Mon, 2018-06-18 at 13:56 +0200, Jonathan Hoyland wrote:
> The issue with the current draft is that it leaves a single PSK with
> two potential interpretations. 
> If the draft also changed the PSK identity value then each PSK would
> have a single interpretation.
> A server unaware of universal PSKs would simply see an unrecognised
> PSK identity.
> If both the unmodified and the modified PSKs are sent, then it can
> simply select the unmodified version, ignoring the other. 
> version would have stronger security properties, and thus presumably
> would be preferable.

That may not be sufficient. A server which sees an unrecognized PSK may
chose to pretend it recognized it to avoid user enumeration attacks
similarly to TLS1.2 (optional) behavior. Hence a modified username
would cause negotiation  failure with such a server.

A new extension seems to be necessary to eliminate any interoperability
issues with servers that will not follow the universal psk draft.

regards,
Nikos

---

From: Jonathan Hoyland <[email-masked]>
Date: Mon, 18 Jun 2018 15:30:55 +0200

Given that channel bindings are generally the output of a hash transcript
there seems to be minimal risk of PSK enumeration.
If I send a PSK that the server recognises, alongside one it does not,
would a server sometimes pretend to accept the PSK it does not recognise to
avoid enumeration attacks?
That behaviour would seem strange to me.

If it's only the behaviour when all PSKs are unrecognised then this
shouldn't be an issue if the unmodified PSK is sent as a less secure
fallback option.
If all PSKs including the unmodified one are unrecognised then negotiation
failure is the correct response.

On the other hand, I have no objection in principle to an extension.

Regards,

Jonathan

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 20 Jun 2018 12:59:56 +0300

> to using the SHA256 PRF. That's how we have implemented it in gnutls.

One thing to be careful with here is interoperability. In fact, with
using PSKs across protocol versions and hashes in all sorts of ways the
specifications say they should not, that is the prinicpal worry I have,
above security implications.

Specifically, one has PSK usable for TLS 1.2 and 1.3: Is that PSK the
same for both protocols or is there something like universal-PSK (which
causes the effective PSK not to be the same) going on?

I tried to cook up attacks against using PSKs across protocol versions
and and hashes. Everything I could come up with stopped at literially
the first hash encountered, unless at least one of:

- The hash has some pathological properties.
- The hash has some other properties that cast serious doubt on
  its security.
- The hash is outright broken (which breaks TLS 1.2 and TLS 1.3
  anyway).
- The ciphersuite on TLS 1.2 side uses non-conventional PRF.
- PSK has insufficient entropy and is vulernable to brute-force.

Of course, formally proving anything like this is extremely hard at
best, and most probably impossible (the pathological hashes alone would
already cause extreme trouble, or outright block any proof). And given
the usefulness of proofs in finding various (subtle) mistakes, there
could still be severe problems.

-Ilari