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

[David Benjamin]

On Thu, Jan 28, 2016 at 2:09 PM Ilari Liusvaara 
wrote:

> On Thu, Jan 28, 2016 at 05:36:22PM +, David Benjamin wrote:
> > On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Wed, Jan 27, 2016 at 07:28:47PM +, David Benjamin wrote:
> > > > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson <
> > > martin.thom...@gmail.com>
> > >
> > > 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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Fri, Jan 29, 2016 at 07:55:53PM +, David Benjamin wrote:
> On Thu, Jan 28, 2016 at 2:09 PM Ilari Liusvaara 
> 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Thu, Jan 28, 2016 at 05:36:22PM +, David Benjamin wrote:
> On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara 
> wrote:
> 
> > On Wed, Jan 27, 2016 at 07:28:47PM +, David Benjamin wrote:
> > > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson <
> > martin.thom...@gmail.com>
> >
> > 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".


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[David Benjamin]

On Wed, Jan 27, 2016 at 2:44 PM Ilari Liusvaara 
wrote:

> On Wed, Jan 27, 2016 at 07:28:47PM +, David Benjamin wrote:
> > On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson <
> martin.thom...@gmail.com>
> > wrote:
> > >
> > > I get your point, but I don't see that as a simplification.  In my
> > > mind, post-handshake client authentication doesn't happen.  Or, I
> > > don't see it being commonplace.
> >
> > But the only cases where this flow is useful (server sends non-zero
> > unauthenticated bytes at t=0.5 before the authenticated bytes at t=1.5)
> has
> > all the same pitfalls of mid-stream auth (specifically that the stream's
> > authentication switches partway through), so I don't see what avoiding
> > mid-stream auth is supposed to gain.
>
> 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.

David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Jan 27, 2016 9:45 AM, "Martin Thomson"  wrote:
>
> On 28 January 2016 at 02:09, Watson Ladd  wrote:
> > All 0-RTT data is replayable, but I don't see what replaying a
> > authenticated replayable connection gets you.
>
> If the 0-RTT flight includes actions (especially non-idempotent ones)
> that only apply if the authentication is correct, then you get
> authenticated replayable actions.
>
> e.g., "please pay Watson $10, my certificate authenticates this request"

We already know non-idempotent actions cannot be put into 0 RTT.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

> e.g., "please pay Watson $10, my certificate authenticates this request"

We already know non-idempotent actions cannot be put into 0 RTT.

s/cannot/should not/  This might help prevent problems.  Might.  I don't know 
if it's worth it.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On 28 January 2016 at 02:09, Watson Ladd  wrote:
> All 0-RTT data is replayable, but I don't see what replaying a
> authenticated replayable connection gets you.

If the 0-RTT flight includes actions (especially non-idempotent ones)
that only apply if the authentication is correct, then you get
authenticated replayable actions.

e.g., "please pay Watson $10, my certificate authenticates this request"

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Andrei Popov]

Ø  The CertificateVerify message is still listed as an option in the 0-RTT 
client's first flight at t = 0.  Is this a mistake?  I have not heard that 
anyone wants to do this, as there is no possibility of a traditional 
proof-of-possession in the first flight.
I agree with this: client auth in 0-RTT is replayable, unless the server takes 
extraordinary steps (QUIC-like strike registers, database of client nonces, 
etc.) No plans to implement, at least for now.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Bill Cox
Sent: Wednesday, January 27, 2016 6:13 AM
To: Martin Thomson <martin.thom...@gmail.com>
Cc: tls@ietf.org
Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished

On Tue, Jan 26, 2016 at 7:32 PM, Martin Thomson 
<martin.thom...@gmail.com<mailto:martin.thom...@gmail.com>> wrote:

I get your point, but I don't see that as a simplification.  In my
mind, post-handshake client authentication doesn't happen.  Or, I
don't see it being commonplace.

The use case described to me was for a higher level of authentication, such as 
when accessing a source-code repository at work, similar to proving that you 
still possess a security key now and then.  I am not sure why FIDO does not fit 
this use case better, though.  I have a feeling this is a legacy use case of 
client certificates, and is being included to avoid having to transition a lot 
of legacy client-cert based systems to FIDO.

The CertificateVerify message is still listed as an option in the 0-RTT 
client's first flight at t = 0.  Is this a mistake?  I have not heard that 
anyone wants to do this, as there is no possibility of a traditional 
proof-of-possession in the first flight.  However, with QUIC-like strike 
registers, a reasonably accurate timestamp in the handshake, and a secure clock 
on the client, you can approximate a proof-of-possession.  This seems like a 
lot of trouble for a first-flight CertificateVerify, but if someone wants to do 
this, it could stay in the spec.  If CertficateVerify is to remain in the 0-RTT 
first flight, there needs to be some way to provide a timestamp in the 
handshake hash.  Is there a way to do this now?  The TLS 1.2 timestamp in the 
client random seems to have been removed.

Bill
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 27 Jan 2016, at 8:38 PM, Andrei Popov  wrote:
> 
> Ø  The CertificateVerify message is still listed as an option in the 0-RTT 
> client's first flight at t = 0.  Is this a mistake?  I have not heard that 
> anyone wants to do this, as there is no possibility of a traditional 
> proof-of-possession in the first flight.
> I agree with this: client auth in 0-RTT is replayable, unless the server 
> takes extraordinary steps (QUIC-like strike registers, database of client 
> nonces, etc.) No plans to implement, at least for now.

To clarify: by “no plans to implement”, do you mean no plans to implement 
0-RTT, or no plans to implement client authentication with 0-RTT?

Thanks

Yoav


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[David Benjamin]

On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson 
wrote:

> On 27 January 2016 at 14:11, David Benjamin  wrote:
> > Why do you say it's an optimization? They're exactly the same except the
> > simplified one reduces to normal 0-RTT + mid-stream CertificateRequest (a
> > combination that's possible with or without my restriction) and the
> other is
> > a brand new handshake flow to worry about.
>
> I get your point, but I don't see that as a simplification.  In my
> mind, post-handshake client authentication doesn't happen.  Or, I
> don't see it being commonplace.
>

I certainly hope it doesn't become commonplace either! :-)

But the only cases where this flow is useful (server sends non-zero
unauthenticated bytes at t=0.5 before the authenticated bytes at t=1.5) has
all the same pitfalls of mid-stream auth (specifically that the stream's
authentication switches partway through), so I don't see what avoiding
mid-stream auth is supposed to gain.

David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Andrei Popov]

No plans to implement client auth in 0-th RTT.

Cheers,

Andrei

From: Yoav Nir [mailto:ynir.i...@gmail.com]
Sent: Wednesday, January 27, 2016 11:10 AM
To: Andrei Popov <andrei.po...@microsoft.com>
Cc: Bill Cox <waywardg...@google.com>; Martin Thomson 
<martin.thom...@gmail.com>; tls@ietf.org
Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished


On 27 Jan 2016, at 8:38 PM, Andrei Popov 
<andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>> wrote:

>  The CertificateVerify message is still listed as an option in the 0-RTT 
> client's first flight at t = 0.  Is this a mistake?  I have not heard that 
> anyone wants to do this, as there is no possibility of a traditional 
> proof-of-possession in the first flight.
I agree with this: client auth in 0-RTT is replayable, unless the server takes 
extraordinary steps (QUIC-like strike registers, database of client nonces, 
etc.) No plans to implement, at least for now.

To clarify: by “no plans to implement”, do you mean no plans to implement 
0-RTT, or no plans to implement client authentication with 0-RTT?

Thanks

Yoav


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Wed, Jan 27, 2016 at 07:28:47PM +, David Benjamin wrote:
> On Tue, Jan 26, 2016 at 10:32 PM Martin Thomson 
> wrote:
> >
> > I get your point, but I don't see that as a simplification.  In my
> > mind, post-handshake client authentication doesn't happen.  Or, I
> > don't see it being commonplace.
> 
> But the only cases where this flow is useful (server sends non-zero
> unauthenticated bytes at t=0.5 before the authenticated bytes at t=1.5) has
> all the same pitfalls of mid-stream auth (specifically that the stream's
> authentication switches partway through), so I don't see what avoiding
> mid-stream auth is supposed to gain.

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.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Watson Ladd]

On Wed, Jan 27, 2016 at 6:12 AM, Bill Cox  wrote:
> On Tue, Jan 26, 2016 at 7:32 PM, Martin Thomson 
> wrote:
>>
>>
>> I get your point, but I don't see that as a simplification.  In my
>> mind, post-handshake client authentication doesn't happen.  Or, I
>> don't see it being commonplace.
>
>
> The use case described to me was for a higher level of authentication, such
> as when accessing a source-code repository at work, similar to proving that
> you still possess a security key now and then.  I am not sure why FIDO does
> not fit this use case better, though.  I have a feeling this is a legacy use
> case of client certificates, and is being included to avoid having to
> transition a lot of legacy client-cert based systems to FIDO.

All certificate based authentication over HTTP is currently done by
renegotiation, when the client chooses to access a protected resource
a Renegotiation Request is sent, leading to the client certificate
being provided in the second handshake. It's true that FIDO will be a
better solution (currently unfinished), but when changing TLS stacks
to work with TLS 1.3 we need to support this case, without requiring
changes to application code below this.

>
> The CertificateVerify message is still listed as an option in the 0-RTT
> client's first flight at t = 0.  Is this a mistake?  I have not heard that
> anyone wants to do this, as there is no possibility of a traditional
> proof-of-possession in the first flight.  However, with QUIC-like strike
> registers, a reasonably accurate timestamp in the handshake, and a secure
> clock on the client, you can approximate a proof-of-possession.  This seems
> like a lot of trouble for a first-flight CertificateVerify, but if someone
> wants to do this, it could stay in the spec.  If CertficateVerify is to
> remain in the 0-RTT first flight, there needs to be some way to provide a
> timestamp in the handshake hash.  Is there a way to do this now?  The TLS
> 1.2 timestamp in the client random seems to have been removed.

All 0-RTT data is replayable, but I don't see what replaying a
authenticated replayable connection gets you.

>
> Bill
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

This is in part why I created: https://github.com/tlswg/tls13-spec/pull/402

My understanding is that the server is able to send any data that does
not depend on client authentication at t=0.5 and any data that depends
on client authentication at either t=0.5 if it successfully consumes
the client authentication in the 0-RTT flight, or t=1.5 failing that.

On 27 January 2016 at 11:46, David Benjamin  wrote:
> It's possible I'm reading the draft wrong, so this thread may be a very
> short one.
>
> (t here is in units of RTT, so t=0 is when the client sends ClientHello and
> t=0.5 is when the server receives ClientHello and sends ServerHello, t=1 is
> when the client receives ServerHello, etc.)
>
> Looking at the Zero-RTT exchange here:
> https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2
>
> Is the intention that the client, even in the successful 0-RTT case, send
> two Finished messages (one at t=0 and one at t=1) and that the server not
> send application data until receiving the second of these at t=1.5? If so,
> does this not defeat the purpose of 0-RTT? Although the client now eagerly
> sends at t=0, it will not see the response until t=2, which is no better
> than the resumption case (in TLS 1.2 or 1.3) where the client doesn't send
> until t=1.
>
> David
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On 27 January 2016 at 12:58, David Benjamin  wrote:
> If the server needs to send a CertificateRequest (i.e. the client
> mispredicted the 0-RTT Certificate/CertificateVerify) but otherwise has a
> 0-RTT hit, have it reject 0-RTT altogether. The 0-RTT is already all but
> useless because the first authenticated byte of the response is delayed to
> t=1.5. We should just say that 0-RTT accept + CertificateRequest is
> forbidden.


I believe that is a choice that an implementation could make, rather
than have a stipulation in a spec.  You are free to simplify in your
implementation as much as you like.

Refusing 0-RTT and delaying the "completion" of a handshake if you
find that you need to send a CertificateRequest (either because you
don't have 0-RTT client auth or the 0-RTT client auth is
bad/indecipherable) is a pretty good choice.  I might even be happy to
recommend it to others.  But do you have a security property you are
looking to preserve?  Because otherwise, I think that I might take the
optimization.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls