Subject: [TLS] tickets or sesssions or both (oh my)

From: "Salz, Rich" <[email-masked]>
Date: Tue, 2 Sep 2014 13:05:09 -0400

Right now we have sessions (server-side, possible scalability issues) and tickets (client-side, hard to make work well with PFS).

A poll for this community: is one likely to be more strategic, or are both likely to be important in the near term  (say within two years after TLS 1.3 is done).

--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: [email-masked]<mailto:[email-masked]> Twitter: RichSalz

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Tue, 02 Sep 2014 19:06:25 +0200

May I ask — out of interest — what the problem is with session tickets 
in regards to PFS? Or is it just the key rotation thing?
Many browsers still don't implement session tickets, therefor removing 
sessions might be a problem that would be bad for fast adoption of 
version 1.3 (not that I count on this).

Richard

On 9/2/2014 7:05 PM, Salz, Rich wrote:
>
> Right now we have sessions (server-side, possible scalability issues) 
> and tickets (client-side, hard to make work well with PFS).
>
> A poll for this community: is one likely to be more strategic, or are 
> both likely to be important in the near term  (say within two years 
> after TLS 1.3 is done).
>
> -- 
>
> IM: [email-masked] <mailto:[email-masked]> Twitter: RichSalz
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 2 Sep 2014 13:15:48 -0400

> May I ask - out of interest - what the problem is with session tickets in regards to PFS? Or is it just the key rotation thing?

Yeah. " just" :)

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Tue, 02 Sep 2014 19:19:19 +0200

I can imagine that it's not just a “just” if you're Akamai, but it's 
definitely not that hard to solve the key rotation problem if you have a 
single server. Or if you have shared hosting for multiple servers. I 
think the technology is very useful for environments that have limited 
memory and/or storage. Of course default implementations would have to 
change. Right now e.g. nginx isn't rotation anything and shares sessions 
and keys among all defined servers. They are blaming OpenSSL for that, 
but that's just a library and the server should rotate and distribute 
the keys while each instance has its own library.

Isn't early termination a viable solution for bigger networks instead of 
sharing the keys among many servers like Twitter is doing it?

Richard

On 9/2/2014 7:15 PM, Salz, Rich wrote:
>
> > May I ask — out of interest — what the problem is with session 
> tickets in regards to PFS? Or is it just the key rotation thing?
>
> Yeah. “ just” J
>
> -- 
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 Sep 2014 17:26:05 +0000

On Tue, Sep 02, 2014 at 01:05:09PM -0400, Salz, Rich wrote:

> Right now we have sessions (server-side, possible scalability
> issues) and tickets (client-side, hard to make work well with PFS).
> 
> A poll for this community: is one likely to be more strategic,
> or are both likely to be important in the near term  (say within
> two years after TLS 1.3 is done).

My data point:

In Postfix SMTP servers, tickets are enabled by default, but a
server-side session cache needs to be enabled explicitly (due to
the scalability issue you note).  (Again in Postfix) There are no
problems with respect to PFS.  Session ticket encryption keys are
rotated hourly.  Session ticket encryption keys are less exposed
than cached session master keys (which are written to the session
cache database and deleted from there when the session expires and
is garbage collected), because session ticket encryption keys do
only live in memory.

>From my perspective, any weakening of PFS through the use of session
tickets is an application architecture artifact, and not an intrinsic
defect of tickets.  In some applications tickets are less likely
to lead to future exposure of keys than server-side session caches.

-- 
	Viktor.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 3 Sep 2014 00:06:22 +0200

Salz, Rich <[email-masked]>:

> Right now we have sessions (server-side, possible scalability issues) and
> tickets (client-side, hard to make work well with PFS).
>
>
>
> A poll for this community: is one likely to be more strategic, or are both
> likely to be important in the near term  (say within two years after TLS
> 1.3 is done).
>

As far as the actual network protocol is concerned, isn't the main
difference between session IDs and session tickets just that the session ID
has a maximum length of 32 bytes while a session ticket can be much longer
(65535 bytes) and comes with a lifetime hint? Other than that, the main
difference is in server details that are opaque to the client. If your
"encryption algorithm" for session tickets is to allocate a random 32-byte
ciphertext and define its decryption accordingly going forward, you're back
to session IDs. Similarly, you could fold session tickets into session IDs
by specifying ServerHello.session_id differently for a new protocol version
so that it can hold more information (however since ClientHello.session_id
needs to remain backwards-compatible, clients would still have to use the
TLS extension, so that's probably not a good idea).

The other main difference is that session IDs are part of the main spec,
while session tickets are an extension. This means that for maximum
benefit, you'll always need to support both because the other party may
not. So maybe what TLS 1.3 should be doing is merge part of the TLS session
ticket spec into the main document, using the traditional session ID fields
for legacy cases only (i.e., ClientHello.session_id would be present for
backwards compatibility but always empty unless you're trying to resume a
<= TLS 1.2 session), always using a session-ticket compatible on-the-wire
format with TLS 1.3 sessions. Servers could use this for tickets or for
short IDs based on their own preference.

The question that we're at then is, Does it make sense to complicate the
protocol just to allow clients to specify whether they prefer short (=
"session ID") or long (= "session ticket") session identifiers?  (If so,
why don't they just send a maximum length so that the server can act
accordingly -- e.g., omit a session identifier that the client would be
expected to ignore?)

Bodo

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Wed, 03 Sep 2014 01:24:08 +0200

I think it would be good to merge the tickets into the specs because in 
a long term the ticket approach makes much more sense. Clients are 
gaining more and more storage and maintaining a session cache for all 
clients is a huge burden for the servers. Especially if you're running a 
huge server network. As you all agreed with me, the fact that current 
web server implementations of server tickets are broken in regards to 
rotation is not a problem of the specs. Such a huge server network would 
have to share the session cache as well. Tickets are e.g. three 48 byte 
strings (plus maybe a timestamp or identifier) to share, that should be 
much easier and especially faster and less memory intensive.

On a last note, merging the tickets into the spec would also force 
browser vendors that are currently not supporting them to include 
support in the future (the major browsers are already offering support). 
Maybe it would be possible to remove sessions with the next incarnation 
of the specs entirely and not only simplify them again but also make 
something like a "maximum length" unnecessary. Tickets would have to be 
marked as successor of sessions. Honestly, I only see benefits from 
using tickets instead of sessions. Especially with the advent of HTTP/2 
where it won't be as problematic to transfer a few bytes as it is with 
HTTP/1.

Richard

On 9/3/2014 12:06 AM, Bodo Moeller wrote:
> Salz, Rich <[email-masked] <mailto:[email-masked]>>:
>
>     A poll for this community: is one likely to be more strategic, or
>     are both likely to be important in the near term  (say within two
>     years after TLS 1.3 is done).
>
>
> difference between session IDs and session tickets just that the 
> session ID has a maximum length of 32 bytes while a session ticket can 
> be much longer (65535 bytes) and comes with a lifetime hint? Other 
> than that, the main difference is in server details that are opaque to 
> the client. If your "encryption algorithm" for session tickets is to 
> allocate a random 32-byte ciphertext and define its decryption 
> accordingly going forward, you're back to session IDs. Similarly, you 
> could fold session tickets into session IDs by specifying 
> ServerHello.session_id differently for a new protocol version so that 
> it can hold more information (however since ClientHello.session_id 
> needs to remain backwards-compatible, clients would still have to use 
> the TLS extension, so that's probably not a good idea).
>
> The other main difference is that session IDs are part of the main 
> spec, while session tickets are an extension. This means that for 
> maximum benefit, you'll always need to support both because the other 
> party may not. So maybe what TLS 1.3 should be doing is merge part of 
> the TLS session ticket spec into the main document, using the 
> traditional session ID fields for legacy cases only (i.e., 
> ClientHello.session_id would be present for backwards compatibility 
> but always empty unless you're trying to resume a <= TLS 1.2 session), 
> always using a session-ticket compatible on-the-wire format with TLS 
> 1.3 sessions. Servers could use this for tickets or for short IDs 
> based on their own preference.
>
> The question that we're at then is, Does it make sense to complicate 
> the protocol just to allow clients to specify whether they prefer 
> short (= "session ID") or long (= "session ticket") session 
> identifiers?  (If so, why don't they just send a maximum length so 
> that the server can act accordingly -- e.g., omit a session identifier 
> that the client would be expected to ignore?)
>
> Bodo
>
>

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Wed, 03 Sep 2014 10:33:57 +0200

On 03/09/2014 00:06, Bodo Moeller wrote:
>      So maybe what TLS 1.3 should be doing is merge part of the TLS session
> <= TLS 1.2 session)

Technical nitpick: currently a non-empty ClientHello.session_id can also be used
with tickets:

   When presenting a ticket, the client MAY generate and include a
   Session ID in the TLS ClientHello.  If the server accepts the ticket
   and the Session ID is not empty, then it MUST respond with the same
   Session ID present in the ClientHello.  This allows the client to
   easily differentiate when the server is resuming a session from when
   it is falling back to a full handshake.

Which is useful IMO.

Manuel.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 3 Sep 2014 07:15:02 -0400 (EDT)

> From: "Richard Fussenegger, BSc" <[email-masked]>
> To: [email-masked]
> Sent: Wednesday, September 3, 2014 1:24:08 AM
> Subject: Re: [TLS] tickets or sesssions or both (oh my)

> I think it would be good to merge the tickets into the specs because in a
> long term the ticket approach makes much more sense. Clients are gaining
> more and more storage and maintaining a session cache for all clients is a
> huge burden for the servers. Especially if you're running a huge server
> network.
The one big feature of TLS 1.3 is PFS by default. It is hard to make tickets work with PFS, you need a synchronisation mechanism between servers one way or the other if you want to retain PFS. 

You can do tickets and not do synchronisation, in effect destroying PFS efforts, while you can't do IDs without synchronisation, so making them PFS-retaining is relatively simple. 

If anything, I'd say that we should drop tickets entirely from TLS 1.3, as the implementations don't implement them in a way that preserves general properties of protocol. 

-- 
Regards, 
Hubert Kario 
Quality Engineer, QE BaseOS Security team 
Email: [email-masked] 
Web: www.cz.redhat.com 
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 3 Sep 2014 13:02:02 +0200

>    it is falling back to a full handshake.

Right -- as when resuming based on the traditional ClientHello.session_id
(in which case the server responds with the same value in
ServerHello.session_id to confirm session resumption), the TLS session
ticket specification currently has the server mirror back a random "ID"
optionally presented by the client to confirm ticket-based session
resumption. Clients are not required to make use of this, but server-side
support is mandated.

It is useful to have *a* mechanism to explicitly confirm session resumption
so that the client already knows what to expect after having seen the
ServerHello, but I don't see a good reason to continue to overload
ClientHello.session_id and ServerHello.session_id with this particular
hack. If we remove the traditional semantics of ClientHello.session_id and
ServerHello.session_id for the new protocol version, an always-empty
ClientHello.session_id and a simple magic value in ServerHello.session_id
confirming session resumption would do: having the client send a made-up
session ID only adds overhead. (The reason to make use of
ServerHello.session_id for the proposed magic value is that the field is
already specified, and is related to session resumption; in principle, the
signal could go elsewhere in the ServerHello message.)

I'm guessing that the thinking underlying the specified use of the
session_id fields in RFC 5077 is that this makes it easier for both ways of
handling sessions to coexist (although based on code I've had to fix, I'm
not sure that it succeeded).  If traditional session IDs are no longer used
(because even stateful session resumption can use "session ticket"
mechanisms on the wire instead), that's no longer an issue.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 3 Sep 2014 13:24:34 +0200

Hubert Kario <[email-masked]>:

> The one big feature of TLS 1.3 is PFS by default. It is hard to make
> tickets work with PFS, you need a synchronisation mechanism between servers
> one way or the other if you want to retain PFS.
>
>
> You can do tickets and not do synchronisation, in effect destroying PFS
> efforts, while you can't do IDs without synchronisation, so making them
> PFS-retaining is relatively simple.
>
> If anything, I'd say that we should drop tickets entirely from TLS 1.3, as
> the implementations don't implement them in a way that preserves general
> properties of protocol.
>
>
What I'm proposing is to only have the session ticket *protocol* in TLS
1.3, but having the main RFC describe how this can be used to handle
session *IDs* (where session details are kept in server-side state). A
companion RFC can explain how to use this protocol for encrypted tickets:
this will need to include appropriate caveats for forward security.

Bodo

---

From: Hubert Kario <[email-masked]>
Date: Wed, 3 Sep 2014 07:40:30 -0400 (EDT)

> From: "Bodo Moeller" <[email-masked]>
> To: [email-masked]
> Sent: Wednesday, September 3, 2014 1:24:34 PM

> Hubert Kario < [email-masked] > :

> > > tickets
> > > work with PFS, you need a synchronisation mechanism between servers one
> > > way
> > > or the other if you want to retain PFS.
> > 
> 

> What I'm proposing is to only have the session ticket *protocol* in TLS 1.3,
> but having the main RFC describe how this can be used to handle session
> *IDs* (where session details are kept in server-side state). A companion RFC
> can explain how to use this protocol for encrypted tickets: this will need
> to include appropriate caveats for forward security.

What does re-purposing this filed give us (apart from confusion)? What can't be done by IDs? 

I see potential for abuse (putting there real tickets, not IDs) with no clear upside.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 3 Sep 2014 14:04:00 +0200

> What does re-purposing this filed give us (apart from confusion)? What

IDs, due to the size restriction, don't work if you really need tickets
holding encrypted state. Repurposing the session-ticket wire protocol,
then, *simplifies* the protocol by using a common protocol mechanism
regardless of which approach to resumable sessions a given server employs
(detailed server-side cached state, or tickets).

I understand that you want to get rid of tickets entirely, which means that
the session ID size restriction becomes a feature instead of a shortcoming.
My goal, instead, is to specify the protocol such that it still *allows*
servers to use tickets if they need to, while describing server-side cached
state as the default model for session caching.

Bodo

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 3 Sep 2014 08:04:37 -0400

> What I'm proposing is to only have the session ticket *protocol* in TLS 1.3, but having the main RFC describe how this can be used to handle session *IDs* (where session details are kept in server-side state). A companion RFC can explain how to use this protocol for encrypted tickets: this will need to include appropriate caveats for forward security.

+1

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: [email-masked] Twitter: RichSalz

---

From: Hubert Kario <[email-masked]>
Date: Wed, 3 Sep 2014 08:48:24 -0400 (EDT)

> Sent: Wednesday, September 3, 2014 2:04:00 PM

> > > 1.3,

> > What does re-purposing this filed give us (apart from confusion)? What
> > can't
> > be done by IDs?
> 

> holding encrypted state. Repurposing the session-ticket wire protocol, then,
> *simplifies* the protocol by using a common protocol mechanism regardless of
> which approach to resumable sessions a given server employs (detailed
> server-side cached state, or tickets).

> state as the default model for session caching.

I'm afraid that if clustering using a static encryption key for tickets is the easiest way to do clustering (and also fastest, since you don't need any inter-host communication), this will be what *everybody* will do, thus making the whole removal of kRSA ciphers for nought. 

So yes, from this point of view the limitation of session ID size is a feature. 

Could you provide an example of system that "really need[s] tickets"?

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Sep 2014 14:00:59 +0000

On Wed, Sep 03, 2014 at 07:15:02AM -0400, Hubert Kario wrote:

> The one big feature of TLS 1.3 is PFS by default. It is hard to
> make tickets work with PFS, you need a synchronisation mechanism
> between servers one way or the other if you want to retain PFS.

Sorry, this seems rather non-obvious.  How is stateless resumption
less compatible with PFS than stateful resumption?  What is this
PFS obstacle you speak of.  In Postfix PFS is on by default, as
are session tickets.

> You can do tickets and not do synchronisation, in effect destroying
> PFS efforts,

How so?  And presumably one can do tickets and synchronize key
rotation (at lower cost than synchronizing session state).

> while you can't do IDs without synchronisation, so making them

Why is there any interlock between PFS and who stores the state
for sessions?  The client presents a ticket to the server, which
is used to recover the server's session state.   This is no different
from recovering session state by any other means.

> If anything, I'd say that we should drop tickets entirely from
> TLS 1.3, as the implementations don't implement them in a way that
> preserves general properties of protocol.

Fix implementation defects.  I am not aware of *any* intrinsic
defects in tickets, and they solve a major scalability problem.

This WG appears lately to be on a slash and burn campaign to reduce
the broad applicability of TLS to just usability for certain types
of web server deployments.  This is troubling.

-- 
	Viktor.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 3 Sep 2014 16:02:58 +0200

Well, strictly speaking, no system really, really *needs* tickets because
you could always start new sessions if a supposedly resumable session can't
be found in the server's cache (at a computational cost, and at a latency
cost). However, for any system that's large enough to require load
balancing, a server-side session cache becomes unproportionally more
expensive than in a single server, and makes denial-of-service problems
more likely (badly behaved clients can fill up your session cache with
unneeded entries, eventually forcing you to expire useful entries). Make
the system global, and things get even worse: a session resumption request
may be for a session that hasn't been negotiated in the same area, and
might need to be fetched from elsewhere.

At some point, building a system to rotate expiring session-ticket
encryption keys just becomes a lot more attractive.

I completely agree that using a fixed key for session-ticket encryption is
not desirable, but deleting expired session-ticket encryption keys could
even become much more practical than deleting lots of expiring sessions in
a huge server-side session cache!

Bodo

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Sep 2014 14:11:49 +0000

On Wed, Sep 03, 2014 at 08:48:24AM -0400, Hubert Kario wrote:

> I'm afraid that if clustering using a static encryption key for
> tickets is the easiest way to do clustering (and also fastest,
> since you don't need any inter-host communication), this will be
> what *everybody* will do, thus making the whole removal of kRSA
> ciphers for nought.

The keys should NOT be static.  The cluster can employ at any given
time two keys, one used to encrypt new sessions, the other used to
decrypted as yet unexpired older sessions.  A new key is agreed
periodically, by the cluster nodes, and then used to encrypt new
sessions.

Postfix already does this on the scale of hundreds of separate
processes running on a single machine, extending this to multiple
nodes is not a big deal.

Let's fix the implementations by providing scalable technology for
cluster key rotation in TLS toolkits.  This will work *better* than
current technologies for sharing server-side session state!

Please DO NOT cripple TLS.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Sep 2014 14:13:41 +0000

> a huge server-side session cache!

I am not in the habit of "+1" style responses.  This is an exception:

+100

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 3 Sep 2014 10:15:13 -0400

> Postfix already does this on the scale of hundreds of separate processes
> running on a single machine, extending this to multiple nodes is not a big
> deal.

Okay, thanks, we're done here.  No offense, but you don't know what you are talking about.

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Wed, 03 Sep 2014 16:11:50 +0200

Could explain the exact problems to us?

Richard

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 3 Sep 2014 10:17:50 -0400

> Fix implementation defects.  I am not aware of *any* intrinsic defects in
> tickets, and they solve a major scalability problem.

I like tickets.  I prefer the client to hold the state.  Keeping PFS when a single "server" is in fact multiple servers distributed globally, sometimes in hostile countries, sometimes in racks that are owned by network operators, brings issues to the table that are, perhaps, new to this group.
 
> This WG appears lately to be on a slash and burn campaign to reduce the
> broad applicability of TLS to just usability for certain types of web server
> deployments.  This is troubling.

I don't see that happening.  Can you provide any examples?  Complexity is problematic, and people are looking for ways to reduce that. So far there hasn't been much action, just discussion; that seems right to me. And the biggest discussion (client auth and renegotiation) was definitely about addressing concerns for OTHER than big web deployments.  And even then, TLS 1.x isn't going away. 
--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: [email-masked] Twitter: RichSalz

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 3 Sep 2014 10:18:53 -0400

> Could explain the exact problems to us?

Let me know if my other note doesn't give enough explanation.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 3 Sep 2014 16:20:28 +0200

Viktor Dukhovni <[email-masked]>:

The keys should NOT be static.

Right.

> The cluster can employ at any given

This doesn't sound quite right, actually: generally, the new key must be
ready everywhere to decrypt session tickets before the first server
instance can actually start to use it to encrypt a session ticket.

Bodo

---

From: Hubert Kario <[email-masked]>
Date: Wed, 3 Sep 2014 10:30:00 -0400 (EDT)

----- Original Message -----
> From: "Viktor Dukhovni" <[email-masked]>
> To: [email-masked]
> Sent: Wednesday, September 3, 2014 4:00:59 PM

Tickets are usually implemented as a session info (master secret) encrypted
using a symmetric algorithm.

If the symmetric algorithm key doesn't change, then the scalability is higer
and ease of deployment is lower. You generate the ticket encryption key,
copy it to all servers and you have scalability implemented, no need for
servers to know about each other or have a common backend.

If you want to retain PFS, you need to regenerate the keys on a semi-frequent
basis (preferably less than 24h), which, from what I've been asking
administrators around, few *know* about, let alone actually do.
 
> rotation (at lower cost than synchronizing session state).

Because the ticket contains keys that can be used to decrypt
communication. If the key used to encrypt the ticket is static, this key
becomes the key to the kingdom.

So while the PFS will appear to work (you get your ECDHE, keys regenerated
for every new connection, etc.), the master secret will be encrypted always
using the same key and conveniently exposed to attacker.

> from recovering session state by any other means.

If the session data is stored server side, then it is not exposed
to the attacker, just a reference to it. So it doesn't need to be
encrypted and because it needs to be stored on a low latency
medium, it will be garbage collected relatively often, in effect, even
server break will expose just most recent sessions, not all of them.

> defects in tickets, and they solve a major scalability problem.

The whole idea behind the tickets is that every server in cluster has
the key to the kingdom (past and future) so that it can decrypt any
valid ticket presented by client. That is intrinsic problem with
tickets-not-used-as-IDs.

> of web server deployments.  This is troubling.

This is applicable to all systems that can be clustered and can use
session resumption. It applies just as much to SMTP as it does to HTTP.

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Wed, 03 Sep 2014 16:42:22 +0200

That's a very good explanation and perhaps admins should be more 
educated on this matter. But the problem here aren't the admins, the 
libraries are. They should take care to frequently rotate the keys like 
Twitter is doing it (by themselves):

https://blog.twitter.com/2013/forward-secrecy-at-twitter

It's really not that hard to implement, even for clusters as we an see 
from the Twitter example. Nginx is already offering key file support, 
but no rotation scheme for single installations. This means cluster 
support is given for people who know what they're doing. But the common 
admin is left alone in the dark, thinking PFS is working great (maybe 
even checked in with SSLLabs or something) and in reality it's not. This 
problem has to be fixed, but it's not a problem of the specs!

I think (to add to Rich Salz's comment) that tickets are best suited for 
hostile servers. Because you can simply increase the rotation frequency 
and you only have a key for decryption. It's not said that you'll ever 
receive all those tickets from the clients afterwards. On the other hand 
with the sessions you'll have direct access to all those sessions. 
(Correct me if I'm wrong here.)

Richard

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Wed, 03 Sep 2014 16:50:58 +0200

> Okay, thanks, we're done here.  No offense, but you don't know what you are
I don't have any experience with large scale deployments, but it seems to me
that sharing and syncing regularly rotated keys among nodes should not be harder
than sharing a large cache of sessions, maybe even easier due to the smaller
size of the data to share. With the experience you have, would you agree with
this? If not, for my own education, I'd be curious to know why.

It seems to me the main problem with tickets is that they are easier to deploy
in a way that destroys PFS than to deploy in a way that preserves it. Being
easier to deploy in an insecure way that will appear to "work" just fine is
obviously an undesirable property.

Just to be clear, I'm not saying this is a sufficient reason to drop session
tickets, my humble opinion is they bring more good than potential issues. But if
we want to be serious about PFS in TLS 1.3, what's currently 5.5 of RFC 5077
should probably be expanded, and the wording made stronger (eg "keys MUST be
changed regularly").

Manuel.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Sep 2014 14:55:54 +0000

On Wed, Sep 03, 2014 at 10:30:00AM -0400, Hubert Kario wrote:

> and ease of deployment is lower.

If the key is never changed, the implementation is flawed.  This
is not a TLS problem.

> You generate the ticket encryption key, copy it to all servers and you
> have scalability implemented, no need for servers to know about each
> other or have a common backend.

This is a poor server design.  Not a TLS problem.

> basis (preferably less than 24h),

Postfix rotates keys hourly by default, with two keys present at
any time, the new encryption-and-decryption key plus old decryption-only
key.  The keys are managed by a shared back-end service, which
holds them in memory, "cluster" nodes (smtpd processes) obtain the
key from the back-end service on a cache lookup miss.  To extend
this to multiple nodes, just add authentication between the cluster
node and the back-end service, and replicate the back-end service.

> which, from what I've been asking

We need to provide them with better tools, not cripple TLS.

> becomes the key to the kingdom.

Not a TLS problem.  The key should not be static.  There are existing
deployments in which keys are not static.

> using the same key and conveniently exposed to attacker.

Not a TLS problem.  That's a problem for the vendors providing
cluster HTTPS servers.  This is an nginx, Apache, F5, ... problem.
Write blogs exposing their negligence until they fix their problem.

> server break will expose just most recent sessions, not all of them.

With tickets, the same text applies to the session ticket keys,
with s/session data/session ticket keys/g.  The problem is lame
implementations of session ticket with static keys.  That's not a
TLS problem.  Let's solve the right problem.

> valid ticket presented by client. That is intrinsic problem with

No, not "the key", rather "a current key", just as with "an unexpired
session".  With Postfix the lifetime (for encrypting) of session
ticket keys is equal to the session lifetime, it then is retained
that long again for decrypting older sessions while the new encryption
key is young.  This simplifies securing session data, because the
session data need never hit a vulnerable shared store and the keys
are only ever in memory.

> session resumption. It applies just as much to SMTP as it does to HTTP.

And yet, it does not apply to Postfix, where ticket key management
is done right.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Sep 2014 14:59:45 +0000

> instance can actually start to use it to encrypt a session ticket.

Depends on the design, session tickets carry 16 byte key ids, and
a cache-miss protocol can be used to fetch a key not yet present
on a node, but there also other ways to do this.

What I described works for a cluster of processes in Postfix, so
it is not wrong, it is just simpler than a multi-node cluster,
because authorization of key lookups is via unix-domain socket
permissions, rather than something more complex.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Sep 2014 15:00:56 +0000

> what you are talking about.

Or perhaps you don't know what I know.  That kind of feedback is
not appropriate on IETF lists I believe.

-- 
	Viktor.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Wed, 03 Sep 2014 17:04:41 +0200

On 03/09/2014 13:02, Bodo Moeller wrote:
> hack.

Agreed.

> If we remove the traditional semantics of ClientHello.session_id and
Another good place for that might be the SessionTicket extension in the
ServerHello. (That would mean changing its current meaning obviously.)

> mechanisms on the wire instead), that's no longer an issue.
I agree with that.

Manuel.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 3 Sep 2014 17:12:22 +0200

> ServerHello. (That would mean changing its current meaning obviously.)

Right, that was the specific other location within the ServerHello that I'd
been thinking of :-)

[However, if we're willing to make changes to the server's use of the
SessionTicket extension, I think I'd instead argue in favor of omitting it
entirely with the new protocol version, on the grounds that with the
proposed protocol change, *all* servers would be required to support the
protocol mechanism: Thus, there's no need to negotiate it explicitly.
Similarly, the client's SessionTicket extension could be omitted if it's
empty, except as required for backwards compatibility with earlier protocol
versions.]

Bodo

---

From: Hubert Kario <[email-masked]>
Date: Wed, 3 Sep 2014 12:06:30 -0400 (EDT)

----- Original Message -----
> Sent: Wednesday, September 3, 2014 4:55:54 PM

Protocol that is easy to get wrong *is* a bad protocol and it is a fault
with protocol.

For now, TLS 1.3 + session tickets ranks at 9 or 10 (at best) and
realistically at 14 on Rusty's scale of good design[1], while ID's are at level 5:

 1 - https://lkml.org/lkml/2007/6/10/99

For a protocol that peoples lives will depend on it is not good enough.

Session resumption is an optional functionality, and yet we're ready to
forfeit PFS just for ease of implementation of it for big deployments.

if you have a deployment big enough that scaling of memcached (or similar
databases) becomes an issue, you certainly have load balancers and as
such, can segregate users based on their session id's to specific
"sub cluster" that can actually resume their session.

On the the other hand static keys for tickets can impact the smallest deployments.

> Write blogs exposing their negligence until they fix their problem.

the problem is, that as a user, I can't detect if they do the right
thing or not, the ticket is an opaque blob I have no way of knowing if
they rotate keys or not (doubly so if the implementation saves time in
ticket and refuses to resume old sessions, not because the key changed).

---

From: Hubert Kario <[email-masked]>
Date: Wed, 3 Sep 2014 12:21:58 -0400 (EDT)

----- Original Message -----

> Sent: Wednesday, September 3, 2014 4:42:22 PM

> That's a very good explanation and perhaps admins should be more educated on
> this matter. But the problem here aren't the admins, the libraries are. They
> should take care to frequently rotate the keys like Twitter is doing it (by
> themselves):

> It's really not that hard to implement, even for clusters as we an see from
> the Twitter example. Nginx is already offering key file support, but no
> rotation scheme for single installations. This means cluster support is
> given for people who know what they're doing. But the common admin is left
> alone in the dark, thinking PFS is working great (maybe even checked in with
> SSLLabs or something) and in reality it's not. This problem has to be fixed,
> but it's not a problem of the specs!
I'd love for the admins to be better educated, but considering that around 0.5% of servers still are vulnerable to Hearbleed (over 700 machines verified), 7% vulnerable to the CCS issue (CVE-2014-0224), 20% of servers still enable SSLv2[1], over 3% enabling AECDH and 17% enabling single DES cipher suites[2], hoping for admins to do the right thing is bad idea. Many of them will get it wrong as they have shown time and time again. 

The point is that getting ID's correct is easy, getting tickets correct is not obvious (most people won't even know there *is* a problem in the first place) and requires "superfluous" code. 

> hostile servers. Because you can simply increase the rotation frequency and
> you only have a key for decryption. It's not said that you'll ever receive
> all those tickets from the clients afterwards. On the other hand with the
> sessions you'll have direct access to all those sessions. (Correct me if I'm
> wrong here.)

If the remote server is compromised, how distributing "just" decryption keys to it is not a problem from PFS point of view? This one server will have the keys to the kingdom, even if they change often, they will allow you to decrypt all communication to other servers from the point of compromise onward. With IDs the server will start misbehaving (asking for more IDs than connections, asking for all IDs, asking for IDs of connections that got terminated some place else), with tickets, it will be invisible. 

1 - https://www.trustworthyinternet.org/ssl-pulse/ 
2 - https://securitypitfalls.wordpress.com/2014/08/25/august-2014-scan-results/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Sep 2014 16:39:49 +0000

On Wed, Sep 03, 2014 at 12:21:58PM -0400, Hubert Kario wrote:

> The point is that getting ID's correct is easy, getting tickets
> correct is not obvious (most people won't even know there *is* a
> problem in the first place) and requires "superfluous" code.

In any cluster, sharing of keys and sharing of sessions are identical
problems.  The fact that some implementations have been sloppy in
support for session tickets is solely a problem of those implementations.

They probably don't have a shared backing store for sessions either.
This is a poorly designed cluster.  This problem has solutions,
and session tickets avoid potential for all too easy denial of
service on server-side session caches.

Please do not cripple TLS.  I don't want to have to disable TLSv1.3
support when TLSv1.3 appears.

Session tickets do not compromise PFS.  Many servers are not
clustered, and work much better with session tickets than with a
memory resident session cache.  Please do not cripple TLS.

That's all I have to say on this thread.  Thanks for the bandwidth.

-- 
	Viktor.

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Wed, 03 Sep 2014 18:47:11 +0200

On 9/3/2014 6:21 PM, Hubert Kario wrote:
>
> ------------------------------------------------------------------------
>
>     *From: *"Richard Fussenegger, BSc" <[email-masked]>
>     *To: [email-masked]
>     *Sent: *Wednesday, September 3, 2014 4:42:22 PM
>     *Subject: *Re: [TLS] tickets or sesssions or both (oh my)
>
>     educated on this matter. But the problem here aren't the admins,
>     the libraries are. They should take care to frequently rotate the
>     keys like Twitter is doing it (by themselves):
>
>     It's really not that hard to implement, even for clusters as we an
>     see from the Twitter example. Nginx is already offering key file
>     support, but no rotation scheme for single installations. This
>     means cluster support is given for people who know what they're
>     doing. But the common admin is left alone in the dark, thinking
>     PFS is working great (maybe even checked in with SSLLabs or
>     something) and in reality it's not. This problem has to be fixed,
> I'd love for the admins to be better educated, but considering that 
> around 0.5% of servers still are vulnerable to Hearbleed (over 700 
> machines verified), 7% vulnerable to the CCS issue (CVE-2014-0224), 
> 20% of servers still enable SSLv2[1], over 3% enabling AECDH and 17% 
> enabling single DES cipher suites[2], hoping for admins to do the 
> right thing is bad idea. Many of them will get it wrong as they have 
> shown time and time again.
>
My point was that the admins aren't the people who are responsible for 
the defect, the library and software developers are. But they are 
ignoring it, even if tickets are created were users ask them to fix it. 
In case of nginx it's even more problematic because they have the flawed 
tickets activated by default. The burden to either configure them 
correctly (by e.g. restarting the server on a regular basis *hack*) or 
disable tickets is up to the admins.
>
>     I think (to add to Rich Salz's comment) that tickets are best
>     suited for hostile servers. Because you can simply increase the
>     rotation frequency and you only have a key for decryption. It's
>     not said that you'll ever receive all those tickets from the
>     clients afterwards. On the other hand with the sessions you'll
>     have direct access to all those sessions. (Correct me if I'm wrong
>     here.)
>
>
> If the remote server is compromised, how distributing "just" 
> decryption keys to it is not a problem from PFS point of view? This 
> one server will have the keys to the kingdom, even if they change 
> often, they will allow you to decrypt all communication to other 
> servers from the point of compromise onward. With IDs the server will 
> start misbehaving (asking for more IDs than connections, asking for 
> all IDs, asking for IDs of connections that got terminated some place 
> else), with tickets, it will be invisible.
>
Although you make a strong point here, you nullify it directly again by 
your own paragraph from above. You trust the same admins that aren't 
even able to simply update their OpenSSL library to implement some kind 
of intrusion detection for their session storage. Don't get me wrong, I 
understand your point and it seems quite right to me.

Current implementations of session caches are also flawed. They are 
shared among many (virtual) hosts and the ID isn't validated against the 
requested host (well, at least as far as I know; again correct me).

Also consider this, if current libraries wouldn't be correctly 
implementing the TTL of session caches, wouldn't this system face the 
same problem?

Richard

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Wed, 03 Sep 2014 18:49:37 +0200

Full agreement here and it underlines what I've written in my last mail. 
Just because current implementations implemented session caches 
correctly but knowingly implemented tickets incorrectly doesn't make 
tickets incorrect or flawed.

The topic on how we can easily detect compromised servers with either 
system is a different and very interesting discussion that I'd love to 
investigate further.

Richard

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Wed, 3 Sep 2014 12:57:18 -0400

Forgetting about PFS for a minute, there is another trade-off on the server-side session vs client-side ticket designs.
The following may be dismissed as an application or API problem, but we’ve found it vexing in building and proving our TLS implementation.

How is a client supposed to cache and reuse tickets? Does it store it indexed by the hostname? + port? + ip address? + certificate?
Obviously, if a client is given a ticket by one (malicious) TLS server and incorrectly uses it with a different (honest) TLS server, 
this breaks confidentiality for the resumed connection (since the malicious server can read it.)

Different client libraries and client applications (e.g. browsers) seem to manage client-side caches differently. 
If tickets make it into the TLS 1.3 spec, it would be great to give strong recommendations on how to store tickets 
at the client side and when the client should use a ticket it has stored earlier. 

(E.g. A client that uses a database of tickets indexed by IP address + Port (only) when speaking to multiple servers does not provide confidentiality for resumed connections.)

---

From: Hubert Kario <[email-masked]>
Date: Wed, 3 Sep 2014 13:05:44 -0400 (EDT)

----- Original Message -----

> To: "Hubert Kario" <[email-masked]>
> Cc: [email-masked]
> Sent: Wednesday, September 3, 2014 6:47:11 PM

> > > from
> > I'd love for the admins to be better educated, but considering that around
> > 0.5% of servers still are vulnerable to Hearbleed (over 700 machines
> > verified), 7% vulnerable to the CCS issue (CVE-2014-0224), 20% of servers
> > still enable SSLv2[1], over 3% enabling AECDH and 17% enabling single DES
> > cipher suites[2], hoping for admins to do the right thing is bad idea. Many
> > of them will get it wrong as they have shown time and time again.
> 

> > The point is that getting ID's correct is easy, getting tickets correct is
> > not obvious (most people won't even know there *is* a problem in the first
> > place) and requires "superfluous" code.
> 

> My point was that the admins aren't the people who are responsible for the
> defect, the library and software developers are.
yes and no. While the "obvious bad" implementation is the result of developers, this implementations will stay like this because users will demand for their flawed deployments to continue working. Without dropping support for tickets, I don't think we can realistically get rid of the bad implementations. 

> > > and

> > If the remote server is compromised, how distributing "just" decryption
> > keys
> > to it is not a problem from PFS point of view? This one server will have
> > the
> > keys to the kingdom, even if they change often, they will allow you to
> > decrypt all communication to other servers from the point of compromise
> > onward. With IDs the server will start misbehaving (asking for more IDs
> > than
> > connections, asking for all IDs, asking for IDs of connections that got
> > terminated some place else), with tickets, it will be invisible.
> 

> Although you make a strong point here, you nullify it directly again by your
> own paragraph from above. You trust the same admins that aren't even able to
> simply update their OpenSSL library to implement some kind of intrusion
> detection for their session storage. Don't get me wrong, I understand your
> point and it seems quite right to me.
This is a big vs single host deployment difference. 
I can expect a big deployment to have proper monitoring. For single host just key rotation or session cache lifetime matters. 

> Current implementations of session caches are also flawed. They are shared
> among many (virtual) hosts and the ID isn't validated against the requested
> host (well, at least as far as I know; again correct me).

> Also consider this, if current libraries wouldn't be correctly implementing
> the TTL of session caches, wouldn't this system face the same problem?
No - because if they didn't implement TTL for cache, they would quickly run out of memory and stop working (probably trashing the whole server in process). That would be an obvious error. 

It's hard to get IDs wrong. And if you do, you won't compromise PFS (short of exporting master secret as the ID...). 
It's easy to get tickets wrong. And if you do, you can hide it well enough that without source code access you won't be able to detect it.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 10:34:02 -0700

> this breaks confidentiality for the resumed connection (since the malicious server can read it.)

As long as we address the master secret manipulation attack properly,
the ability of an attacker to generate a ticket that is both a)
accepted by the honest server and b) corresponds to the master (or
pre-master) that both client and server will use, is limited.

Add to that the fact that integrity and confidentiality protections on
the ticket need to be adequate. That ensures that tickets can't be
decrypted or synthesized.

While I think that Bodo's suggestion regarding a single mechanism is
basically OK, I don't think we should punt the description of tickets
and these concerns to another document.  I'd prefer if we pull all
forms of resumption in to the main TLS 1.3 draft and have the
considerations properly articulated there.  It's not as though we
don't have the information already at hand.

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Wed, 03 Sep 2014 19:47:43 +0200

On 9/3/2014 7:05 PM, Hubert Kario wrote:
>
> yes and no. While the "obvious bad" implementation is the result of 
> developers, this implementations will stay like this because users 
> will demand for their flawed deployments to continue working. Without 
> dropping support for tickets, I don't think we can realistically get 
> rid of the bad implementations.
>
Actually fixing current implementations wouldn't break anything, because 
the keys would simply start to rotate. Otherwise the admins wouldn't be 
able to restart their flawed web servers ever, as this would apparently 
break their complete deployment following your logic. So that's not a 
valid argument.

> I can expect a big deployment to have proper monitoring. For single 
> host just key rotation or session cache lifetime matters.
>
No worries, I understood that. But the joke is, as soon as the software 
is fixed all small implementations are fixed (well, at least those that 
are updating and note that the ones that have a Heartbleed bug shouldn't 
even think about PFS).

>
>     Current implementations of session caches are also flawed. They
>     are shared among many (virtual) hosts and the ID isn't validated
>     against the requested host (well, at least as far as I know; again
>     correct me).
>
>     implementing the TTL of session caches, wouldn't this system face
>     the same problem?
>
>
> No - because if they didn't implement TTL for cache, they would 
> quickly run out of memory and stop working (probably trashing the 
> whole server in process). That would be an obvious error.
>
> It's hard to get IDs wrong. And if you do, you won't compromise PFS 
> (short of exporting master secret as the ID...).
> It's easy to get tickets wrong. And if you do, you can hide it well 
> enough that without source code access you won't be able to detect it.
>
You're most certainly correct here with the memory limit regarding TTLs 
and I only meant it as a mind game and not like actually implementing 
it. Re-read it and you'll notice. ;-)

But don't jump right over the Virtual Host Confusion [1] problem. That's 
a realistic problem for all and was used against Akamai [2], Pinterest 
[3], Dropbox [4], … which I assume using clusters. How can we detect it? 
Well, go over the source code.

Same problem, different implementation.

Richard

[1] https://bh.ht.vc/vhost_confusion.pdf
[2] https://www.youtube.com/watch?v=YKD-i4HbbGg
[3] https://www.youtube.com/watch?v=h0VhFlTP2xw
[4] https://www.youtube.com/watch?v=CkOGKi0pKdk

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 3 Sep 2014 20:53:32 +0200

> forfeit PFS just for ease of implementation of it for big deployments.

I'm certainly not willing to forfeit forward secrecy (although I wouldn't
want to call it "perfect" forward secrecy ever, and certainly not if we're
allowing *any* kind of session caching); hence
http://marc.info/?l=openssl-cvs&m=128283567020551, but of course, that
one's not very practical for most use cases -- that's one tradeoff:
encrypted session tickets are another.

I do think that RFC 5077 is problematic in that it makes it too easy to get
key management wrong, and has incomplete Security Considerations. That's
among the reasons why I'd prefer to have a clearer separation between the
wire protocol (which doesn't depend on "tickets" being tickets, as opposed
to random IDs) and the actual ticket-encryption mechanism. Then protocol
implementations would be able to use much of the same code with a
server-side session cache (which generally seems to be the most reasonable
default) and with encrypted session tickets (which generally require more
of a set-up to use securely).

Of course, it's also possible to lose forward secrecy via a server-side
session cache. Maybe you're just not expiring entries properly, maybe your
session store gets backed up daily, whatever. Avoiding session tickets is
no panacea.

Bodo

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Wed, 3 Sep 2014 14:57:14 -0400

> pre-master) that both client and server will use, is limited.

True, but if we use a 0RTT resumption scenario where the client starts 
sending data immediately without waiting to see whether the server accepted the ticket, 
then this data is forfeit.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 3 Sep 2014 15:00:32 -0400 (EDT)

----- Original Message -----

> Sent: Wednesday, September 3, 2014 7:47:43 PM

> > developers, this implementations will stay like this because users will
> > demand for their flawed deployments to continue working. Without dropping
> > support for tickets, I don't think we can realistically get rid of the bad
> > implementations.
> 

> Actually fixing current implementations wouldn't break anything, because the
> keys would simply start to rotate. Otherwise the admins wouldn't be able to
> restart their flawed web servers ever, as this would apparently break their
> complete deployment following your logic. So that's not a valid argument.
I'm not saying that we should remove tickets from TLS 1.2. There are many deployments that simply don't care for PFS, where the failures in ticket implementations are actually features. 

I'm talking about refusing to use tickets in TLS 1.3 context. If the server negotiates TLS 1.3, I say it MUST NOT assign a ticket. Nothing would stop working, 
at worst for implementations that ignored IDs, the clients would just perform full handshake. 

> > I can expect a big deployment to have proper monitoring. For single host
> > just
> > key rotation or session cache lifetime matters.
> 

> No worries, I understood that. But the joke is, as soon as the software is
> fixed all small implementations are fixed (well, at least those that are
> updating and note that the ones that have a Heartbleed bug shouldn't even
> think about PFS).
The truth is that developers are lazy (and I include myself in this set too) and prefer not to touch code that works. If it is possible to move the bad code from TLS 1.2 to TLS 1.3 it will be reused this way. We have real world examples of people doing it wrong, while we can fix it for the OSS servers, there will always be people that make their own servers (just because of NIH, if nothing else) and do it wrong. 

I'd prefer if the "do it wrong" required more effort than "do it correctly". 

> > > shared

> > > implementing
> > No - because if they didn't implement TTL for cache, they would quickly run
> > out of memory and stop working (probably trashing the whole server in
> > process). That would be an obvious error.
> 

> > It's hard to get IDs wrong. And if you do, you won't compromise PFS (short
> > of
> > exporting master secret as the ID...).
> 
> > It's easy to get tickets wrong. And if you do, you can hide it well enough
> > that without source code access you won't be able to detect it.
> 

> You're most certainly correct here with the memory limit regarding TTLs and I
> only meant it as a mind game and not like actually implementing it. Re-read
> it and you'll notice. ;-)

> But don't jump right over the Virtual Host Confusion [1] problem. That's a
> realistic problem for all and was used against Akamai [2], Pinterest [3],
> Dropbox [4], … which I assume using clusters. How can we detect it? Well, go
> over the source code.

> [4] https://www.youtube.com/watch?v=CkOGKi0pKdk

I haven't analysed the attack in detail, but wouldn't a straight forward implementation of tickets have the same issue?

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Wed, 03 Sep 2014 21:28:39 +0200

On 9/3/2014 9:00 PM, Hubert Kario wrote:
>
> I'm not saying that we should remove tickets from TLS 1.2. There are 
> many deployments that simply don't care for PFS, where the failures in 
> ticket implementations are actually features.
>
> I'm talking about refusing to use tickets in TLS 1.3 context. If the 
> server negotiates TLS 1.3, I say it MUST NOT assign a ticket. Nothing 
> would stop working,
Got your point there, that's the main discussion here and I'm a friend 
of the ticket approach because it removes the burden from the servers to 
maintain a cache. But TLS 1.3 would have to be changed to say that keys 
MUST be rotated at least within 24 hours. This would be backwards 
compatible as well and ensure PFS.

Of course the problem with a compromised server to which we sync the key 
is still in the room. As I said, I'd love to go into more detail on this 
topic. But the question here is more like “how can we detect that a 
server is compromised?” The same question in regards to session caches. 
If a compromised server doesn't start to behave totally weird it's going 
to be very hard to detect it. Plus, is this even a problem of TLS per 
se? What if the server maintaining the session cache is compromised, how 
do we tackle that (with TLS)? You'll notice that there are many 
questions that have nothing to do with the protocol.

>
> The truth is that developers are lazy (and I include myself in this 
> set too) and prefer not to touch code that works. If it is possible to 
> move the bad code from TLS 1.2 to TLS 1.3 it will be reused this way. 
> We have real world examples of people doing it wrong, while we can fix 
> it for the OSS servers, there will always be people that make their 
> own servers (just because of NIH, if nothing else) and do it wrong.
>
As I see it right now, both cache and tickets are easy to get wrong and 
the only thing that's currently implemented wrong in regards to tickets 
is the fact that servers aren't rotating them. So it's a minor fix and 
I'm currently looking into the nginx source code to see if I'm able to 
create a patch for it.

>
> I haven't analysed the attack in detail, but wouldn't a straight 
> forward implementation of tickets have the same issue?
>
Yes, both approaches have the same issue and it's something that 
developers have to fix in general. Just like the fail to implement 
rotation, but at least a tech savvy admin can fix the rotation problem 
(e.g. via a cron job that restarts the server, although loosing 
decryption capability for the last used key). Only the developers are 
able to fix the virtual host confusion problem. I may look into this as 
well, but I'm not a dedicated C developer and this looks like a bigger 
problem.

Richard

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 13:03:35 -0700

> then this data is forfeit.

0RTT creates some interesting side effects.  I wouldn't have
characterized the data as forfeit, just that there are certain
considerations around the use of that first flight.  The keys used to
protect that data are different from the previous session, but they
are derived from those previous keys.  If we do some form of rekeying,
I expect that the basis for the resumption keying material won't
advance with any rekeying on the previous connection, so the lifetime
of that data and corresponding potential for loss or exposure is
greater.  But the extent to which an attacker might be able to
influence that data seems (at least intuitively) to be similar to the
data sent on the previous connection.

Resumption is less interesting in the 0RTT case than 0RTT without
resumption, where the initial flight of data isn't protected with the
server's new DH share.  That is, it's basically not forward secure.
That creates a reason to avoid sending or accepting that first flight.

If by forfeit you mean that there is a risk that the data is not
accepted by the server, that's a risk that I think is inherent in the
design.  In addition to the extra computation required to get 0RTT,
the client will have to buffer and re-send data in some cases, paying
the protection cost twice.  Otherwise the API changes, and I don't
think anyone wants that.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Wed, 3 Sep 2014 16:12:18 -0400

I apologize for lack of clarity. By “forfeit” I meant the following scenario, where a malicious server gets to read data sent to an honest server:

Connection 1:
C connects to malicious S 
S sends it a session ticket T which C stores.

Connection 2:
C wants to connect to honest S’.
C (incorrectly) uses the session ticket T to initiate resumption.
C optimistically encrypts sensitive data meant for S’ (e.g. cookies) under a key derived from (the master secret in) T.

Result:
S gets to read data that C was sending to S’.
Now, here, the fault is that C incorrectly cached T, so that it used T with S’ (whereas it should only be used with S).
This can easily happen if e.g. C’s client-side cache was indexed only an IP address and port.

The question is what is the identity of S that C should use when storing the ticket?
Can we give some recommendations?

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Sep 2014 20:20:05 +0000

On Wed, Sep 03, 2014 at 04:12:18PM -0400, Karthikeyan Bhargavan wrote:

> I apologize for lack of clarity. By "forfeit" I meant the following
> scenario, where a malicious server gets to read data sent to an
> honest server:
> 
> Connection 1:

The malicious server failed to be authenticated, so the session in
question (with which the ticket is associated) is unauthenticated.

With or without tickets, clients that resume unauthenticated sessions
are vulnerable to MiTM attacks.  There's nothing new here.

> Can we give some recommendations?

Don't resume unauthenticated sessions when trying to connect to a
service for which MiTM protection is wanted.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 15:33:47 -0500

Session tickets are a SINE QUA NON for future deployment.

PFS or not is up to the client (and server).  Remember, PFS is related
to the start of a session -- once you have a long-lived session, those
session keys could be stolen.  If you'll allow long-lived sessions
then you might as well allow session tickets.

(And if you want to add periodic PFS to long-lived sessions then you
need renego, no?)

Anyways, the right thing to do is to REQUIRE frequent session ticket
encryption rotation / short ticket lifetimes.  Look, session tickets
are an optimization, but a HUGE optimization at that.  It's necessary.

Nico
--

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Wed, 03 Sep 2014 22:37:48 +0200

+1

What would be an appropriate rotation cycle? 24 hours was already coined 
as a maximum and is also often stated in existing RFCs. I think that 
this is sufficient for most applications in regards to security. Of 
course more secure applications need to lower this to something like one 
hour or even less.

Richard

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Wed, 03 Sep 2014 22:41:22 +0200

> service for which MiTM protection is wanted.
Also storing by IP is pretty impossible with SNI. A cache has to include 
at least the FQDN for SNI.

Richard

---

From: Brian Sniffen <[email-masked]>
Date: Wed, 3 Sep 2014 16:49:14 -0400

> then you might as well allow session tickets.

Yes.

> are an optimization, but a HUGE optimization at that.  It's necessary.

What about making session tickets optional?  Clients or servers that
want PFS can then decline to accept or generate tickets.

-Brian

-- 
Brian Sniffen
"I reserve the right to evolve my views, and state that views I previously
 expressed may have been somehere along the spectrum from insufficiently
 nuanced through ill-informed to dead wrong."

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 13:54:10 -0700

> (And if you want to add periodic PFS to long-lived sessions then you

Not strictly, though it can get almost as complicated as
renegotiation.  But you don't have to change all the session
parameters, just the keys.

You can rekey with material that is derived from the old material and
prevent a future break from compromising session history back past the
rekeying point.  Or you can do a full or partial DH round without any
of the other renego baggage, which ensures that any break is limited
in access to the plaintext up to the DH in both directions.  The
latter is pretty complicated to get right when it comes to
synchronization.

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 15:54:55 -0500

> want PFS can then decline to accept or generate tickets.

They are optional.  The problem is that if you ever use a ticket once
and the server doesn't rotate its keys (or in the non-ticket
resumption case, flush its session cache) then the resumed connections
can be compromised later.  But... so what?  This is a problem for
*running* connections anyways.  If an attacker can compromise the
server's keys, it can probably compromise the server completely and
access running connections' session keys.

This is about trade-offs.  Proposals to get rid of sessions because of
concerns about PFS are just throwing the baby out with the bathwater;
such proposals are just not serious, and -if adopted- risk leading to
TLS 1.3's failure.

Nico
--

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 13:55:45 -0700

> want PFS can then decline to accept or generate tickets.

That's certainly already the case.  I'm fairly sure that we'd want to
keep that flexibility.  Certainly,  we have to allow for a ticket to
be invalid, so the server always has some discretion regarding whether
it honours a ticket.

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Wed, 03 Sep 2014 22:55:43 +0200

> want PFS can then decline to accept or generate tickets.
One can use session tickets together with PFS if rotation works. Of 
course one could simply deactivate them to add a layer of paranoia but 
one would have to disable session IDs as well because those could be 
compromised too.

Yes, looking at current implementations it's no paranoia layer. But the 
spec has to be sure to mark any non-rotating implementation as not RFC 
compliant by changing the rotation to MUST.

Also don't forget that tickets are already optional as it is now and I'd 
keep that dual system at least for TLS 1.3, as I said earlier. Otherwise 
nobody will adopt the new protocol because of lack of support on client 
and server side. But the next incarnation could drop one or the other.

Richard

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 15:56:18 -0500

> latter is pretty complicated to get right when it comes to

Nothing short of a new (possibly asynchronous) DH exchange will
prevent compromise of the past for connections still live at the time
of compromise.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 15:56:53 -0500

> be invalid, so the server always has some discretion regarding whether

This is *already* so today.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 16:04:14 -0500

On Wed, Sep 3, 2014 at 3:55 PM, Richard Fussenegger, BSc
<[email-masked]> wrote:
> nobody will adopt the new protocol because of lack of support on client and
> server side. But the next incarnation could drop one or the other.

Opaque session tickets of any length >> session IDs.  The server can
always use session IDs as the ticket.  IIRC this is Bodo's suggestion
for simplifying the protocol, and I agree.

There's really no need to say anything normative about server-side
resumption state vs. stateless resumption tickets -- it's an
implementation detail.  Losing the distinction on the wire should help
simplify things.

The key is to require resumption state -whether stored on the server
or on the client with an encrypted session ticket- to be
deleted/expired periodically.  For session tickets that's done by
rotating keys.  For server-side state it's done by expunging expired
sessions from the cache.  Either way the effect is the same.

Advice can be given about not storing these things on long-lived
storage (disk, ssd), just memory (e.g., tmpfs, ramdisk, whatever).

The where-is-the-state-stored distinction is not (should not be)
relevant to the protocol though.

Nico
--

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Wed, 03 Sep 2014 23:19:12 +0200

> relevant to the protocol though.
+1 seems like the best solution to me. Dissecting current implementation 
flaws isn't going to lead us anywhere. The developers simply have to fix 
them.

Richard

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 16:29:40 -0500

> flaws isn't going to lead us anywhere. The developers simply have to fix

+1 to that.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 3 Sep 2014 23:51:47 +0200

Nico Williams <[email-masked]>:

> sessions from the cache.  Either way the effect is the same.

Yes, I completely agree.

Bodo

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 15:23:19 -0700

> prevent compromise of the past for connections still live at the time

Maybe I'm not that smart, but I don't get that.  The scheme I
originally proposed had the master secret fed into the PRF in order to
generate a new master secret, with the old master secret ultimately
being discarded.  Once the old MS is gone, I don't see how an attacker
can recover plaintext prior to the rekeying that preceded the break.
That is, without a preimage attack on the hash function being used.

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 17:55:51 -0500

On Wed, Sep 3, 2014 at 5:23 PM, Martin Thomson <[email-masked]> wrote:
> [...]

No, it's I who brainfarted.

But even so, if you are paranoid enough you'll want to do a PFS DH
exchange often.  You might fear, for example, that the server doesn't
expunge old secrets often enough (considering the level of paranoia
we're showing as a group, this is not too farfetched).

Nico
--

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 17:30:45 -0700

> we're showing as a group, this is not too farfetched).

My conversations indicate that there is little willingness to incur
much complexity cost here.  New connections are relatively cheap after
all.  At least we know that new connections will have forward secrecy
(if you don't resume, that is).

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 19:34:35 -0500

> (if you don't resume, that is).

I agree.  But I was making a point.  The point is: there's nothing
wrong with session resumption as such.  Servers should rotate session
ticket encryption keys / expire / expunge cached sessions frequently
-- that should be enough.

Nico
--

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 04 Sep 2014 08:38:10 +0300

Hi Kathik,

You are implying that this attack only applies to session tickets and 
not to "regular" session caches, and I don't see why.

Even if the client only sends a session ID, not a full ticket, but it 
associates the same ID incorrectly with both S and S', it will encrypt 
the first flight to S' with a master key that's known to S. Am I missing 
anything?

I agree that TLS 1.3 should specify the scope of session identities, and 
thus, client-side behavior.

Thanks,
	Yaron

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 4 Sep 2014 09:48:37 +0200

Viktor Dukhovni <[email-masked]>:

> on a node,

This may work well enough for a single cluster, but in general it would be
better to make sure you distribute the new key *before* active use starts,
thus avoiding the need for global synchronization from cache-miss
situations.

Bodo

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Thu, 04 Sep 2014 10:17:15 +0200

On 9/4/2014 9:48 AM, Bodo Moeller wrote:
> Viktor Dukhovni <[email-masked] <mailto:[email-masked]>>:
>
> This may work well enough for a single cluster, but in general it 
> would be better to make sure you distribute the new key *before* 
> active use starts, thus avoiding the need for global synchronization 
> from cache-miss situations.
>
> Bodo
>
Twitter is doing that, they use a 20 minute timeout. But of course other 
tactics are also possible.

Richard

---

From: Hubert Kario <[email-masked]>
Date: Thu, 4 Sep 2014 06:57:29 -0400 (EDT)

----- Original Message -----

> Sent: Wednesday, September 3, 2014 9:28:39 PM

> > I haven't analysed the attack in detail, but wouldn't a straight forward
> > implementation of tickets have the same issue?
> 

> Yes, both approaches have the same issue and it's something that developers
> have to fix in general. Just like the fail to implement rotation, but at
> least a tech savvy admin can fix the rotation problem (e.g. via a cron job
> that restarts the server, although loosing decryption capability for the
> last used key). Only the developers are able to fix the virtual host
> confusion problem. I may look into this as well, but I'm not a dedicated C
> developer and this looks like a bigger problem.

actually, from what I read, current upstream Apache does save the ticket encryption key to disk, so it is persistent across restarts of service

---

From: Hubert Kario <[email-masked]>
Date: Thu, 4 Sep 2014 07:13:05 -0400 (EDT)

----- Original Message -----
> Sent: Wednesday, September 3, 2014 10:55:43 PM

I would go a step further: clients MUST NOT update the session cache TTL
upon receiving a new ticket from a resumed connection. So that the client
will force the server to perform full negotiation on a schedule established
by the ticket hint.

This will not help against compromised ticket encryption key, but will
help for PFS in general.

As for 24h limit on ticket lifetime: just a bit over 3.5% of https servers
advertise longer lived tickets, and basically all of those use a 28h
lifetime (less than 0.1% use longer than 28h).[1]

 1 - http://wp.me/p4BPwe-1M

---

From: Hubert Kario <[email-masked]>
Date: Thu, 4 Sep 2014 07:19:36 -0400 (EDT)

----- Original Message -----
> From: "Nico Williams" <[email-masked]>
> To: "Richard Fussenegger, BSc" <[email-masked]>
> Cc: [email-masked]
> Sent: Wednesday, September 3, 2014 11:04:14 PM

Session tickets do introduce parallel key schedule (even if implicitly),
for a protocol that aims to provide PFS that makes them relevant.

In the static key case, it will allow you to decrypt all of communication,
future and past. Compromising the session cache requires you to keep
it compromised to be able to decrypt future communication (and hope old
sessions didn't get garbage collected to decrypt past communication).

If the decision is to keep tickets, we need to be explicit about
their use, acceptable practices, etc. Otherwise they will be the weakest
link for the protocol.

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Thu, 04 Sep 2014 13:28:13 +0200

On 9/4/2014 12:57 PM, Hubert Kario wrote:
>     *To: *"Hubert Kario" <[email-masked]>
>     *Cc: [email-masked]
>     *Sent: *Wednesday, September 3, 2014 9:28:39 PM
>         I haven't analysed the attack in detail, but wouldn't a
>         straight forward implementation of tickets have the same issue?
>
>     rotation, but at least a tech savvy admin can fix the rotation
>     problem (e.g. via a cron job that restarts the server, although
>     loosing decryption capability for the last used key). Only the
>     developers are able to fix the virtual host confusion problem. I
>     may look into this as well, but I'm not a dedicated C developer
>     and this looks like a bigger problem.
>
>
>
> actually, from what I read, current upstream Apache does save the 
> ticket encryption key to disk, so it is persistent across restarts of 
> service
>
I was of course mainly referring to nginx. I have absolutely no 
experience with Apache httpd in the last two years. I guess the Apache 
devs wanted the ability to decrypt old tickets upon restart. Something 
the nginx devs haven't given any thought as it seems. The complete nginx 
ticket system is fully built upon the provided OpenSSL functionality. 
Although a file based ticket key system found it's way to the mainline 
version.

Richard

---

From: "Richard Fussenegger, BSc" <[email-masked]>
Date: Thu, 04 Sep 2014 13:42:13 +0200

>   1 - http://wp.me/p4BPwe-1M
Thanks for this info, much appreciated.

I'd say that we define a 24h maximum limit for the server ticket 
encryption key (48h [or in other words ttl * 2] in total for decrypt 
only keys). Additionally we should define that clients remember the 
creation time of a new ticket and will automatically drop it, if it's 
older than 48h (or of course TTL is reached). I think it's important to 
define such times in the specs because otherwise you'll get confused 
admins and devs who don't know how to handle it.

This will destroy the ability for long lived session tickets without 
PFS. But this isn't an issue if PFS is going to be mandatory for TLS 1.3 
(which has my full support). If someone really needs long lived tickets 
for a custom server-client-app nothing holds them back from not being 
RFC compliant and thus remove PFS entirely.

Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Sep 2014 09:58:03 -0400

On Tue, Sep 2, 2014 at 1:05 PM, Salz, Rich <[email-masked]> wrote:
> likely to be important in the near term  (say within two years after TLS 1.3
> is done).

Since the technical difference between the two is merely that a ticket
is large enough for the server to embed encrypted notes to self,
tickets are obviously the way to go.

I don't see the issue with PFS and tickets. Tickets are a good way to
implement PFS, you just need to be careful about how you separate your
credentials.

My view is that for TLS next generation, what we should do is to
separate out key negotiation, forward secrecy and applying keys to
transport.

The Key Negotiation module can then be applied at any layer that we
need it - Packet, Transport or Application.

The output of the Key Negotiation mechanism is a set of cryptographic
parameters (algorithms, shared key(s)) and an opaque session
identifier whose internal structure does not need to be understood by
any party other than the one that generated it.

If we have that as a separate module in our toolbox, the application
to DNS, TCP/IP, HTTP etc. becomes very straightforward. Instead of
IPSEC being a whole different stack it is just a different application
of TLS.

Layering DNS security on top of TLS or DTLS makes no sense. You start
off with a huge stack and make it larger. The larger the stack the
larger the number of security holes are going to arise out of
unexpected interactions.

To achieve forward secrecy we simply have two levels of tickets. The
top level negotiation returns a ticket and session ID that is then
used to encrypt/authenticate parameters for a PFS exchange.

Turning everything into tickets is astonishingly powerful. I have been
using that a while and I encourage people to do the same. A lot of
problems that seem hard, like encrypting SNI become a lot easier.

It is much better for IETF as well, Kerberos and PKI are no longer
polar opposites. Good forward planning for quantum computing if it
ever arrives.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 4 Sep 2014 07:26:10 -0700

> implement PFS, you just need to be careful about how you separate your

Can you explain that some more?  If the credential protecting the
ticket is compromised, or if the ticket encryption is cracked, then
the session key is available to a MITM. That's very different from
DHE, where the session key is derived from materials that never cross
the wire.

-- 
Colm

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Sep 2014 10:42:20 -0400

Meta point: Quite a few people need to STFU about what people's lives
depend on. IF you have direct experience of working with dissident
groups then sure, speak up. There are people who do in fact specialize
in that area who attend IETF. If you don't know who they are then you
almost certainly don't understand the real requirements.

As a general rule, if we have a cluster of computers spread over
international borders and any part of that cluster is compromised by
an attacker then that attacker will always be able to perform a
downgrade attack on any party they can MITM simply by directing
traffic to the part of that cluster they control.

+1

The argument that some people can't write code is never a good reason
to cripple implementations.

We don't have to do TLS 1.3. We could do TLS 2.0 instead. In fact most
of the conversations suggests to me that is what we are already
planning but not admitting the fact.

> (And if you want to add periodic PFS to long-lived sessions then you

The way I see it, once we have a secure connection to a server we
should never speak to that server en-clair ever again for any reason.

> are an optimization, but a HUGE optimization at that.  It's necessary.

More than an optimization, they let us apply multiple layers of
security which is essential if we are going to properly solve problems
like leaking SNI data.

One of the things that makes this discussion hard to follow is that a
lot of people are conflating characteristics of particular
implementations with architectural choices. We do not remove features
from IETF protocols because some people don't like some
implementations.

We have a number of security requirements and we have tools for
achieving those requirements that come with costs.

Checking cert chains has a high cost
Performing static key negotiation has a cost
Performing ephemeral key negotiation has a cost

The security requirements for session keys are essentially that people
want to limit the vulnerability window in various ways, these include
time and number of machines affected and data that is disclosed.

Just because the SSL 1.x spec tells us that a ticket is bound to data
encryption and authentication keys does not mean we have to stick with
that architecture for TLS-TNG.

The biggest cost in the TLS key negotiation process is that
certificate chain validation thing. And that is always going to be the
case because certificates are always going to have the biggest keys
and there are multiple certs in a chain (minimum of one KSC these days
so two signatures to validate).

So using a ticket to validate an ephemeral key exchange over some fast
ECC curve would make a lot of sense.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Sep 2014 11:00:43 -0400

> DHE, where the session key is derived from materials that never cross

We are talking about TLS-TNG so forget all the existing TLS baggage,
in particular the notion that Tickets are only bound to data keys.

The scheme I am describing is currently implemented as a Web Service
security layer but it can be applied in TLS just as well.

I have a key exchange service that performs a certificate chain
validation, algorithm negotiation and returns an opaque ticket and a
set of crypto parameters (algorithm, security policy, secret keys k_a,
k_e).

So one option is that we just use the keys to encrypt and authenticate
the data channel.

Another option is that we use the keys bound to that ticket to
authenticate (and why not also encrypt) an ephemeral key exchange:

Client->Server = X_c, MAC (X_c, k_a)
Server->Client = X_s, MAC (X_s, k_a)

Now derive new keys for use in this session:

k_tm = H (DH_ECC (X_c, X_s), k_e)
k_te = F1 (k_tm)
k_ta= F2 (k_tm)

[OK I am simplifying as I usually make the keys different in different
directions.]

Note here that the PFS key is a mix in, not a replacement. I notice a
lot of designs where the output of the PFS exchange replaces the
negotiation parameters completely so if there is a weak PFS scheme
(e.g. a weak RNG) then the channel is compromised.

This approach is a bit slower than using secret keys bound to a ticket
directly on the channel. But it is a heck of a lot faster than
performing a full cert chain validation and key exchange.

We can also use a faster algorithm. If we are using AES 128 then there
is obviously no particular need to use a curve larger than 256 bits,
so we might use Curve 25519 for the PFS exchange even though the
certificates are using 512 bit curves. But with the mix in approach we
might still use Curve 25519 for the PFS mixin even if we were using
AES 256.

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 Sep 2014 10:32:15 -0500

> to cripple implementations.

Indeed, and if we take it to the limit it's an argument for giving up
(and certainly for abandoning TLS).

---

From: Thor Lancelot Simon <[email-masked]>
Date: Thu, 04 Sep 2014 04:10:30 -0000

On Wed, Sep 03, 2014 at 04:02:58PM +0200, Bodo Moeller wrote:
> cost).

Indeed.  Here again, we have the opportunity to make a doctrinaire mistake
that trades away actual security in practice (and workload for the likely
adversary) to obtain some theoretical security street cred.

You know, like forcing everyone to 2048 bit RSA keys (and impeding the
universal of HTTPS everywhere, particularly for sites behind computational
choke points such as load balancers) when 1280 bits or so would have been
plenty.

Anything that forces live state synchronization amongst large distributed
systems (such as reverting from tickets to a shared session cache) or more
full RSA exchanges makes the cost of TLS measurable, and sometimes prohibitive,
for some applications where its _only_ real rationale is herd immunity from
snooping -- where the only benefit's collective and social and if crypto has
measurable costs the entity running the server will just skip the crypto.

Let's not make that mistake again.

Thor