Re: [TLS] Closing on 0-RTT

PR up:
https://github.com/tlswg/tls13-spec/pull/1034

On Fri, Jun 23, 2017 at 9:21 AM, Joseph Salowey <joe@salowey.net> wrote:

> Hi Ekr,
>
> Discussion on this topic is dying down, can you post a PR so we can see
> the proposed text.  There is still some discussion on the API thread so
> there may be some additional modifications coming in that area.
>
>
> On Wed, Jun 14, 2017 at 10:45 AM, Ilari Liusvaara <
> ilariliusvaara@welho.com> wrote:
>
>> On Tue, Jun 13, 2017 at 03:24:24PM -0700, Bill Cox wrote:
>> > On Tue, Jun 13, 2017 at 1:51 PM, Ilari Liusvaara <
>> ilariliusvaara@welho.com>
>> > wrote:
>> >
>> > > >   - Note that 0-RTT exporters are not safe for authentication on
>> servers
>> > > > that do not enforce single-use tickets, or for clients that do not
>> > > > recompute authentication signatures on retransmission of early data.
>> > >
>> > > "Single-use tickets" imply global anti-replay.
>> > >
>> >
>> > I assumed "gobal anti-replay" meant there would be a globally
>> synchronized
>> > cache of valid single-use tickets.  It sounds like you mean "global
>> > anti-replay" includes schemes using orbit/metro/server bound tickets,
>> since
>> > they can support single-use tickets.  In that case, I agree with you,
>> but I
>> > think the phrase "single-use tickets" may be less confusing.  Maybe just
>> > say "anti-replay" instead of "global anti-replay"?
>>
>> IMO, "anti-replay" also includes per-server anti-replay, which archives
>> "at most N replays" in global scale.
>>
>> Of course, the ticket scope of server can be wider than the 0-RTT scope
>> (the server accepts tickets but rejects 0-RTT from any ticket in
>> between).
>>
>> > And the latter part is way too obscure. I have no idea how it is
>> > > trying to fix ClientHello replay resulting the same exporter
>> > > output.
>> > >
>> >
>> > I don't know what you mean by "resulting the same exporter output."
>> Auth
>> > signatures in a 1-RTT fallback need to be recomputed using the 1-RTT
>> > exporter to avoid having the same signature accepted twice.  Maybe this
>> is
>> > too specific and should be left out.
>>
>> If you replay ClientHello and it gets accepted twice, including to
>> different servers, both connections have the same 0-RTT exporter values.
>>
>> The 1-RTT exporter values will not be the same, but this is not helpful
>> for 0-RTT data, or for that matter any 1-RTT data unless exporters are
>> switched mid-stream.
>>
>> > > Even this is only partially true.  Anti-replay can be built above the
>> TLS
>> > > > layer.  I'm considering doing token-binding replay defense in the
>> > > > authentication backend, to help ensure the token-binding guarantee:
>> that
>> > > > auth tokens taken from one device cannot be used from another device
>> > > > without continued access to the first device's signing oracle.
>> > > > Unfortunately, 0-RTT master resumption secrets are a new kind of
>> auth
>> > > > bearer token, and the token binding spec does not cover them.
>> > >
>> > > Doing stuff like this gets more and more complicated and fragile as
>> > > one moves up the layer stack.
>> > >
>> >
>> > It depends on the task.  Moving channel ID from the TLS layer to token
>> > binding in the HTTP layer should simplify the TLS state machine enough
>> to
>> > justify the change.
>>
>> Implementing such thing without some TLS support at application layer is
>> just crazy.
>>
>> IMO, the only reason token binding concerns itself at all with TLS is
>> that "0.5 RTT" (a TLS 1.3 feature) and HTTP/2 was not available when
>> token binding was started. Those (together with exporters) would have
>> enabled token binding in HTTPS without having to mess with TLS.
>>
>> (The messing with TLS in token binding seems to be solely about saving
>> round-trips!)
>>
>> > Anti-replay in the TLS layer would be good for 0-RTT
>> > token binding, but the cost and complexity of running the whole
>> user-facing
>> > fleet of servers with anti-replay caches is huge, many times higher than
>> > the cost of token-binding anti-replay in the backend.  Also, the
>> > authentication backend is where bound tokens are currently verified, so
>> > putting the anti-replay there seems like the appropriate layer.
>>
>> That greatly depends on the implementation and deployment. That's why it
>> is more fragile.
>>
>> E.g. run more than one authentication backend for 0-RTT scope, and
>> your application layer anti-replay breaks. And I'm not convinced the
>> scale of anti-replay cache would be much smaller at application layer, in
>> fact, it could be even biger.
>>
>> > I'm still not sure this scheme is worth implementing, but without it, I
>> do
>> > not think we can support client certificates or token binding over
>> 0-RTT.
>> > It doesn't really matter for the TLS 1.3 spec.  I'm just pointing out
>> that
>> > the statement "0-RTT auth is insecure without anti-replay defense" is
>> not
>> > 100% accurate.  There are other ways to improve the security.
>>
>> Well, client certificates are currently forbidden for connections with
>> 0-RTT data (indirectly, but it is still forbidden). It could become
>> possible
>> in the future.
>>
>>
>>
>>
>>
>> -Ilari
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>