Subject: [TLS] Do we actually need semi-static DHE-based 0-RTT?

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Feb 2016 18:04:05 -0700

TL;DR.
Should we remove the semi-static DHE 0-RTT mode and just leave
the PSK and PSK-DHE 0-RTT modes?

DETAIL
This is the last in the series of messages about changes to consider.

TLS 1.3 currently supports two 0-RTT modes:

- A semi-static Diffie-Hellman mode in which the server provides
  a long-term DH share and the data is protected under the client's
  ephemeral DH share and the server's long-term DH share.

- A PSK mode in which the client and server establish a shared
  key in handshake #1 and then they use that to encrypt 0-RTT
  data in handshake #2. And of course you can use tickets.
  [Note that this isn't as completely specified as one might
  like, but as there is agreement that this should work, we
  need to fully specify it. I'm working on implementing it now
  and this should help flush out issues.]

A number of people have independently observed that semi-static DHE
for 0-RTT is not clearly better than DHE-PSK for 0-RTT and suggested
that we limit 0-RTT to PSK and DHE-PSK [0], so I figured it was
something we should disuss. Obviously this is a significant
simplification, while still a big improvement over TLS 1.2-style
resumption because it allows PFS and 0-RTT.

Aside from simplicity, there are two major other considerations
here: PFS and public "priming".

PFS
In the semi-static mode, the 0-RTT client data is encrypted under g^xs
and the server's application data and any 1-RTT client app data is
encrypted under both g^xy and g^xs, so you get PFS for any 1-RTT data
but not for 0-RTT data, because as long as the server has s floating
around, there is a risk that the attacker can attack the server,
recover s, and decrypt any of the 0-RTT data.

In PSK-DHE mode, the 0-RTT data is encrypted under the shared
resumption master secret (r) and then the 1-RTT data is encrypted
under both r and g^xy, so you get PFS for any 1-RTT data
but not for 0-RTT data, because as long as the server has s floating
around, there is a risk that the attacker can attack the server,
recover s, and decrypt any of the 0-RTT data. If we assume that
the server uses tickets, then r isn't stored but encrypted under
some master key m.

They key point is that in both cases the server has a long-term key
floating around which is a risk to PFS. But the concerns are basically
the same for m and s, so you can pretty much keep them around with the
same kind of lifetime.

As Adam Langley points out, the *client* has to store a long-term
secret (r) in the DHE-PSK mode and if that is compromised, then an
attacker can decrypt the 0-RTT data and potentially mount an active
attack on future connections. This is a pretty qualitatively lower
risk from compromise of the server's long-term DHE key.

PUBLISHED CONFIGURATIONS
The semi-static mode in principle allows the server to publish its
configuration (i.e., it's semi-static key), e.g., via DNS, which the
client can then use for 0-RTT handshakes on first contact. However,
recent conversations (especially with the guys from Cloudflare) have
convinced me that this probably isn't useful: DNS TXT record
penetration rates are really bad and all the other proposed mechanisms
are also pretty problematic. For the few protocols where I was
thinking that this sort of priming was attractive, it turns out not to
work well or to have other easier workarounds.

WHAT ARE THE OPTIONS
1. Simply leave things as-is.
2. Just remove 0-RTT semi-static DHE
3. Remove 0-RTT semi-static DHE *and* 0-RTT client auth
   (on the theory that tickets let you carry it across connections).

Obviously #3 is the biggest change, but also the biggest simplification.
Both #2 and #3 are basically subsets of the existing protocol.

In addition, if we decide to make this change, we should probably
consider having some way for the client to indicate 0-RTT PSK-DHE but
force the server to do a signature (thus proving possession of the
signature key). I can think of a number of ways to design this easily,
however.

In terms of the way forward, if we can agree on a general strategy,
I'll work up proposed text.

Thanks,
-Ekr

[0] I've heard this suggested at one time or another by
Watson Ladd, Cloudflare, and the INRIA/MSR Cambridge group.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 19 Feb 2016 00:44:22 -0500

> 1. Simply leave things as-is.

Nobody has enough of a reason to have support for DNS records that can do this, yet. Adding it here could change the situation over time.

More importantly, some major sites/services might even want to just cut out the middle-ware and dump 0RTT configs into a client synced list of some sort, akin to how some handle HPKP. Not the most elegant of systems, but it would let clients that use such a list have out-of-the-box 0RTT to major high-traffic sites. Ad hoc systems would also be able to preload for 0RTT for their services easily (e.g. make an app & include 0RTT config cache with it).

Even for clients merely getting their config via a first connection, we might be more likely to be able to cache for DHE safely longer than just for PSK for every client.

I think it's a feature worth keeping.

Dave

---

From: Bill Cox <[email-masked]>
Date: Thu, 18 Feb 2016 21:57:04 -0800

> I think it's a feature worth keeping.
I do not agree.  Having two different modes to achieve basically the same
thing in TLS 1.3 is a bad idea.  Complexity is what will kill TLS, not a
lack of different ways to do the same thing.  If one mode must go (and one
should), PSK seems the more worthy of the two, IMO.

Bill

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 19 Feb 2016 15:01:31 +0000

I greatly prefer one way to do things.  (Python not perl, if you will :)

On the other hand, there is an elegance about using a single well-understood mechanism even if it has operational burdens.  We all know how to secure PSK material, though, right? :)  But what dose this do about encrypted-SNI? 

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Feb 2016 11:16:10 -0700

+ TLS WG

On Fri, Feb 19, 2016 at 8:46 AM, Eric Rescorla <[email-masked]> wrote:

>
> On Fri, Feb 19, 2016 at 8:01 AM, Salz, Rich <[email-masked]> wrote:
>
>> On the other hand, there is an elegance about using a single
>> well-understood mechanism even if it has operational burdens.  We all know
>> how to secure PSK material, though, right? :)  But what dose this do about
>> encrypted-SNI?
>>
>
> Funny you should mention that. There's actually a very elegant way to do
> encrypted
> SNI here (due to Cedric Fourney). The basic idea is that you initially
> contact the hidden
> server and do a TLS handshake establishing a ticket. That ticket actually
> has two parts:
>
> - The ordinary ticket
> - The identity of the hidden cipher enciphered for the gateway
>
> Then when you connect to the gateway, you do an apparent PSK+(ECDHE)
> handshake with it and provide the ticket. It unwraps the identity of the
> hidden
> server and then forwards the ClientHello to the hidden server for
> processing
> and the rest of the handshake just completes as normal, but with the hidden
> server [0]. And because each handshake provides a new ticket, this
> is unlinkable.
>
> The major drawback of this design is that the first ticket establishment
> requires
> contacting the hidden server, but you can either do this directly (as we
> have
> been assuming) or just tunnel through the gateway the first time with
> TLS-in-TLS.
>
> -Ekr
>
> [0] I originally thought this might need a change to the ticket signaling
> mechanism, but I'm less sure that that's true. In any case, that should
> be minor.
>
>
>> --

---

From: Dave Garrett <[email-masked]>
Date: Fri, 19 Feb 2016 17:08:20 -0500

On Friday, February 19, 2016 12:57:04 am Bill Cox wrote:
> Having two different modes to achieve basically the same
> thing in TLS 1.3 is a bad idea.

On Friday, February 19, 2016 10:01:31 am Salz, Rich wrote:
> I greatly prefer one way to do things.

I do not fundamentally disagree. I would support dropping PSK resumption in favor of using only DHE 0RTT for resumption.

With PSK resumption, as far as I know, the issue of what cipher suites to offer & use has not been settled, or at least written down in the spec. Not having to use all of the PSK suites (or non-PSK suites but actually using PSK, which could be confusing) and the PSK extension for resumption, and instead using some session ID and DHE 0RTT would be simpler and not loose capability.

I think that requiring PSK for 0RTT would significantly reduce the availability of actually using 0RTT, whilst providing no way to improve the situation over the long term. It would mean that TLS only has 0RTT resumption and not actually have any 0RTT sessions.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Feb 2016 15:24:25 -0700

On Fri, Feb 19, 2016 at 3:08 PM, Dave Garrett <[email-masked]>
wrote:

> I do not fundamentally disagree. I would support dropping PSK resumption
> in favor of using only DHE 0RTT for resumption.
>

This would represent a major performance regression from TLS 1.2
and therefore I do not believe is practical.

With PSK resumption, as far as I know, the issue of what cipher suites to
> offer & use has not been settled, or at least written down in the spec. Not
> having to use all of the PSK suites (or non-PSK suites but actually using
> PSK, which could be confusing) and the PSK extension for resumption, and
> instead using some session ID and DHE 0RTT would be simpler and not loose
> capability.
>

I'm fairly far into a PSK-resumption implementation and I don't believe
that that is going
to be correct. I do agree that some details need to be written down, but I
don't expect
them to be that hard.

I think that requiring PSK for 0RTT would significantly reduce the
> availability of actually using 0RTT, whilst providing no way to improve the
> situation over the long term.

My impression is exactly the opposite. All the infrastructure to
PSK-resumption and
hence PSK-0RTT is already in place for TLS 1.2. And of course PSK-resumption
is also much faster.

It would mean that TLS only has 0RTT resumption and not actually have any
> 0RTT sessions.

Why do you think that this makes a material difference?

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Fri, 19 Feb 2016 18:15:09 -0500

On Friday, February 19, 2016 05:24:25 pm Eric Rescorla wrote:
> My impression is exactly the opposite. All the infrastructure to PSK-resumption and

That's good to hear. The perf advantage is why I'm not advocating dropping it; merely saying that I too would prefer a single method if it didn't loose capability. Dropping PSK resumption drops less than dropping DHE 0RTT, but keeping both seems like the best option at the moment.

> On Fri, Feb 19, 2016 at 3:08 PM, Dave Garrett <[email-masked]> wrote:
> > It would mean that TLS only has 0RTT resumption and not actually have any 0RTT sessions.
> 

One of the fundamental complaints about TLS, performance-wise, is the added round trip time over plaintext. That's why the WG made a point to focus on adding 0RTT in the first place. Someone considering upgrading from HTTP to HTTPS generally has this concern (or any other protocol to a variant over TLS). With only PSK resumption, we can still always have a 1RTT hit on first connection, and revert to that after the session is considered expired. With DHE 0RTT we have a longer term config that could allow for more generic caching and distribution and thus not have to get that 1RTT hit in many scenarios.

The lack of a current ability to easily distribute a new config system should not be used as evidence against creating a new config system that we would want to create a way to easily distribute. Even dumping the top few dozen sites' 0RTT DHE config into a static file in a client update would be a noticeable improvement over not doing so. Coming up with a better method can come next.

People should be using TLS or encryption in general as a matter of responsibility, but they don't. Softening *all* barriers to them upgrading is very necessary to get more to switch. 0RTT PSK only gets rid of a delay in continuing a session, which in some use-cases might be minimally noticeable. 0RTT DHE allows for a first-connect with comparable speed to plaintext (in scenarios where 0RTT data is safe, namely most HTTP). Within the context of HTTP, which is singled out as a focus in the TLS WG charter, 0RTT DHE will provide a more noticeable latency reduction in comparison to 0RTT PSK only.

Another issue is that of privacy with session resumption. If the only way to get 0RTT is to keep sessions alive, then clearing that cache on the client side costs a future 1RTT. You can, however, cache 0RTT DHE configs safely for a longer time because they are not specific to the user agent. (we should probably narrow the spec to state that configs SHOULD NOT be per-client) In order to reliably get 0RTT without DHE configs, applications/services would need to cache PSK resumption sessions for as long as possible, which leaves a distinct per-user marker on both the client and server. Anyone trying to optimize away the 1RTT hit of first-connect will be required to maintain a system that keeps more user identifiable information than we should want.

Dave

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 19 Feb 2016 23:31:32 +0000

I would also suggest keeping PSK 0RTT.

On of the things I'm looking at is postquatum cryptography (that is, cryptography that would still be secure even if someone manages to build a large quantum computer).  While this is not the most important issue that TLS 1.3 needs to deal with; it's probably not in the top 100; however at some point, TLS will need to deal with it, and it would be preferable if we could say "here's a minor tweak/new ciphersuite/named group we apply to TLS 1.3, and we're good to go", rather than "we need to start doing a TLS 1.4".

Here's one of the issues that I foresee; we have key exchange protocols that look postquantum, however they can't do everything that (EC)DH can; either either must be run ephemerally (that is, no static keyshares, you have to generate a fresh one for each key exchange), or the response keyshare is a function of the initiator's one (and can't be used be used in a second exchange).

While such a key exchange protocol would work fine in an initial contact situation, it doesn't work out nearly as well in a DHE-0RTT protocol (which does make both assumptions).  Leaving in a doorway where we don't require our cryptoprimitives to have such capabilities may, in the long run, make things easier on us.

> -----Original Message-----
> From: TLS [mailto:[email-masked]] On Behalf Of Dave Garrett
> Sent: Friday, February 19, 2016 6:15 PM
> To: Eric Rescorla; [email-masked]
> Subject: Re: [TLS] Do we actually need semi-static DHE-based 0-RTT?
> 
> > PSK-resumption and hence PSK-0RTT is already in place for TLS 1.2. And
> > of course PSK-resumption is also much faster.
> 
> That's good to hear. The perf advantage is why I'm not advocating dropping
> it; merely saying that I too would prefer a single method if it didn't loose
> capability. Dropping PSK resumption drops less than dropping DHE 0RTT, but
> keeping both seems like the best option at the moment.
> 
> One of the fundamental complaints about TLS, performance-wise, is the
> added round trip time over plaintext. That's why the WG made a point to
> focus on adding 0RTT in the first place. Someone considering upgrading from
> HTTP to HTTPS generally has this concern (or any other protocol to a variant
> over TLS). With only PSK resumption, we can still always have a 1RTT hit on
> first connection, and revert to that after the session is considered expired.
> With DHE 0RTT we have a longer term config that could allow for more
> generic caching and distribution and thus not have to get that 1RTT hit in
> many scenarios.
> 
> The lack of a current ability to easily distribute a new config system should
> not be used as evidence against creating a new config system that we would
> want to create a way to easily distribute. Even dumping the top few dozen
> sites' 0RTT DHE config into a static file in a client update would be a noticeable
> improvement over not doing so. Coming up with a better method can come
> next.
> 
> People should be using TLS or encryption in general as a matter of
> responsibility, but they don't. Softening *all* barriers to them upgrading is
> very necessary to get more to switch. 0RTT PSK only gets rid of a delay in
> continuing a session, which in some use-cases might be minimally noticeable.
> 0RTT DHE allows for a first-connect with comparable speed to plaintext (in
> scenarios where 0RTT data is safe, namely most HTTP). Within the context of
> HTTP, which is singled out as a focus in the TLS WG charter, 0RTT DHE will
> provide a more noticeable latency reduction in comparison to 0RTT PSK only.
> 
> Another issue is that of privacy with session resumption. If the only way to
> get 0RTT is to keep sessions alive, then clearing that cache on the client side
> costs a future 1RTT. You can, however, cache 0RTT DHE configs safely for a
> longer time because they are not specific to the user agent. (we should
> probably narrow the spec to state that configs SHOULD NOT be per-client) In
> order to reliably get 0RTT without DHE configs, applications/services would
> need to cache PSK resumption sessions for as long as possible, which leaves a
> distinct per-user marker on both the client and server. Anyone trying to
> optimize away the 1RTT hit of first-connect will be required to maintain a
> system that keeps more user identifiable information than we should want.
> 
> 
> Dave
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Feb 2016 17:02:44 -0700

On Fri, Feb 19, 2016 at 4:15 PM, Dave Garrett <[email-masked]>
wrote:

> it; merely saying that I too would prefer a single method if it didn't
> loose capability. Dropping PSK resumption drops less than dropping DHE
> 0RTT, but keeping both seems like the best option at the moment.
>
> HTTP to HTTPS generally has this concern (or any other protocol to a
> variant over TLS). With only PSK resumption, we can still always have a
> 1RTT hit on first connection, and revert to that after the session is
> considered expired. With DHE 0RTT we have a longer term config that could
> allow for more generic caching and distribution and thus not have to get
> that 1RTT hit in many scenarios.
>
> The lack of a current ability to easily distribute a new config system
> should not be used as evidence against creating a new config system that we
> would want to create a way to easily distribute. Even dumping the top few
> dozen sites' 0RTT DHE config into a static file in a client update would be
> a noticeable improvement over not doing so. Coming up with a better method
> can come next.
>
> responsibility, but they don't. Softening *all* barriers to them upgrading
> is very necessary to get more to switch. 0RTT PSK only gets rid of a delay
> in continuing a session, which in some use-cases might be minimally
> noticeable. 0RTT DHE allows for a first-connect with comparable speed to
> plaintext (in scenarios where 0RTT data is safe, namely most HTTP). Within
> the context of HTTP, which is singled out as a focus in the TLS WG charter,
> 0RTT DHE will provide a more noticeable latency reduction in comparison to
> 0RTT PSK only.
>

This seems to basically come down to an assessment of how likely it is that
we in fact will
have an out-of-band priming mechanism. My sense from talking to the people
most likely
to deploy such a thing is that that's not actually very likely to emerge.
Note that we're
primarily discussing what has to appear in TLS 1.3. If something like this
emerged
it can be added in a future extension.  appreciate that this is a judgement
call and for a
long time I leaned the way you are arguing, but lately I've started to feel
like the arguments
to the contrary are fairly persuasive.

> Another issue is that of privacy with session resumption. If the only way
> to get 0RTT is to keep sessions alive, then clearing that cache on the
> client side costs a future 1RTT. You can, however, cache 0RTT DHE configs
> safely for a longer time because they are not specific to the user agent.
> (we should probably narrow the spec to state that configs SHOULD NOT be
> per-client) In order to reliably get 0RTT without DHE configs,
> applications/services would need to cache PSK resumption sessions for as
> long as possible, which leaves a distinct per-user marker on both the
> client and server. Anyone trying to optimize away the 1RTT hit of
> first-connect will be required to maintain a system that keeps more user
> identifiable information than we should want.
>

I don't find this argument very persuasive. The server need not store any
information at all
(because it can use tickets). As a practical matter, having the server's
config leaks the
fact that you had contacted the server just as much as having a session
ticket. We already
see this with HPKP and HSTS information and that's definitely public.

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Fri, 19 Feb 2016 19:38:31 -0500

I just had an idea. There is significant doubt of how useful semi-static DHE 0RTT would be due to the difficulty of distributing the configs out-of-bound. I don't dispute this; I merely dispute that no capability is better than minimal, in this realm. There is another way that they could be helpful, however.

Take a typical HTTP page and a client with no prior knowledge. (could be applicable to other applications, but the TLS WG does have a charter to take special note of HTTP latency; subresources' lack of HTTPS often is a stated reason for a site's lack of HTTPS overall) There will be a 1RTT cost without having a pre-cached way to do 0RTT, and then after that there will be a 1RTT cost for *every* subresource on a different server. To do HTTPS for the servers of 3rd party scripts, ads, user-posted images/video embeds, etc., each of those servers will need to be connected to by the client with TLS and no prior knowledge, meaning a 1RTT cost. This could be significantly optimized by creating a new HTTP extension that allows servers to enumerate the domains on a page, cache all those domains' semi-static DHE config, and push them to each client in their first flight returning the primary resource. This would allow all subresources to be fetched by the client with a 0RTT cost, and just a single 1RTT cost for the primary resource. Servers could simply refresh their cache of their subresources' semi-static DHE configs on a daily basis. A stale config can be sent to a client and it can still fallback to 1RTT, though. Clients would not need to have any prior knowledge in order to significantly benefit from 0RTT in this scenario. TLS 1.3 would need to have some way of facilitating this scenario in order to devise a way to do this sort of thing in HTTP (or another general protocol with subresources).

The general point I'm trying to convey here is that we can come up with ways to use this to improve latency noticeably, if given the underlying capability. We don't know how effectively it can be used until we try.

Dave

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Feb 2016 16:47:31 -0800

This really only helps on the first connection attempt.  Browsers
already pre-warm connections to subresource hosts.

On 19 February 2016 at 16:38, Dave Garrett <[email-masked]> wrote:
> Take a typical HTTP page and a client with no prior knowledge. (could be applicable to other applications, but the TLS WG does have a charter to take special note of HTTP latency; subresources' lack of HTTPS often is a stated reason for a site's lack of HTTPS overall) There will be a 1RTT cost without having a pre-cached way to do 0RTT, and then after that there will be a 1RTT cost for *every* subresource on a different server. To do HTTPS for the servers of 3rd party scripts, ads, user-posted images/video embeds, etc., each of those servers will need to be connected to by the client with TLS and no prior knowledge, meaning a 1RTT cost. This could be significantly optimized by creating a new HTTP extension that allows servers to enumerate the domains on a page, cache all those domains' semi-static DHE config, and push them to each client in their first flight returning the primary resource. This would allow all subresources to be fetched by the client with a 0RTT cost, and just a sin
>  gle 1RTT cost for the primary resource. Servers could simply refresh their cache of their subresources' semi-static DHE configs on a daily basis. A stale config can be sent to a client and it can still fallback to 1RTT, though. Clients would not need to have any prior knowledge in order to significantly benefit from 0RTT in this scenario. TLS 1.3 would need to have some way of facilitating this scenario in order to devise a way to do this sort of thing in HTTP (or another general protocol with subresources).
>

---

From: Dave Garrett <[email-masked]>
Date: Fri, 19 Feb 2016 20:00:22 -0500

> already pre-warm connections to subresource hosts.

The first connect is important, as are new connections after a cache clear (think also, private browsing modes).

Providing this capability to TLS 1.3 clients (likely also requiring HTTP/2) would allow for browsers to explicitly have a way to do this, rather than speculatively "pre-warm" connections.

Additionally, servers could push a cached config for links on pages if they wanted to. Servers supporting this could effectively chain together to give 0RTT for virtually all normal user connections. Clients would not have to open connections to arbitrary link destinations in order to optimize away this 1RTT. (yes, there's the TCP 1RTT too, but that's a separate issue)

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Feb 2016 17:52:44 -0800

I don't believe that this is going to work very well, since it is a fairly
large burden for referring
servers to refresh their state.

-Ekr

On Fri, Feb 19, 2016 at 5:00 PM, Dave Garrett <[email-masked]>
wrote:

> Providing this capability to TLS 1.3 clients (likely also requiring
> HTTP/2) would allow for browsers to explicitly have a way to do this,
> rather than speculatively "pre-warm" connections.
>
> Additionally, servers could push a cached config for links on pages if
> they wanted to. Servers supporting this could effectively chain together to
> give 0RTT for virtually all normal user connections. Clients would not have
> to open connections to arbitrary link destinations in order to optimize
> away this 1RTT. (yes, there's the TCP 1RTT too, but that's a separate issue)
>
>
> Dave
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 20 Feb 2016 14:07:00 +0200

> servers to refresh their state.

Then there is the question of authenticating the state.

-Ilari

---

From: Nick Sullivan <[email-masked]>
Date: Sun, 21 Feb 2016 09:29:29 -0800

> a noticeable improvement over not doing so. Coming up with a better method

I don't think distributing the 0RTT semi-static DHE config for a set of top
sites using a file is a realistic use case. As Eric said, for each active
DH share, the server has a long-term key floating around which is a risk to
PFS. Keeping these keys around for longer than the recommended 7 days is
not a good practice. If the semi-static secrets are rotated at this rate,
this increases the rate at which clients will have to download the
configuration file. For everything other than these few dozen sites, the
first connection will still be 1RTT. Clients who want 0RTT with these top
sites might as well just establish a session out of band and then use 0RTT
PSK.

> 0RTT PSK only

This assumes that there is a reasonable concrete scenario for distributing
the semi-static DH share. It is not clear that this use case exists. Any
use case we find to distribute semi-static secrets out of band needs to
handle authentication, key freshness, and provide a latency improvement
over simply priming the connection with a full handshake.

At the very least, we should consider removing the ServerConfiguration
distribution as part of the TLS handshake. It is only useful for
establishing 0-RTT in resumption connections, and there is already a method
for 0-RTT resumption using PSK. Having a two ways in TLS to distribute key
material to prime 0-RTT for resumed connections is redundant.