Subject: [TLS] Negotiating with known_configuration

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jul 2015 13:04:14 +0200

The known_configuration mechanism in the current draft allows the
client to resurrect the handshake parameters (though not the keys)
which were negotiated in a previous handshake, but this is done
implicitly, i.e., the server provides a label and the client returns
it on the next connection. This has the advantage of keeping things
short but the disadvantage the it means that you can't have a static
configuration ID for everyone (instead, the server has to somehow
embed the properties in the configuration ID). After some thought,
I think this is a bad plan.

Here's what I propose (and what's in my slides for today):

- The client indicates configuration ID and cryptographic configuration,
  including the cipher suites and cryptographic extensions. This
  MUST replicate the server's selection from a previous handshake

- The server verifies the client's ClientHello and
  (a) Checks that configuration ID is valid
  (b) Verifies that client's parameters are what it would negotiate

Accordingly, this would change the extension to something like:

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

             case server:
               struct {};
           }
         } KnownConfigurationExtension

The server would just need one configuration for each public key and
woudldn't need to have any client-specific state. It also has the
benefit that it makes PSK work with 0-RTT.

Thoughts? Improvements?

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Jul 2015 04:10:56 -0700

>   MUST replicate the server's selection from a previous handshake

That's not going to work if there was no previous session.  For
instance, if the configuration was learned out of band.  It also
implies that the selection can come from ANY previous session, where I
think that it only makes sense to identify the session where the
configuration was learned.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jul 2015 13:12:38 +0200

On Tue, Jul 21, 2015 at 1:10 PM, Martin Thomson <[email-masked]>
wrote:

> instance, if the configuration was learned out of band.

Yes, that's an issue. Not entirely sure what to do about other than
have the server provide its negotiation preferences out of band
in that case.

 It also

> configuration was learned.

I agree with this point.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Jul 2015 04:30:12 -0700

> have the server provide its negotiation preferences out of band

I think that we could handle that at the point we define an
out-of-band configuration priming mechanism.  I don't think we need a
full negotiation model for the server.  A simple option would list the
server's preference order for suites and so forth in its configuration
advertisement; the client would then pick from that.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jul 2015 13:31:41 +0200

Yeah, or it could just have the semantics "this is my most preferred
configuration and if you send me anything compatible with it, I will
pick it"

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 21 Jul 2015 15:41:10 +0300

> configuration and if you send me anything compatible with it, I will

What cipher this is about? The cipher used for protecting 0RTT/Early
handshake data? The cipher used for protecting main connection?

For main connection, the server can pick from ciphersuites advertized
by client (assuming client gives ciphers that are acceptable and
are usable with configurations, i.e. GDHE_CERT-type things).

For 0-RTT/Early handshake data you want cipher that the server
supports and accepts. If it is about this, there could be multiple
allowed ciphers.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jul 2015 14:55:33 +0200

> handshake data? The cipher used for protecting main connection?

The former.

> are usable with configurations, i.e. GDHE_CERT-type things).

Agreed.

> supports and accepts. If it is about this, there could be multiple

In principle this is true. However, there are two complications, ISTM:

1. The client has no way of knowing which ciphers the server would support
other than the one it negotiated with the client previously (assuming
in-band)

2. I'm trying to avoid questions about the security of the negotiation for
the
0-RTT data, and we already have negotiated parameters.

I haven't done any analysis of what happens if the server doesn't check
that it would negotiate the parameters that the client provides. That might
be fine, but I'm trying to be conservative.

Thanks,
-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 21 Jul 2015 16:08:50 +0300

> other than the one it negotiated with the client previously (assuming

Well, if it is about supported ciphers, there could be multiple, and
the proposal has slot for only one.

> the 0-RTT data, and we already have negotiated parameters.

Can you give some examples of such questions?

> be fine, but I'm trying to be conservative.

I think it would either work fine (client picks something server supports/
accepts) or it would not work at all (client picks some unknown cipher).

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Jul 2015 06:38:28 -0700

> the proposal has slot for only one.

The proposal is for what the client selects and uses for its first flight.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 21 Jul 2015 17:15:59 +0300

> The proposal is for what the client selects and uses for its first flight.

Oh darn, mislooked what message it was.

Also, with regard to ending 0RTT, even without encrypted content
types. Either I am misunderstanding something, or:

- Client: Send ClientHello.
- Server: Read ClientHello.
- Client: Send 0-RTT & client cert.
- Server: Read 0-RTT & client cert.
- Client: Wait for server reply.
- Server: Wait for handshake message to end 0-RTT.
*deadlock*.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jul 2015 17:09:31 +0200

> - Server: Wait for handshake message to end 0-RTT.

Is this the case where the server is accepting 0-RTT or  rejecting it?

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 21 Jul 2015 18:17:49 +0300

> Is this the case where the server is accepting 0-RTT or  rejecting it?

Apparently, only for accepting case.

(If the server rejects, it can reply immediately, avoiding this
deadlock).

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Jul 2015 08:21:12 -0700

> (If the server rejects, it can reply immediately, avoiding this

I don't think that this is a concern.  You only have to say that the
server should not wait for the 0-RTT data before continuing with the
handshake.  At some level, you can safely consider 0-RTT data as being
streamable/equivalent to application data.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 21 Jul 2015 12:05:36 -0400

> benefit that it makes PSK work with 0-RTT.

A simple suggested improvement: name the fields clearly to indicate what they are.

e.g.

opaque server_configuration_identifier<0..2^16-1>;
CipherSuite early_data_cipher_suite;
Extension cached_server_extensions<0..2^16-1>;

Use this same ID field name in ServerConfiguration.

Also, why is this ID allowed to be so big? It's extreme overkill now that it's down to one config per pub key, with nothing client specific. It doesn't need a string with a 16-bit length; it barely needs a single 16-bit integer.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jul 2015 21:49:36 +0200

> streamable/equivalent to application data.

This is what I have been assuming.

-Ekr