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

[David Benjamin]

On Sun, Mar 12, 2017 at 8:09 PM Martin Thomson 
wrote:

> On 13 March 2017 at 10:55, Brian Smith  wrote:
> >> So, I'd prefer to bring session IDs back, and
> >> to arrange things so that they're always server-generated.
> >
> > 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.
>
> 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.
>

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

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

[Eric Rescorla]

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  wrote:

> Ivan Ristic  wrote:
> > - The opaque nature of this field also makes connection auditing more
> > difficult.
>
> This is intentional.
>
> > 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.
>
> 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.
>
> > - 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.
>
> 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
> > to arrange things so that they're always server-generated.
>
> 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/
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On 13 March 2017 at 10:55, Brian Smith  wrote:
>> So, I'd prefer to bring session IDs back, and
>> to arrange things so that they're always server-generated.
>
> 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.

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Brian Smith]

Ivan Ristic  wrote:
> - The opaque nature of this field also makes connection auditing more
> difficult.

This is intentional.

> 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.

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.

> - 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.

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
> to arrange things so that they're always server-generated.

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/

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

> On Mar 12, 2017, at 7:23 PM, Ivan Ristic  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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ivan Ristic]

On Sun, Mar 12, 2017 at 3:44 PM, Martin Thomson 
wrote:

> On 13 March 2017 at 09:23, Ivan Ristic  wrote:
> > - 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.
>
> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On 13 March 2017 at 09:23, Ivan Ristic  wrote:
> - 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.

For some people, tracking is an anti-feature.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ivan Ristic]

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