Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

[Bill Cox <[e-mail]>]

On Sun, Mar 13, 2016 at 2:23 PM, Scott Schmit <[e-mail]> wrote:

>
> So why are we adding a protocol optimization known from the start to be
> insecure (or less secure than you'd expect from using a PFS cipher
> suite)?
>

If you require PFS with resolution on the order of seconds to minutes
rather than hours to days, you probably do not want to use tickets either.
The ticket decryption key rotation schedule limits PFS.  0-RTT resumes do
not make this worse.

What percentage of servers that have a perceived need for 0-RTT will be
> able to securely use and benefit from this feature as their
> infrastructure is actually implemented?
>

Well, Google already sees a significant fraction.  Going back to 1-RTT
would be a significant downgrade.

If almost everyone should turn it off, why are we including it?
>

Almost every small site on the Internet should turn it off, but the large
sites that want to enable it could make up a large fraction of all traffic.

Most server admins won't be reading the TLSv1.3 spec.  They're going to
> see "shiny feature added specifically in this version that makes it
> faster!" with *maybe* a warning that there are risks, which they'll
> dismiss because "if it was so insecure, they wouldn't have included it
> in the protocol in the first place."  Unless 0-RTT can be fixed, it
> looks like an attractive nuisance.
>

I agree.  Instead of dropping 0-RTT, I think we should make it easy for
admins to learn about what is involved in using 0-RTT in ways we believe
are secure.  The two modes I am aware of that are potentially as secure as
TLS 1.2 session resumption are:

- Do 0-RTT session resumption using a session cache, using the ticket as
the session ID.  This should have the same security as TLS 1.2 resume,
right?
- At the HTTP app layer, make all requests that change state transaction
based with unique transaction numbers, so replay attacks fail to change
server state.  Done successfully, this should be more secure than TLS 1.2
resumption, shouldn't it?

Are we aware of other secure ways to do 0-RTT?

Bill