Re: [TLS] 0-RTT, server Application Data, and client Finished

[Ilari Liusvaara <[e-mail]>]

On Fri, Jan 29, 2016 at 07:55:53PM +0000, David Benjamin wrote:
> On Thu, Jan 28, 2016 at 2:09 PM Ilari Liusvaara <[e-mail]>
> wrote:
> 
> Perhaps I misunderstood you. I read "dynamic reauth" in your message above
> as the post-handshake auth mechanism. You said that "server 0-RTT" has
> recipient identity change and "dynamic reauth" has sender identity change.
> My claim is that "server 0-RTT" also has sender identity change, since that
> seemed to be the question you were asking. Did you mean something else?

No, it doesn't: The server auth block comes before the data sent, and this
block authenticates the sender (which is the server).
 
> Yes, by forbidding CertificateRequest on 0-RTT hit, we are not removing
> anything post-handshake auth can't do. That's largely my point. It is
> identical in both how it works in good or bad) and how early each message
> arrives (see https://www.ietf.org/mail-archive/web/tls/current/msg19159.html
> for comparison).

Also, there are some subtle attacks on TLS that only fail on client
Finished, so client auth block is needed.

> I hope the more reasonable protocols without legacy burdens will declare
> that post-handshake auth is forbidden and only allow initial-handshake
> client auth or none at all, as SPDY and HTTP/2[*] did to renego in TLS 1.2.
> Yet it's not obvious CertificateRequest on a 0-RTT hit is equivalent to
> post-handshake auth and should be allowed or forbidden together.

That actually also depends on what kind of data is sent in 0-RTT. Some
protocols might be unsafe in general case, but have restricted subset
that is safe in 0-RTT.

E.g. protocol banners (e.g. HTTP/2 prelude/SETTINGS) are in general safe.
HTTP/2 also has other stuff that could be sent (e.g. preflights or
any requests with user privilege).

Or protocol could say that anything in 0-RTT is permanently locked
to authority it was sent with (including possibly anonymous authority).
IIRC, 0-RTT data is explicitly distinct from normal data.

> Also, although servers can choose never to do this, clients that implement
> post-handshake auth (like HTTP apparently) can't. This figures into the
> client API the TLS stack exposes. Despite being in the handshake, this flow
> should be exposed via post-handshake auth's API. This is weird, but
> handshake-negotiated properties otherwise have nice assumptions like being
> constant throughout the connection, should the client's stream depend on
> it. Consider ALPN. If a server wishes to pick a different ALPN value from
> the 0-RTT-predicted one, it must reject 0-RTT because that data's wrong
> anyway. I think the same should be true of in-handshake client auth.

IIRC, there is no indication of assumed ALPN for 0-RTT...

Also, 0-RTT data is also separate on client side. So in-handshake
1RTT auth is quite different for client than post-handshake auth.

Also, I think there should be a way for client to request Certificate-
Request, even without valid configuration. This is needed for M2M
applications (and some interactive protocols as well).

> [*] Sadly, HTTP's legacy burdens caught up to us. Although I see
> draft-thomson-http2-client-certs-01 has picked up again, so maybe HTTP/2
> won't use post-handshake auth? Doesn't matter; new multiplexed protocol
> without such legacy would best forbid post-handshake auth.

Well, considering that they have no choice with TLS 1.2, I presume
they will also go that way with TLS 1.3.


-Ilari