Subject: [TLS] Comments on the session ticket format in TLS 1.3

From: Ivan Ristic <[email-masked]>
Date: Sun, 12 Mar 2017 15:23:53 -0700

The "ticket" field in NewSessionTicket is opaque and can hold an identifier
or an actual encrypted ticket. I think this is problematic, for a couple of
reasons:

- Field and meaning overloading/reuse is a bad practice in general and
leads to programming errors. I feel that protocol design should encourage
good practices, not the other way round. Implementations that decide to
support both behaviours (IDs and tickets) will have to use an indicator to
differentiate between the two. In that light, I think it would be less
error prone to provide more detail at the protocol level.

- The opaque nature of this field also makes connection auditing more
difficult. For example, I'd like to know if session tickets are used to
resume for a particular connection. Perhaps more importantly, it would be
useful to identify specific ticket keys (to track their usage, rotation,
etc), age, encryption algorithm, and their strength.

- As a matter of approach, I think the protocol shouldn't leave design
decisions to implementors. These decisions (session ID/ticket usage, ticket
keys, ticket formats, and so on) will need to be made, and I think it's
better to make them part of the protocol, where they can be audited, etc.

- Finally, I feel that the effective removal of (visible) session IDs is a
regression. Being able to track sessions and resumption is useful to
understand traffic patterns. So, I'd prefer to bring session IDs back, and
to arrange things so that they're always server-generated.

I know these are not big problems (especially given the improvements made
to session tickets), but whatever is specified now will be used for a very
long time, and it would be a shame to leave these around.

-- 
Ivan

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Mar 2017 09:44:59 +1100

> to arrange things so that they're always server-generated.

For some people, tracking is an anti-feature.

---

From: Ivan Ristic <[email-masked]>
Date: Sun, 12 Mar 2017 16:23:03 -0700

> For some people, tracking is an anti-feature.

Sure, but the current session ticket design doesn't prevent tracking. At
best, it only makes it somewhat more expensive because trackers need to
construct their own session IDs from available connection data.

Another example, perhaps relevant: load balancers can often be configured
to use sticky sessions based on TLS session IDs. It's a useful feature
given that web servers typically don't have a good story for distributed
server-side TLS session storage. Without an explicit ID, they too would
need to make their own.

-- 
Ivan

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 12 Mar 2017 19:48:42 -0400

> On Mar 12, 2017, at 7:23 PM, Ivan Ristic <[email-masked]> wrote:
> 
> Another example, perhaps relevant: load balancers can often be configured to use sticky sessions based on TLS session IDs. It's a useful feature given that web servers typically don't have a good story for distributed server-side TLS session storage. Without an explicit ID, they too would need to make their own.

With session tickets, there's no need for server-side TLS session storage,
and no need for load-balancers to direct resuming TLS clients to the same
server.  All that's required is proper coordination of the distribution
and rotation of the short-term session ticket encryption keys.  This
improves the effectiveness of the load-balancer when some clients are
responsible for a large fraction of the load.

Opaque session tickets are just fine, and one can tell which connections
are reused by observing abbreviated handshakes.

For example, Gmail's SMTP servers all share the same session ticket encryption
keys, and any server can resume a session initiated by a different server.

Here's an example, in which an SMTP TLS client reuses a session with a
second Gmail SMTP server (w51si13238472qtb.292) 10 seconds after the
session is created with a first SMTP server (r3si13266009qkb.62):

$ posttls-finger -lmay -Lcache,summary -m 3 -r 10 gmail.com
posttls-finger: Connected to gmail-smtp-in.l.google.com[209.85.144.27]:25
posttls-finger: < 220 mx.google.com ESMTP r3si13266009qkb.62 - gsmtp
posttls-finger: > EHLO straasha.imrryr.org
posttls-finger: < 250-mx.google.com at your service, [108.21.89.116]
...
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 Ready to start TLS
posttls-finger: looking for session [209.85.144.27]:25&8A8ACB9F076F21BB0182A29964626E9B9E564450364F42705D3248594EF24C16 in memory cache
posttls-finger: save session [209.85.144.27]:25&8A8ACB9F076F21BB0182A29964626E9B9E564450364F42705D3248594EF24C16 to memory cache
posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[209.85.144.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
posttls-finger: > EHLO straasha.imrryr.org
posttls-finger: < 250-mx.google.com at your service, [108.21.89.116]
...
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 closing connection r3si13266009qkb.62 - gsmtp
posttls-finger: Reconnecting after 10 seconds
<...10 second delay...>
posttls-finger: < 220 mx.google.com ESMTP w51si13238472qtb.292 - gsmtp
posttls-finger: looking for session [209.85.144.27]:25&8A8ACB9F076F21BB0182A29964626E9B9E564450364F42705D3248594EF24C16 in memory cache
posttls-finger: reloaded session [209.85.144.27]:25&8A8ACB9F076F21BB0182A29964626E9B9E564450364F42705D3248594EF24C16 from memory cache
posttls-finger: gmail-smtp-in.l.google.com[209.85.144.27]:25: Reusing old session
posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[209.85.144.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 closing connection w51si13238472qtb.292 - gsmtp
posttls-finger: Found a previously used server.  Done reconnecting.

-- 
-- 
	Viktor.

---

From: Brian Smith <[email-masked]>
Date: Sun, 12 Mar 2017 13:55:08 -1000

Ivan Ristic <[email-masked]> wrote:
> difficult.

This is intentional.

> For example, I'd like to know if session tickets are used to

The server knows this information. if it wants you to know it, then it
can share it with you. If it doesn't, then you shouldn't be able to
know it, ideally.

> understand traffic patterns.

This is an attack on the client and server, which the protocol ideally
should prevent. In fact, I know at least one implementation is doing
extra work specifically to frustrate this kind of attack. Also the
charter says "Develop a mode that encrypts as much of the handshake as
is possible to reduce the amount of observable data to both passive
and active attackers."

> So, I'd prefer to bring session IDs back, and

Even in earlier versions, session IDs were not required with
resumption using tickets. The server sends an empty session ID and the
client may (should, IMO) send an empty session ID in the resumption
hello.

> I know these are not big problems (especially given the improvements made to
> session tickets), but whatever is specified now will be used for a very long
> time, and it would be a shame to leave these around.

This I agree with, except I think it's worth spending extra effort to
standardize the methods for preventing the thing you are asking for.

BTW, I understand you are asking for this for diagnostic reasons, not
for malicious reasons.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Mar 2017 11:09:23 +1100

> client may (should, IMO) send an empty session ID in the resumption

This is true, but I believe that there are compatibility reasons to
send the session ID anyway.  I don't know the details, but it probably
comes down to the load balancing thing that Ivan is asking about.

All told, this was a mess in previous versions.  Now we at least have
a hope of maintaining unlinkability.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 12 Mar 2017 17:17:00 -0700

I more or less concur with Brian and Martin.

I do think it would be worthwhile for someone to document a ticket
construction that's more
modern than the one in RFC 5705, but I don't think implementations should
be required
to implement any particular format.

-Ekr

On Sun, Mar 12, 2017 at 4:55 PM, Brian Smith <[email-masked]> wrote:

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

---

From: David Benjamin <[email-masked]>
Date: Mon, 13 Mar 2017 01:21:21 +0000

> a hope of maintaining unlinkability.

Clients send session IDs in TLS 1.2 because that is how the server
indicates a resumption. It echoes the client-sent ID back. Otherwise that
value has no meaning. (Go's implementation will just pick a random value
each time. OpenSSL derivatives hash the ticket.)

RFC 5077 does allow a client to leave it empty, but this is a mistake and
should not have been in the specification. That means a client must peek
ahead for ChangeCipherSpec to determine resumption. This is a huge source
of complexity (handshake/CCS synchronization is tricky as it is) and does
not work with DTLS.

David