[TLS] Universal PSKs

[David Benjamin]

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: 
Date: Thu, Jun 14, 2018 at 3:21 PM
Subject: New Version Notification for
draft-davidben-tls-universal-psk-00.txt
To: David Benjamin 



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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Enforcing Protocol Invariants

[Kyle Nekritz]

That’s definitely a possibility if using a single key that never changes. With 
periodically rolling new keys, I’m not sure the risk is much different than 
with periodically rolling new versions. Ossifying on updated versions of either 
requires the middlebox to take a hard dependency on having the updated version 
available. Updating for arbitrary changes in the protocol is more complex than 
just updating a config for an encryption key, but I suspect we could also roll 
out an updated key mapping much faster than a new version that required TLS 
library code changes.

Using a negotiated key from a previous connection completely avoids that issue 
(for example the server sends an encrypted extension with identifier X and key 
Y, which the client remembers for future connections).

From: Steven Valdez 
Sent: Thursday, June 14, 2018 10:35 AM
To: Kyle Nekritz 
Cc: David Benjamin ;  
Subject: Re: [TLS] Enforcing Protocol Invariants

This scheme probably isn't sufficient by itself, since a middlebox just has to 
be aware of the anti-ossification extension and can parse the server's response 
by decrypting it with the known mapping (either from the RFC or fetching the 
latest updated mapping), and then ossifying on the contents of the 'real' 
ServerHello. To keep the ServerHello from ossifying, you'll need to change the 
serialization and codepoints of the ServerHello at each rolling version.

On Wed, Jun 13, 2018 at 8:29 PM Kyle Nekritz 
mailto:knekr...@fb.com>> wrote:
I think there may be lower overhead ways (that don’t require frequent TLS 
library code changes) to prevent ossification of the ServerHello using a 
mechanism similar to the cleartext cipher in quic. For example, a client could 
offer an “anti-ossification” extension containing an identifier that 
corresponds to a particular key. The identifier->key mapping can be established 
using a couple of mechanisms, depending on the level of defense desired against 
implementations that know about this extension:
* static mapping defined in RFC
* periodically updated mapping shared among implementations
* negotiated on a previous connection to the server, similar to a PSK
This key can then be used to “encrypt” the ServerHello such that it is 
impossible for a middlebox without the key to read (though would not add actual 
confidentiality and would probably involve aead nonce-reuse). There’s a couple 
of options to do this:
* Simply replace the plaintext record layer for the ServerHello with an 
encrypted record layer, using this key (this would not be compatible with 
existing middleboxes that have caused us trouble)
* Put a “real” encrypted ServerHello in an extension in the “outer” plaintext 
ServerHello
* Send a fake ServerHello (similar to how we encapsulate HelloRetryRequest in a 
ServerHello), and then send a real ServerHello in a following encrypted record
All of these would allow a server to either use this mechanism or negotiate 
standard TLS 1.3 (and the client to easily tell which one is in use).

With the small exception of potentially updating the identifier->key mapping, 
this would not require any TLS library changes (once implemented in the first 
place), and I believe would still provide almost all of the benefits.

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
David Benjamin
Sent: Tuesday, June 12, 2018 12:28 PM
To: mailto:tls@ietf.org>> mailto:tls@ietf.org>>
Subject: [TLS] Enforcing Protocol Invariants

Hi all,

Now that TLS 1.3 is about done, perhaps it is time to reflect on the 
ossification problems.

TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be 
incrementally rolled out in an existing compliant TLS 1.2 deployment. Yet we 
had problems. Widespread non-compliant servers broke on the TLS 1.3 
ClientHello, so versioning moved to supported_versions. Widespread 
non-compliant middleboxes attempted to parse someone else’s ServerHellos, so 
the protocol was further hacked to weave through their many defects.

I think I can speak for the working group that we do not want to repeat this 
adventure again. In general, I think the response to ossification is two-fold:

1. It’s already happened, so how do we progress today?
2. How do we avoid more of this tomorrow?

The workarounds only answer the first question. For the second, TLS 1.3 has a 
section which spells out a few protocol 
invariants.
 It is all corollaries of existing TLS specification text, but hopefully 
documenting it explicitly will help. But experience has shown specification 
text is only necessary, not sufficient.

For extensibility problems in servers, we have 
GREASE

Re: [TLS] Enforcing Protocol Invariants

[Steven Valdez]

This scheme probably isn't sufficient by itself, since a middlebox just has
to be aware of the anti-ossification extension and can parse the server's
response by decrypting it with the known mapping (either from the RFC or
fetching the latest updated mapping), and then ossifying on the contents of
the 'real' ServerHello. To keep the ServerHello from ossifying, you'll need
to change the serialization and codepoints of the ServerHello at each
rolling version.

On Wed, Jun 13, 2018 at 8:29 PM Kyle Nekritz  wrote:

> I think there may be lower overhead ways (that don’t require frequent TLS
> library code changes) to prevent ossification of the ServerHello using a
> mechanism similar to the cleartext cipher in quic. For example, a client
> could offer an “anti-ossification” extension containing an identifier that
> corresponds to a particular key. The identifier->key mapping can be
> established using a couple of mechanisms, depending on the level of defense
> desired against implementations that know about this extension:
> * static mapping defined in RFC
> * periodically updated mapping shared among implementations
> * negotiated on a previous connection to the server, similar to a PSK
> This key can then be used to “encrypt” the ServerHello such that it is
> impossible for a middlebox without the key to read (though would not add
> actual confidentiality and would probably involve aead nonce-reuse).
> There’s a couple of options to do this:
> * Simply replace the plaintext record layer for the ServerHello with an
> encrypted record layer, using this key (this would not be compatible with
> existing middleboxes that have caused us trouble)
> * Put a “real” encrypted ServerHello in an extension in the “outer”
> plaintext ServerHello
> * Send a fake ServerHello (similar to how we encapsulate HelloRetryRequest
> in a ServerHello), and then send a real ServerHello in a following
> encrypted record
> All of these would allow a server to either use this mechanism or
> negotiate standard TLS 1.3 (and the client to easily tell which one is in
> use).
>
> With the small exception of potentially updating the identifier->key
> mapping, this would not require any TLS library changes (once implemented
> in the first place), and I believe would still provide almost all of the
> benefits.
>
> *From:* TLS  *On Behalf Of *David Benjamin
> *Sent:* Tuesday, June 12, 2018 12:28 PM
> *To:*  
> *Subject:* [TLS] Enforcing Protocol Invariants
>
> Hi all,
>
> Now that TLS 1.3 is about done, perhaps it is time to reflect on the
> ossification problems.
>
> TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be
> incrementally rolled out in an existing compliant TLS 1.2 deployment. Yet
> we had problems. Widespread non-compliant servers broke on the TLS 1.3
> ClientHello, so versioning moved to supported_versions. Widespread
> non-compliant middleboxes attempted to parse someone else’s ServerHellos,
> so the protocol was further hacked to weave through their many defects.
>
> I think I can speak for the working group that we do not want to repeat
> this adventure again. In general, I think the response to ossification is
> two-fold:
>
> 1. It’s already happened, so how do we progress today?
> 2. How do we avoid more of this tomorrow?
>
> The workarounds only answer the first question. For the second, TLS 1.3
> has a section which spells out a few *protocol invariants*
> .
> It is all corollaries of existing TLS specification text, but hopefully
> documenting it explicitly will help. But experience has shown specification
> text is only necessary, not sufficient.
>
> For extensibility problems in servers, we have *GREASE*
> .
> This enforces the key rule in ClientHello processing: ignore unrecognized
> parameters. GREASE enforces this by filling the ecosystem with them. TLS
> 1.3’s middlebox woes were different. The key rule is: if you did not
> produce a ClientHello, you cannot assume that you can parse the response.
> Analogously, we should fill the ecosystem with such responses. We have an
> idea, but it is more involved than GREASE, so we are very interested in the
> TLS community’s feedback.
>
> In short, we plan to regularly mint new TLS versions (and likely other
> sensitive parameters such as extensions), roughly every six weeks matching
> Chrome’s release cycle. Chrome, Google servers, and any other deployment
> that wishes to participate, would support two (or more) vers