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

On Sun, Mar 13, 2016 at 9:29 PM, Bill Cox <waywardgeek@google.com> wrote:

> On Sun, Mar 13, 2016 at 6:26 PM, Harlan Lieberman-Berg <
> hlieberman@setec.io> wrote:
>
>> Bill Cox <waywardgeek@google.com> writes:
>>
>> More generally, I strongly believe that TLS 1.3 should not
>> provide options which we think should be restricted to "admins who know
>> what they're doing".  These end up hurting us down the line (cf EXPORT
>> cipher suites.)
>>
>> I think we should ship the parts of 0-RTT that we believe are
>> intrinsically safe for (the vast majority) of the internet to enable and
>> use on day 1.
>>
>
> This is just my opinion, not Google's.  Here is a dumb idea I just had:
>
> The current 0-RTT modes described in TLS 1.3 are clearly only for admins
> who really know what they are doing.  If the current 0-RTT modes are deemed
> to dangerous, then how about going back to session IDs, and doing 0-RTT
> resumption from the session cache?
>

Isn't this more or less what we have been calling PSK-resumption? Can you
explain
the difference?
-Ekr

> This is not only fairly simple given the existing code base, but it fits
> well with my personal bias towards supporting strong client authentication,
> which basically got thrown under the bus in the current 0-RTT scheme.
> Frankly, my current job (working on token binding) is a lot less appealing
> in a world where servers cannot do proofs-of-possession with clients.  With
> 0-RTT cached session resumption, the TLS sequence numbers remain intact,
> and we inherit the security parameters from the original connection.  The
> new replay attacks go away, as do most of the "new and exciting" ways to
> PWN TLS 1.3 0-RTT.
>
> The new tickets could still be supported to enable advanced operators the
> flexibility they need to implement stateless 0-RTT, but from the TLS point
> of view, it would just be a 0-RTT resume using a session ID, with
> additional ticket data.  If the admins at a particular company want to
> stuff all the session state into the ticket and accept the security
> consequences of stateless 0-RTT resumption, I think they should have the
> flexibility to do that.  I _think_ the new tickets give them what they need.
>
> This would enable the standard 0-RTT resume to be as secure as keeping the
> connection alive the whole time.  I think it would stop this "race to the
> bottom" problem people are worried about on this thread.
>
> So... how dumb is this idea?
>
> Bill
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>