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

[David Benjamin <[e-mail]>]

On Thu, Jan 28, 2016 at 2:09 PM Ilari Liusvaara <[e-mail]>
wrote:

> On Thu, Jan 28, 2016 at 05:36:22PM +0000, David Benjamin wrote:
> > On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara <
> [e-mail]>
> > wrote:
> >
> > > On Wed, Jan 27, 2016 at 07:28:47PM +0000, David Benjamin wrote:
> > > > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson <
> > > [e-mail]>
> > >
> > > I don't think the two situations have the same problems:
> > > - "Server 0-RTT" has _recipient_ identity change.
> > > - "Dynamic reauth" has _sender_ identity change.
> > >
> > > You have more concrete examples of things going wrong with "server
> > > 0-RTT"? Because I have major problems coming up with troublesome
> > > cases.
> >
> >
> > The client also has some 0-RTT data which, in the server 0-RTT case, the
> > server reports was accepted and processed. That all is associated with
> the
> > first identity rather than the second. So I believe we have sender
> identity
> > change in both cases.
>
> The 0-RTT being sent under different identity than the application data
> does involve sending identity change, but what does it have to do with
> "server 0-RTT"? The client could do that (and run into trouble with
> badly designed protocols) without "server 0-RTT".
>

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?

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).

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.

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.

Since there is zero benefit to a using this handshake flow over already
existing alternative (this handshake flow is not an optimization), I don't
see how it can be worth this (or any) complexity.

David

[*] 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.