On Fri, Mar 25, 2016 at 12:24 PM, Eric Rescorla <e...@rtfm.com> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
