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

[Colm MacCárthaigh <[e-mail]>]

On Fri, Mar 25, 2016 at 12:24 PM, Eric Rescorla <[e-mail]> wrote:

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

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

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

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

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

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


-- 
Colm