Subject: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

From: Karthik Bhargavan <[email-masked]>
Date: Fri, 25 Mar 2016 10:29:06 +0100

We currently allow 0-RTT with Semi-static DH, with PSK resumption, and with pure PSK.
Whether or not we keep all of these, it would be good to clean up the protocol design 
so that both the client and server have a uniform way of signaling their preferences.

After implementing and analyzing TLS 1.3, here are a few suggestions for discussion.

1) Early Data Extension

The current early-data extension is too DH-specific.
When using PSK, we now have to look at both early_data and pre_shared extensions.
I suggest reusing the same extension for both, with the following interpretation:

	struct {
          select (Role) {
              case client:
                  opaque id<1..2^16-1>;
                  opaque context<0..255>;
                  CipherSuite cipher_suite;
                  Extension extensions<0..2^16-1>;

              case server:
                 struct {};
          	}
	} EarlyDataIndication;

In the semi-static DH case:
- id is the configuration id
- context is the hash of the ServerConfiguration + Server Certificate + CertificateRequest

In the PSK resumption case:
- id is the session ticket
- context is a *public* value unique to the derived session. For example, it could be defined as the session hash of the original handshake,
  or it could be derived by the client as HKDF(RMS, “early data context”)

In the pure PSK case
- id is the PSK identifier
- context is unique to the PSK and its allowed use.
  For example, it can be generated (out-of-band) as HKDF(PSK, “early data context”)

2) New Session Ticket

The NewSessionTicket message needs to indicate whether the server will accept 0-RTT,
and what ciphersuites it is willing to accept (e.g. pure PSK resumption vs only PSK-ECDHE).

I suggest the following modification to this message:
	struct {
         uint32 ticket_lifetime;
         opaque ticket<0..2^16-1>;
	 CipherSuite cipher_suites<2..2^16-2>;
	 EarlyDataType early_data_type
     	} NewSessionTicket;

        enum {
	  no_early_data_allowed(0),
          replayable_early_data_allowed (1),
          all_early_data_allowed(2),
          (65535)
       } EarlyDataType;

The interpretation of the early_data_type field is that the server is either:
(a) unwilling to accept 0-RTT (no_early_data_allowed), 
(b) willing to accept 0-RTT, but it has no replay cache (replayable_early_data_allowed),
(c) willing to accept 0-RTT and has a replay cache that it uses to prevent replay (all_early_data_allowed)

The client’s response to this ticket message should be to store it in its
session along with the “context” (session hash or derived from RMS),
the allowed cipher suites, and the early_data_indication.

When resuming with this ticket:
- the client should not send any 0-RTT data if no_early_data_allowed
- the client should only send replayable data if replayable_early_data_allowed (e.g. GET requests)
- the client can send any 0-RTT data if all_early_data_allowed, trusting the server to do the right thing.

A note on replay
----------------------

There has been much discussion on 0-RTT replay and here’s a quick summary of my understanding.
We already knew that an active attacker, or a lossy network, or an overzealous web browser could
and would cause 0-RTT (and even 1-RTT) data to be replayed to the server. This can already happen
in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3.

The new concerns on the mailing list (and in my TRON talk which was based on a ProVerif model) 
are that unlike TLS 1.2:
(a) even a passive attacker could replay 0-RTT data, long after the client has gone away,
(b) replaying authenticated 0-RTT data can be more damaging (whether authenticated with client cert or with a cookie), and
(c) by replaying 0-RTT data, the attacker can obtain encrypted 0.5-RTT data which opens up new attack vectors.

As a result of these new concerns, I would say that TLS 1.3 should recommend that all servers SHOULD
implement a replay cache, and those that cannot should clearly signal this to the client, so that the client
can adjust its 0-RTT use case and its expectations accordingly.

A note on authenticating the 0-RTT “context”
----------------------------------------------------------

When trying to figure out how to authenticate 0-RTT DH mode in an earlier draft, we came upon the
design of signing the Handshake Context that consists of the ClientHello + additional information from the previous handshake.
This construction prevents 0-RTT authentication from unknown key share attacks.

Even if we eliminate client certificate authentication from 0-RTT, this notion of “context" is still useful for two reasons:
(a) the application may use TokenBinding or some such protocol to authenticate 0-RTT data, and we need to understand what “channel binding” to provide for this case,
(b) in PSK resumption mode, since the handshake log does not contain much information that is specific to the previous connection, it would be more robust to add an explicit context.

If we accept the definition of “context” in the EarlyDataIndication extension, then we can use the hash of the ClientHello uniformly in all
0-RTT modes for deriving keys, and for deriving a channel binding for the application. Furthermore, we can safely introduce a PSK_ECDHE
mode where the server sends its Certificate and CertificateVerify and its signature is correctly bound to the PSK (via the “context” field).

Best regards,
Karthik

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 25 Mar 2016 13:53:43 +0200

>                   Extension extensions<0..2^16-1>;

You mean combining the 0-RTT aspects of pre_shared_key extension with
early_data? Because I don't think this type of structure can present what
PSK extension presents (e.g. multiple candidate PSK identities).
 
> - context is the hash of the ServerConfiguration + Server Certificate + CertificateRequest

This would close the loop between static key and the handshake (this
loop being open in previous versions creates some "excitement" (not a
good thing)).

Also, is this hash also used to bind the configuration, identity and
possible certificate request to 0-RTT keys? ServerConfiguration and
CertificateRequest are not problematic to reconstruct from small space,
but Certificate message can be good bit larger...

Ah, later it looks like these could then be dropped form 0-RTT key
derivation then...

>   or it could be derived by the client as HKDF(RMS, “early data context”)

The first would break symmetry between resumption and PSK. The second
would be symmetric with HKDF(PSK, “early data context”).
 
>   For example, it can be generated (out-of-band) as HKDF(PSK, “early data context”)

Seems reasonable way to generate the context.

> (c) willing to accept 0-RTT and has a replay cache that it uses to prevent replay (all_early_data_allowed)

(b) vs (c) don't affect the next handshake except if 0-RTT data is sent
or not?

(I ask, because early_data_type with 0rtt auth does affect next handshake
in a way that is not signaled there, making it look horrifying to implement,
at least if one wants to enforce strict state machine behaviour).
 
> When trying to figure out how to authenticate 0-RTT DH mode in an
> earlier draft, we came upon the design of signing the Handshake
> Context that consists of the ClientHello + additional information
> from the previous handshake. This construction prevents 0-RTT
> authentication from unknown key share attacks.

It also looks to protect the _main_ TLS handshake from unknown key share
attacks when using 0-RTT DH mode.

> Even if we eliminate client certificate authentication from 0-RTT,
> this notion of “context" is still useful for two reasons:

Also, lacking 0-RTT certificate auth would be useful to deflect the
headlines if flaw in scheme is discovered (the flaw would then be
blamed on $PROTOCOL, not TLS). :-)

More seriously, if I was pick one aspect of current TLS 1.3
implmentability that terrifies me the most, it would be 0-RTT cert.
auth, by far.

When writing code doing state-machine handshake sequencing on TLS 1.2
and 1.3, by far the source of most expletives is either:

1) Some crazyness TLS 1.2 does with resumption (when session tickets
   are involved).
2) TLS 1.3 0-RTT cert auth (would really love to rip that code out).

> (a) the application may use TokenBinding or some such protocol to 
>     authenticate 0-RTT data, and we need to understand what “channel
>     binding” to provide for this case,
> (b) in PSK resumption mode, since the handshake log does not contain
>     much information that is specific to the previous connection, it
>     would be more robust to add an explicit context.

> If we accept the definition of “context” in the EarlyDataIndication
> extension, then we can use the hash of the ClientHello uniformly in
> all 0-RTT modes for deriving keys, and for deriving a channel binding
> for the application. Furthermore, we can safely introduce a PSK_ECDHE
> mode where the server sends its Certificate and CertificateVerify and
> its signature is correctly bound to the PSK (via the “context” field).

Yeah. Would solve a lot of problems with the current design.

-Ilari

---

From: Karthik Bhargavan <[email-masked]>
Date: Fri, 25 Mar 2016 12:59:16 +0100

> PSK extension presents (e.g. multiple candidate PSK identities).

Good question. For 0-RTT, multiple PSK identities make no sense, 
because we can only use one of these for the 0-RTT key derivation.

Are there cases where the client wants to advertise multiple PSK identities
for 1-RTT? If so, we could retain the pre_shared_key extension specifically
for the 1-RTT PSK case, and disregard it for 0-RTT.

Best,
Karthik

---

From: Bill Cox <[email-masked]>
Date: Fri, 25 Mar 2016 08:33:20 -0700

Adding 1 byte EarlyDataType seems like a good idea.

As for the CipherSuite, assuming DH-0RTT goes away, would it be simpler to
require that the cipher suite negotiated from the original 1-RTT connection
be used?

For channel binding, the only mode that seems to work with 0-RTT is when we
issue new tickets on each 0-RTT connection to emulate a single session like
we have in TLS 1.2, and use a replay cache on the server.  The only valid
proof-of-possession the server can do with the client before processing
application requests is the one done on the 1-RTT connection, so this
single proof needs to secure the entire chain of 0-RTT connections.  The
master resumption secret becomes a bearer token and needs to be protected
accordingly.

The Export Key Material API also needs to be updated.  The simplest
implementation where keys are derived from the current ephemeral secrets
will cause the exported keys to be different whenever new keys are
negotiated.  This will probably cause bugs at the application layer.  We
may need to have an EKM API that depends only on the original PSK, and
another one for generating ephemeral EKM material.

Bill

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Mar 2016 08:39:39 -0700

On Fri, Mar 25, 2016 at 8:33 AM, Bill Cox <[email-masked]> wrote:

> For channel binding, the only mode that seems to work with 0-RTT is when
> we issue new tickets on each 0-RTT connection to emulate a single session
> like we have in TLS 1.2, and use a replay cache on the server.  The only
> valid proof-of-possession the server can do with the client before
> processing application requests is the one done on the 1-RTT connection, so
> this single proof needs to secure the entire chain of 0-RTT connections.
> The master resumption secret becomes a bearer token and needs to be
> protected accordingly.
>

PTAL at draft-12 which has a definition of exporters based on the Exporter
Secret, which is computed at the end of the handshake.

-Ekr

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 25 Mar 2016 18:49:05 +0200

> require that the cipher suite negotiated from the original 1-RTT connection

TLS_PSK_* or TLS_ECDHE_PSK_*? Apparently the design currently includes
doing ECDHE_PSK_* together with PSK for 0-RTT. And the unified session
resumption is pure-PSK.

So it would look like there are at least two valid ciphersuites...
 
> master resumption secret becomes a bearer token and needs to be protected

Once the crypto problems with DH-0RTT are fixed, one can use that with
similar guarantees, but without sensitive state being kept by the client.
 
> another one for generating ephemeral EKM material.

Err... You mean new exporter keys when doing new handshake? If so, that
is intended. Or new exporter keys when rolling over keys? IIRC, key
rollover only updates traffic keys, not the key used for exporter.

And also, at TLS level? What is the "original PSK"?

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Mar 2016 10:05:43 -0700

Karthik,

Thanks for sending this. Some initial thoughts below.

> - context is a *public* value unique to the derived session. For example,
it could be defined as the session hash of the original handshake,
>   For example, it can be generated (out-of-band) as HKDF(PSK, “early data
context”)

There seem to be several ideas here:

1. Dispose of PreSharedKey and only use EarlyDataIndication.
2. Have an explicit context field that is derived in a deterministic
fashion.

I'm not sure that the first of these is a good idea, for several reasons.

1. While it's not sensible to have 0-RTT data encrypted with multiple
PSKs, it's not at all silly for the client to offer multiple PSKs to
the server. Note that the current TLS 1.2 PSK extension allows the
server to provide a hint on the theory that the client might have more
than one PSK. Having separate extensions allows this.

2. It burdens servers and clients which don't want to do 0-RTT (but do
want to do PSK-resumption) with 0-RTT machinery. This is a particular
concern with the extension version proposed above because it doesn't
give the client any way to say "this is just a resumption, I'm not
sending any 0-RTT data". This means that servers have to at least
implement the 0-RTT skipping algorithm even if they refuse 0-RTT. [You
could say that the server had indicated "I won't accept 0-RTT" when it
established the ticket, and then act as if the client complied but
that produces a really ugly decryption failure rather than a handshake
failure]. We'd at least want to restore the EarlyDataType value from
previous versions of EarlyDataIndication so that the client could
express what it did here.

The second idea seems sensible, and I do like the idea of binding the
session hash of the previous handshake into PSK-Resumption. One thing
that seems unclear would be what the responsibilities of the server
are with respect to the context. In the current draft, the client
and server both digest it explicitly but it's not signalled, which
has the disadvantage that you can't just run the session transcript
forward. If the client just provides it to the server, then that
seems to have different security properties unless we require the
server to verify it. Is that what you have in mind here?

I note that the context value here was intended for a different
purpose, namely tying the handshake to some external context (for
instance, if you have an external anti-replay mechanism). I'm not sure
if that's still valuable, but if we wanted to do so, then we'll need a
separate field somewhere.

Another possible design here would be:

        struct {
           opaque psk_identity<0..2^16-1>;
           opaque context<0..255>;
        } PreSharedKeyInfo;

        struct {
           select (Role) {
               case client:
                   PreSharedKeyInfo keys<2..2^16-1>;

               case server:
                   uint16 index;  // The selected index
           }
         } PreSharedKeyExtension;

         struct {
           select (Role) {
               case client:
                   CipherSuite cipher_suite;
                   select (key_exchange) {
                      case PSK:
                         uint16 index;   // PSK index

                      case (EC)DHE
                         opaque configuration_id<1..2^16-1>;
                         opaque server_context<0..255>; //
ServerConfiguration + Server Certificate + CertificateRequest
                   }
                   Extension extensions<0..2^16-1>;

               case server:
                  struct {};
                 }
         } EarlyDataIndication;

It's not super-elegant to have a switch here in the decode for
EarlyDataIndication, but they actually are semantically different, so
I'm not sure it's that bad. The idea here would be to design to a
different invariant, namely:

- The client gets to offer the server a bunch of options for the
  1-RTT handshake. The server picks one.

- The client offers the server exactly one option for 0-RTT and
  the server can take it or leave it.

This is the way that 0-RTT DHE works now. It does open the door
to the server somehow picking a different option for 1-RTT than
the client chose for 0-RTT, but this is something we could forbid.

>          EarlyDataType early_data_type

The cipher suites indication seems generally sensible.

> (c) willing to accept 0-RTT and has a replay cache that it uses to
prevent replay (all_early_data_allowed)

This is an interested suggestion. I agree that it's important to
be able to say "don't send me 0-RTT data" (see above). ISTM that
"all_early_data_allowed" would be useful primarily if we allowed
clients who received it to use the ordinary TLS 1.3 API for sending
0-RTT data. That would be a real advantage, it seems to me.

> (a) even a passive attacker could replay 0-RTT data, long after the
client has gone away,

Nit: This doesn't sound like a passive attacker to me...

> Even if we eliminate client certificate authentication from 0-RTT, this
> (a) the application may use TokenBinding or some such protocol to
authenticate 0-RTT data, and we need to understand what “channel binding”
to provide for this case,
> (b) in PSK resumption mode, since the handshake log does not contain much
information that is specific to the previous connection, it would be more
robust to add an explicit context.

Yes, I agree that this is an improvement.

-Ekr

On Fri, Mar 25, 2016 at 2:29 AM, Karthik Bhargavan <
[email-masked]> wrote:

> - context is a *public* value unique to the derived session. For example,
> it could be defined as the session hash of the original handshake,
> - the client should only send replayable data if
> replayable_early_data_allowed (e.g. GET requests)
> (b) replaying authenticated 0-RTT data can be more damaging (whether
> authenticated with client cert or with a cookie), and
> design of signing the Handshake Context that consists of the ClientHello +
> additional information from the previous handshake.
> Even if we eliminate client certificate authentication from 0-RTT, this
> notion of “context" is still useful for two reasons:
> authenticate 0-RTT data, and we need to understand what “channel binding”
> to provide for this case,
> (b) in PSK resumption mode, since the handshake log does not contain much
> information that is specific to the previous connection, it would be more
> robust to add an explicit context.
>
> extension, then we can use the hash of the ClientHello uniformly in all
> 0-RTT modes for deriving keys, and for deriving a channel binding for the
> application. Furthermore, we can safely introduce a PSK_ECDHE
> mode where the server sends its Certificate and CertificateVerify and its
> signature is correctly bound to the PSK (via the “context” field).
>
> Best regards,
> Karthik
>
>
>
>
>

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 25 Mar 2016 11:27:29 -0700

> in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3.

TLS is used by more than web browsers, so this unfortunately isn't the
case. In particular:

* There are applications and protocols built on top of TLS that do not
retry, because they are not replay safe. It's legitimate to prefer
bossiness over duplication, and to rely on TLS for anti-replay at the
transport layer.

* More commonly; there are many applications and protocols that are
tolerant of a small number of retries and even duplicates, but  suffer
severe harm in the face of a large or unbounded number of duplicates.

As a result of these new concerns, I would say that TLS 1.3 should
> recommend that all servers SHOULD

+1 but I think we can go further here and specify 0RTT in such a way that
it only works when the server maintains state, and so that any given 0RTT
ticket may only be used once (to preserve forward secrecy as much as
possible within the constrains of 0RTT).

-- 
Colm

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Mar 2016 11:36:29 -0700

> possible within the constrains of 0RTT).

I'm not enthusiastic about this. This seems like it would rule out a bunch
of implementations
which don't need that guarantee.

-Ekr

---

From: Karthik Bhargavan <[email-masked]>
Date: Fri, 25 Mar 2016 19:38:44 +0100

Hi Eric,

Yes, I now agree with Ilari and you that we should have a separate pre_shared_key extension
in order to signal multiple PSKs. I wonder if we could still share the structure between
PSK and DH though, although that’s mainly an aesthetic choice.

> server to verify it. Is that what you have in mind here?

I suggest that the “context” is something that the client generates
and the server must  check. 

When a client receives a DH ServerConfiguration,
or a NewSessionTicket, or an out-of-band PSK, it
generates and stores the context with the key material.

When the server receives the id+context, it always has
enough information to be able to check the context
after processing the id. (e.g. it decrypts the sessionticket
and then verifies the context.) The server must perform this check.

> purpose,

Yeah, sorry for reusing the name, but we were already using Handshake Context,
so perhaps this confusion was already there.

Best,
Karthik

> On Fri, Mar 25, 2016 at 2:29 AM, Karthik Bhargavan <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>

---

From: Karthik Bhargavan <[email-masked]>
Date: Fri, 25 Mar 2016 20:02:22 +0100

> +1 but I think we can go further here and specify 0RTT in such a way that it only works when the server maintains state, and so that any given 0RTT ticket may only be used once (to preserve forward secrecy as much as possible within the constrains of 0RTT). 

Do you envision clients only having one resumption handshake at a time? I was under the impression that TLS 1.2 clients typically open multiple
resumption handshakes in parallel, and that TLS 1.3 clients would want to do the same.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 25 Mar 2016 12:23:09 -0700

> which don't need that guarantee.

With 0RTT, it doesn't seem to be possible to have anti-replay of the
message itself without some kind of server state. It's also beneficial for
cryptographic safety to prevent at-will re-use of the ticket - other-wise
the data is subject to the kind of "try and iterate" attacks we've seen be
very successful against DTLS because of its tolerance for duplicate and out
of order messages. If server state is required, some more good can come of
it by improving the forward secrecy of the 0RTT data to match that of
regular data; which I think is most important of all.

An implementation would have to be willing to sacrifice replay protection,
some cryptographic safety and forward secrecy for the 0RTT data. I'm sure
there are implementations that would sacrifice these things to get lower
latency more cheaply, but should they be encouraged?  I'll admit that this
is an unfair simplification in this case since it's a more grey area, but
"fast, secure, cheap: pick two" is at play here, and many would pick "fast,
cheap".

-- 
Colm

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Mar 2016 12:23:28 -0700

> PSK and DH though, although that’s mainly an aesthetic choice.

Yes. I'm not wholly satisfied with what I posted here :)

> and then verifies the context.) The server must perform this check.

This is what I assumed. We would need to document that.

> so perhaps this confusion was already there.

I agree it was already confusing. I just wanted to note it for posterity

-Ekr

> much information that is specific to the previous connection, it would be
> more robust to add an explicit context.
>
>> design of signing the Handshake Context that consists of the ClientHello
>> + additional information from the previous handshake.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Mar 2016 12:24:32 -0700

On Fri, Mar 25, 2016 at 12:23 PM, Colm MacCárthaigh <[email-masked]>
wrote:

>>> +1 but I think we can go further here and specify 0RTT in such a way
>>> that it only works when the server maintains state, and so that any given
>>> 0RTT ticket may only be used once (to preserve forward secrecy as much as
>> I'm not enthusiastic about this. This seems like it would rule out a
>> bunch of implementations
> message itself without some kind of server state.
>

Yes.

> It's also beneficial for cryptographic safety to prevent at-will re-use of
> the ticket - other-wise the data is subject to the kind of "try and
> iterate" attacks we've seen be very successful against DTLS because of its
> tolerance for duplicate and out of order messages. If server state is
> required, some more good can come of it by improving the forward secrecy of
> the 0RTT data to match that of regular data; which I think is most
> important of all.
>
> latency more cheaply, but should they be encouraged?
>

The issue isn't encouraged. It's whether we should design the protocol so
that it cannot be implemented any other way.

-Ekr

>   I'll admit that this is an unfair simplification in this case since it's
> a more grey area, but "fast, secure, cheap: pick two" is at play here, and
> many would pick "fast, cheap".
>
>
> --
> Colm
>

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 25 Mar 2016 12:39:45 -0700

> that it cannot be implemented any other way.

I think it is encouraged ... not really intentionally, but economically.

We all know that the keys encrypting TLS tickets should be rotated
frequently; but that's not something that happens that much in the real
world. Take Apache httpd or nginx for example; both lack any support for
rotation schedules or key id indication in the ticket. I've encountered a
lot of environments using these, and other servers, and besides my own
employer - I've *never* seen an environment in which the keys are actually
rotated.  Folks, developers and operators, just set up things up to the
point there things "work".

The end effect is that users have no way to know if their connections are
actually forward secure. Now one could argue; that's impossible to begin
with - maybe the provider is logging everything, including the full request
and response bodies, and maybe those logs are weakly protected, and so on.
That's true, but it's rare, and particularly egregious. The default at the
transport layer should be to keep users sessions secret; even in the face
of a credential compromise. That's what we're aiming for with TLS1.3 I
think.

0RTT data is likely to contain request data; which I'd regard as sensitive
- so I really want to make sure it's protected and that a user can tell
with some confidence that it likely really is.

If we require server state; it flips the economics. The default "cheap" way
would be FS (no 0RTT), and if you do implement a session cache, you'll be
incentivized to evict entries ASAP with a single-use requirement. And it
gets us to a place where a compromise can only decrypt future sessions; not
previous ones - which is the same as (EC)DHE.

-- 
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 25 Mar 2016 12:41:04 -0700

On Fri, Mar 25, 2016 at 12:02 PM, Karthik Bhargavan <
[email-masked]> wrote:

> Do you envision clients only having one resumption handshake at a time? I
> was under the impression that TLS 1.2 clients typically open multiple

It is common for existing clients to re-use the same ticket for many
connections. This is at-odds with forward secrecy though :/ Clients could
have many resumption tokens at a time though; e.g. they could ask for 10
and use each one once. It's just that each token is used once. So parallel
resumptions could be supported.

-- 
Colm

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 26 Mar 2016 22:10:13 +0200

> that it cannot be implemented any other way.

Also, implementing protocol that it can't be done another way isn't
trivial (aside from limiting session IDs to some small size or something
line that...

If one has enough space to offload state, one can just ignore state
updates, making things replayable...

-Ilari

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 28 Mar 2016 11:11:03 -0500

On 03/25/2016 02:41 PM, Colm MacCárthaigh wrote:
> On Fri, Mar 25, 2016 at 12:02 PM, Karthik Bhargavan
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     > +1 but I think we can go further here and specify 0RTT in such a way that it only works when the server
>     maintains state, and so that any given 0RTT ticket may only be
>     used once (to preserve forward secrecy as much as possible within
>     the constrains of 0RTT).
>
>     Do you envision clients only having one resumption handshake at a
>     time? I was under the impression that TLS 1.2 clients typically
>     open multiple
> connections. This is at-odds with forward secrecy though :/ Clients
> could have many resumption tokens at a time though; e.g. they could
> ask for 10 and use each one once. It's just that each token is used
> once. So parallel resumptions could be supported.
>

I understand there are good reasons to want to make the default behavior
of a single-physical-server TLS server as secure as possible, but I
think it's also well-understood that the more "exciting" portions of
0-RTT happen in a distributed setup, where there are different physical
(well, maybe virtual) machines sharing a session ticket key, potentially
in different data centers.  I don't think we've seen a real description
of how this proposal for "single-use" session tickets would behave in
the distributed setup yet.  Are you proposing to require a distributed
replay cache shared by all machines sharing the session-ticket key?  I
expect a lot of pushback from operators in that case, since distributed
replay caches are really annoying to get right, let alone performant. 
So then the "single-use" property would come with a caveat, that it's
only "single use" per replay cache instance, and some limited number of
replays become possible.

Can you say more about how you envision your proposal working for these
distributed environments?

In a more general sense, it's starting to seem like we should consider
the spectrum from "actually no replays possible" to "some small number
of replays possible [on the order of the number of machines sharing the
session ticket key]" and ending at "nearly unlimited (millions+) of
replays possible".  I think avoiding the last case is a reasonable goal,
but I'm as-yet unconvinced that the first case is achievable. Perhaps
the middle ground is good enough...

-Ben

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 28 Mar 2016 10:13:29 -0700

On Mon, Mar 28, 2016 at 9:11 AM, Benjamin Kaduk <[email-masked]> wrote:
> of a single-physical-server TLS server as secure as possible, but I think
> it's also well-understood that the more "exciting" portions of 0-RTT happen
> in a distributed setup, where there are different physical (well, maybe
> virtual) machines sharing a session ticket key, potentially in different
> data centers.  I don't think we've seen a real description of how this
> proposal for "single-use" session tickets would behave in the distributed
> setup yet.  Are you proposing to require a distributed replay cache shared
> by all machines sharing the session-ticket key?  I expect a lot of pushback
> from operators in that case, since distributed replay caches are really
> annoying to get right, let alone performant.  So then the "single-use"
> property would come with a caveat, that it's only "single use" per replay
> cache instance, and some limited number of replays become possible.
>

> In a more general sense, it's starting to seem like we should consider the
> spectrum from "actually no replays possible" to "some small number of
> replays possible [on the order of the number of machines sharing the
> session ticket key]" and ending at "nearly unlimited (millions+) of replays
> possible".  I think avoiding the last case is a reasonable goal, but I'm
> as-yet unconvinced that the first case is achievable. Perhaps the middle
> ground is good enough...
>

I've come to the same conclusion: I don't think it's possible to eliminate
all possibility of replay - but it is possible to reduce it to a small
window, and I think there are pragmatic design steps that can be made that
reduce the idempotency risks too. I'm working on a small write-up now; will
send out later today.

-- 
Colm