Re: [TLS] Security review of TLS1.3 0-RTT

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

On Wed, May 3, 2017 at 3:04 PM, Viktor Dukhovni <[e-mail]>
wrote:

>
> On May 3, 2017, at 4:27 PM, Colm MacCárthaigh <[e-mail]> wrote:
>
> > On Wed, May 3, 2017 at 1:20 PM, Viktor Dukhovni <[e-mail]>
> wrote:
> >
> >> The kind of application whose security requirements preclude use of RFC
> 5077
> >> session tickets can and should likely also avoid both 0-RTT and session
> >> resumption entirely.
> >
> > I don't agree with this. Why should users of mobile devices, to pick one
> example,
> > have to choose between speed and the extra risk of data disclosure for
> their requests
> > and passwords?
>
> Their security requirements don't preclude use of RFC 5077 session tickets,
> they've been using them all along, and will continue to do so for the
> majority
> of destinations that will take quite some time to upgrade to TLS 1.3.
>
> As you might recall, I don't agree that STEKs are fundamentally less secure
> than remote session caches, I rather suspect that sensibly implemented
> STEKs
> are safer.
>

I'm not sure how any of that is relevant. Mobile users, like everyone else,
appreciate speed; they'll want to use 0-RTT. I'm sure they also appreciate
their data being less at risk, so forward secrecy is good for them too. I'm
saying they should be able to get both. Again, you can combine the security
properties of a STEK with a cache if you want, by encrypting the cache
entries the same way you would use a STEK.


>
> [ I do concede that the current OpenSSL implementation leaves too much of
> the
> responsibility of doing STEKs right to applications, and I will endeavour
> to
> fix that.  It is not especially difficult to implement a default-on key
> rotation
> mechanism. ]
>

Just an aside related to that; it can be useful to fuzz ticket lifetimes a
bit so all of the tickets from a STEK don't expire at exactly the same
time. That can lead to a lot of painful renegotiations happening at once.

>> Second-guessing the server's design by looking at ticket sizes seems
> rather
> >> contrived.
> >
> > It's not a second guess. If the ticket size is smaller than the RPSK,
> then it
> > provably can not have been self-encrypted. But I agree that it says
> nothing
> > about the server-side security. They might be posting the keys to
> twitter.
>
> As you yourself concede it is not the size that matters. It is a very
> marginal indication of the security of the remote session. The server may
> wish to decorate

the session id with additional data (say which data-centre issued the
> session)
> and fail your test, and yet be doing the type of session caching you're
> asking
> for.  The client should either trust the server to cache sessions
> correctly (this
> would be the default client behaviour in most cases), or it can choose to
> forgo
> session re-use.
>

True.


> Feel free to malign bad implementations of STEKs, but the basic mechanism
> is
> sound.
>

"sound" goes too far. Pervasive forward secrecy is one of the central
security goals of modern cryptography, some schemes go so far as to bake in
very frequent key agreement and ratcheting. STEKs aren't compatible with
this goal. They may be acceptable operationally today, but I think they
must be borrowed time if the central goal is meaningful.

-- 
Colm