Re: [TLS] In-handshake CertificateRequest and 0-RTT

2016-05-12 Thread Andrei Popov 
Ø  Is the client still authenticated as the previous one too, or just the new 
one?
I think the client that has authenticated as A and then B in the same TLS 
session, can’t claim to not be A anymore.

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David Benjamin
Sent: Thursday, May 12, 2016 12:41 PM
To: Eric Rescorla <e...@rtfm.com>
Cc: tls@ietf.org
Subject: Re: [TLS] In-handshake CertificateRequest and 0-RTT

Right, I want to forbid it precisely because I don't want to allow 
post-handshake client auth. :-)

Or rather, I expect most TLS applications will not want post-handshake client 
auth enabled as it significantly changes the authentication picture (TLS-level 
auth can change mid-stream) and would have it off. I would like disabling 
post-handshake client auth to, as a result, disable all such TLS-level 
mid-stream switches. For some legacy uses of HTTP/1.1, sure, post-handshake 
auth will be enabled and this feature doesn't do much harm. (But it also 
doesn't help. The server can just as easily send post-handshake 
CertificateRequest right after the handshake.)

For 1-RTT, there's no mid-stream transition problem. Though it is kind of weird 
for PSK-resumption. PSK-resumption already implicitly carries a set of 
certificate-based identities from the previous run, but we're saying the server 
may ask the client to pick a different one (but not vice versa). Is the client 
still authenticated as the previous one too, or just the new one?

David

On Thu, May 12, 2016 at 3:26 PM Eric Rescorla 
<e...@rtfm.com<mailto:e...@rtfm.com>> wrote:
I agree that the current draft is ambiguous on this point but I think the 
question is what the right
thing is. My intuition here is that we should try to make the client's side and 
the server's side
more independent so that you can have client auth in either case. Given that 
we're going to
allow post-handshake client auth when you resume, it's just not clear to me why 
you wouldn't
allow in-handshake client-auth. I'm not sure it's a hill I'm willing to die on 
though.

-Ekr



On Thu, May 12, 2016 at 9:06 PM, David Benjamin 
<david...@chromium.org<mailto:david...@chromium.org>> wrote:
Which PSK/non-PSK symmetry are you referring to? I didn't think 1.3 currently 
allowed CertificateRequest in a PSK handshake either, or are you referring to 
something else?

Actually, looking at the text again, it's a little confusing right now where 
CertificateRequest is and isn't allowed. The message flow in 6.2.2 implies a 
PSK resumption handshake does not send CertificateRequest. The flow in 6.2.3 
implies a 0-RTT handshake does, but it describes the 0-RTT handshake as:

"""
When resuming via a PSK, clients can also send data on their first flight 
(“early data”). This data is encrypted solely under keys derived using the PSK 
as the static secret. As shown in Figure 4, the Zero-RTT data is just added to 
the 1-RTT handshake in the first flight, the rest of the handshake uses the 
same messages.
"""

This suggests it should match 6.2.2 in whether CertificateRequest is allowed. 
Arguably the rules should be in text, not diagrams, but the text in 6.3.3.2 
just says:

"""
A non-anonymous server can optionally request a certificate from the client, if 
appropriate for the selected cipher suite. This message, if sent, will follow 
EncryptedExtensions.
"""

(I'm guessing "non-anonymous" is a holdover from TLS 1.2's text.)

In TLS 1.2, I believe CertificateRequest in a PSK-based cipher wasn't allowed. 
RFC 4279 explicitly says it's not allowed in plain PSK. It's not clear whether 
that applies to DHE_PSK, but I think that combined with 1.2's "non-anonymous" 
rule gives client auth => certificate-based cipher as the most reasonable 
interpretation.

David

On Thu, May 12, 2016 at 11:19 AM Eric Rescorla 
<e...@rtfm.com<mailto:e...@rtfm.com>> wrote:
Interesting suggestion. I see what you mean about symmetry with the server

The symmetry I was optimizing for is that the PSK and non-PSK handshake, and I 
think from that perspective the current design is simpler, so I see it both 
ways.

WRT to the 0.5RTT data, Hugo Krawczyk has done some nice work on analyzing this 
case and I think we're starting to get more comfort with that.

So, not sure what I think...

-Ekr





On Wed, May 11, 2016 at 10:44 PM, David Benjamin 
<david...@chromium.org<mailto:david...@chromium.org>> wrote:
The 0-RTT handshake originally had two places with a client Certificate + 
CertificateVerify: in the 0-RTT flow and in the second Finished block in 
response to a server CertificateRequest. We've dropped the first now. I propose 
we drop the second too. Client auth with 0-RTT is solely carried over via 
resumption. (I mentioned this previously, but with 0-RTT looking closer to 
resumption and the IETF 95 decision on 0.5-RTT data, I think the case is 
clearer.)

This mak

Re: [TLS] In-handshake CertificateRequest and 0-RTT

2016-05-12 Thread David Benjamin 
Right, I want to forbid it precisely because I don't want to allow
post-handshake client auth. :-)

Or rather, I expect most TLS applications will not want post-handshake
client auth enabled as it significantly changes the authentication picture
(TLS-level auth can change mid-stream) and would have it off. I would like
disabling post-handshake client auth to, as a result, disable all such
TLS-level mid-stream switches. For some legacy uses of HTTP/1.1, sure,
post-handshake auth will be enabled and this feature doesn't do much harm.
(But it also doesn't help. The server can just as easily send
post-handshake CertificateRequest right after the handshake.)

For 1-RTT, there's no mid-stream transition problem. Though it is kind of
weird for PSK-resumption. PSK-resumption already implicitly carries a set
of certificate-based identities from the previous run, but we're saying the
server may ask the client to pick a different one (but not vice versa). Is
the client still authenticated as the previous one too, or just the new one?

David

On Thu, May 12, 2016 at 3:26 PM Eric Rescorla  wrote:

> I agree that the current draft is ambiguous on this point but I think the
> question is what the right
> thing is. My intuition here is that we should try to make the client's
> side and the server's side
> more independent so that you can have client auth in either case. Given
> that we're going to
> allow post-handshake client auth when you resume, it's just not clear to
> me why you wouldn't
> allow in-handshake client-auth. I'm not sure it's a hill I'm willing to
> die on though.
>
> -Ekr
>
>
>
> On Thu, May 12, 2016 at 9:06 PM, David Benjamin 
> wrote:
>
>> Which PSK/non-PSK symmetry are you referring to? I didn't think 1.3
>> currently allowed CertificateRequest in a PSK handshake either, or are you
>> referring to something else?
>>
>> Actually, looking at the text again, it's a little confusing right now
>> where CertificateRequest is and isn't allowed. The message flow in 6.2.2
>> implies a PSK resumption handshake does not send CertificateRequest. The
>> flow in 6.2.3 implies a 0-RTT handshake does, but it describes the 0-RTT
>> handshake as:
>>
>> """
>> When resuming via a PSK, clients can also send data on their first flight
>> (“early data”). This data is encrypted solely under keys derived using the
>> PSK as the static secret. As shown in Figure 4, the Zero-RTT data is just
>> added to the 1-RTT handshake in the first flight, the rest of the handshake
>> uses the same messages.
>> """
>>
>> This suggests it should match 6.2.2 in whether CertificateRequest is
>> allowed. Arguably the rules should be in text, not diagrams, but the
>> text in 6.3.3.2 just says:
>>
>> """
>> A non-anonymous server can optionally request a certificate from the
>> client, if appropriate for the selected cipher suite. This message, if
>> sent, will follow EncryptedExtensions.
>> """
>>
>> (I'm guessing "non-anonymous" is a holdover from TLS 1.2's text.)
>>
>> In TLS 1.2, I believe CertificateRequest in a PSK-based cipher wasn't
>> allowed. RFC 4279 explicitly says it's not allowed in plain PSK. It's not
>> clear whether that applies to DHE_PSK, but I think that combined with 1.2's
>> "non-anonymous" rule gives client auth => certificate-based cipher as the
>> most reasonable interpretation.
>>
>> David
>>
>> On Thu, May 12, 2016 at 11:19 AM Eric Rescorla  wrote:
>>
>>> Interesting suggestion. I see what you mean about symmetry with the
>>> server
>>>
>>> The symmetry I was optimizing for is that the PSK and non-PSK handshake,
>>> and I think from that perspective the current design is simpler, so I see
>>> it both ways.
>>>
>>> WRT to the 0.5RTT data, Hugo Krawczyk has done some nice work on
>>> analyzing this case and I think we're starting to get more comfort with
>>> that.
>>>
>>> So, not sure what I think...
>>>
>>> -Ekr
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 11, 2016 at 10:44 PM, David Benjamin 
>>> wrote:
>>>
 The 0-RTT handshake originally had two places with a client
 Certificate + CertificateVerify: in the 0-RTT flow and in the second
 Finished block in response to a server CertificateRequest. We've
 dropped the first now. I propose we drop the second too. Client auth with
 0-RTT is solely carried over via resumption. (I mentioned this previously,
 but with 0-RTT looking closer to resumption and the IETF 95 decision on
 0.5-RTT data, I think the case is clearer.)

 This makes 6.2.3 more consistent with 6.2.2 where neither side
 authenticates in a resumption handshake. 0-RTT is much more similar to
 resumption with most parameters carrying over anyway.

 1-RTT client auth in a 0-RTT handshake also invites more of the
 retroactive auth confusion as with post-handshake auth. The client stream
 switches from unauthenticated to authenticated. I believe this was one
 of the reasons we agreed

Re: [TLS] In-handshake CertificateRequest and 0-RTT

2016-05-12 Thread Eric Rescorla 
I agree that the current draft is ambiguous on this point but I think the
question is what the right
thing is. My intuition here is that we should try to make the client's side
and the server's side
more independent so that you can have client auth in either case. Given
that we're going to
allow post-handshake client auth when you resume, it's just not clear to me
why you wouldn't
allow in-handshake client-auth. I'm not sure it's a hill I'm willing to die
on though.

-Ekr



On Thu, May 12, 2016 at 9:06 PM, David Benjamin 
wrote:

> Which PSK/non-PSK symmetry are you referring to? I didn't think 1.3
> currently allowed CertificateRequest in a PSK handshake either, or are you
> referring to something else?
>
> Actually, looking at the text again, it's a little confusing right now
> where CertificateRequest is and isn't allowed. The message flow in 6.2.2
> implies a PSK resumption handshake does not send CertificateRequest. The
> flow in 6.2.3 implies a 0-RTT handshake does, but it describes the 0-RTT
> handshake as:
>
> """
> When resuming via a PSK, clients can also send data on their first flight
> (“early data”). This data is encrypted solely under keys derived using the
> PSK as the static secret. As shown in Figure 4, the Zero-RTT data is just
> added to the 1-RTT handshake in the first flight, the rest of the handshake
> uses the same messages.
> """
>
> This suggests it should match 6.2.2 in whether CertificateRequest is
> allowed. Arguably the rules should be in text, not diagrams, but the text
> in 6.3.3.2 just says:
>
> """
> A non-anonymous server can optionally request a certificate from the
> client, if appropriate for the selected cipher suite. This message, if
> sent, will follow EncryptedExtensions.
> """
>
> (I'm guessing "non-anonymous" is a holdover from TLS 1.2's text.)
>
> In TLS 1.2, I believe CertificateRequest in a PSK-based cipher wasn't
> allowed. RFC 4279 explicitly says it's not allowed in plain PSK. It's not
> clear whether that applies to DHE_PSK, but I think that combined with 1.2's
> "non-anonymous" rule gives client auth => certificate-based cipher as the
> most reasonable interpretation.
>
> David
>
> On Thu, May 12, 2016 at 11:19 AM Eric Rescorla  wrote:
>
>> Interesting suggestion. I see what you mean about symmetry with the server
>>
>> The symmetry I was optimizing for is that the PSK and non-PSK handshake,
>> and I think from that perspective the current design is simpler, so I see
>> it both ways.
>>
>> WRT to the 0.5RTT data, Hugo Krawczyk has done some nice work on
>> analyzing this case and I think we're starting to get more comfort with
>> that.
>>
>> So, not sure what I think...
>>
>> -Ekr
>>
>>
>>
>>
>>
>> On Wed, May 11, 2016 at 10:44 PM, David Benjamin 
>> wrote:
>>
>>> The 0-RTT handshake originally had two places with a client
>>> Certificate + CertificateVerify: in the 0-RTT flow and in the second
>>> Finished block in response to a server CertificateRequest. We've
>>> dropped the first now. I propose we drop the second too. Client auth with
>>> 0-RTT is solely carried over via resumption. (I mentioned this previously,
>>> but with 0-RTT looking closer to resumption and the IETF 95 decision on
>>> 0.5-RTT data, I think the case is clearer.)
>>>
>>> This makes 6.2.3 more consistent with 6.2.2 where neither side
>>> authenticates in a resumption handshake. 0-RTT is much more similar to
>>> resumption with most parameters carrying over anyway.
>>>
>>> 1-RTT client auth in a 0-RTT handshake also invites more of the
>>> retroactive auth confusion as with post-handshake auth. The client stream
>>> switches from unauthenticated to authenticated. I believe this was one
>>> of the reasons we agreed at IETF 95 to discourage/forbid (not sure which)
>>> sending 0.5-RTT data following a CertificateRequest. In-handshake
>>> CertificateRequest either requires this discouraged situation or accepting
>>> 0-RTT data without sending 0.5-RTT data, which is largely pointless.
>>>
>>> We accepted the retroactive auth issue in post-handshake auth, but I
>>> think we should limit it to that. For implementations, BoringSSL made
>>> accepting renego an opt-in feature. I expect we'd do the same for
>>> post-handshake auth. For specs, one might specify that post-handshake
>>> authentication is forbidden. HTTP/2 did this for renegotiation. I
>>> haven't been following the HTTP/2 client cert saga as closely, but
>>> draft-thomson-http2-client-certs-02 is the current plan, right? If so,
>>> HTTP/2 should forbid TLS-level post-handshake auth too.
>>>
>>> In both cases, excluding post-handshake auth should exclude any
>>> transition from unauthenticated to authenticated in the stream. Instead, if
>>> you want to change authentication state, send a post-handshake
>>> CertificateRequest, as you would have normally.
>>>
>>> David
>>>
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>>

Re: [TLS] In-handshake CertificateRequest and 0-RTT

2016-05-12 Thread Eric Rescorla 
Interesting suggestion. I see what you mean about symmetry with the server

The symmetry I was optimizing for is that the PSK and non-PSK handshake,
and I think from that perspective the current design is simpler, so I see
it both ways.

WRT to the 0.5RTT data, Hugo Krawczyk has done some nice work on analyzing
this case and I think we're starting to get more comfort with that.

So, not sure what I think...

-Ekr





On Wed, May 11, 2016 at 10:44 PM, David Benjamin 
wrote:

> The 0-RTT handshake originally had two places with a client Certificate +
> CertificateVerify: in the 0-RTT flow and in the second Finished block in
> response to a server CertificateRequest. We've dropped the first now. I
> propose we drop the second too. Client auth with 0-RTT is solely carried
> over via resumption. (I mentioned this previously, but with 0-RTT looking
> closer to resumption and the IETF 95 decision on 0.5-RTT data, I think the
> case is clearer.)
>
> This makes 6.2.3 more consistent with 6.2.2 where neither side
> authenticates in a resumption handshake. 0-RTT is much more similar to
> resumption with most parameters carrying over anyway.
>
> 1-RTT client auth in a 0-RTT handshake also invites more of the
> retroactive auth confusion as with post-handshake auth. The client stream
> switches from unauthenticated to authenticated. I believe this was one of
> the reasons we agreed at IETF 95 to discourage/forbid (not sure which)
> sending 0.5-RTT data following a CertificateRequest. In-handshake
> CertificateRequest either requires this discouraged situation or accepting
> 0-RTT data without sending 0.5-RTT data, which is largely pointless.
>
> We accepted the retroactive auth issue in post-handshake auth, but I think
> we should limit it to that. For implementations, BoringSSL made accepting
> renego an opt-in feature. I expect we'd do the same for post-handshake
> auth. For specs, one might specify that post-handshake authentication is
> forbidden. HTTP/2 did this for renegotiation. I haven't been following
> the HTTP/2 client cert saga as closely, but
> draft-thomson-http2-client-certs-02 is the current plan, right? If so,
> HTTP/2 should forbid TLS-level post-handshake auth too.
>
> In both cases, excluding post-handshake auth should exclude any transition
> from unauthenticated to authenticated in the stream. Instead, if you want
> to change authentication state, send a post-handshake CertificateRequest,
> as you would have normally.
>
> 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] In-handshake CertificateRequest and 0-RTT

2016-05-12 Thread Martin Thomson 
On 12 May 2016 at 12:41, David Benjamin  wrote:
> Sure, if we end up doing something on the server, mirroring sounds
> reasonable enough. (This would just be for re-asserting the private key and
> not switching certificates, right?)

Not planning to allow it :)

>[re: post handshake as an extension]
> For HTTP, doing it in an extension the obvious way doesn't quite work.
> Whether Chrome is willing to do renego depends on how ALPN resolves (we
> leave it at its default off state and, after the initial handshake but
> before we could consume a HelloRequest, toggle it off).

Yeah, it's not ideal, but you could advertise support, then refuse to
respond when it is requested of you in situations that you don't like.
But Chrome is, as ever, somewhat special in this regard.  Everyone
else would be sort of protected from accidents unless they took the
same rather extraordinary steps to enable the feature.

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

Re: [TLS] In-handshake CertificateRequest and 0-RTT

2016-05-11 Thread David Benjamin 
On Wed, May 11, 2016 at 9:25 PM Martin Thomson 
wrote:

> I think that this is a fine way to simplify, but I have a wrinkle to add.
>
> I would rather this be formulated as: a client cannot authenticate
> using Certificate[+Verify] unless the server does so first.
>


> The reason that I want that is this issue
> https://github.com/tlswg/tls13-spec/issues/443  I want to be able to
> do 0-RTT but have the server continue to prove that it has the private
> key (maybe some clients will do that occasionally).  For those, I
> think that reciprocating is reasonable.  It doesn't significantly
> change the state machine in that case.
>
> I hope to write a draft explaining this soon, so that folks can see
> what it costs/looks like.
>

Sure, if we end up doing something on the server, mirroring sounds
reasonable enough. (This would just be for re-asserting the private key and
not switching certificates, right?)


> On 12 May 2016 at 06:44, David Benjamin  wrote:
> > The 0-RTT handshake originally had two places with a client Certificate +
> > CertificateVerify: in the 0-RTT flow and in the second Finished block in
> > response to a server CertificateRequest. We've dropped the first now. I
> > propose we drop the second too. Client auth with 0-RTT is solely carried
> > over via resumption. (I mentioned this previously, but with 0-RTT looking
> > closer to resumption and the IETF 95 decision on 0.5-RTT data, I think
> the
> > case is clearer.)
>
> > We accepted the retroactive auth issue in post-handshake auth, but I
> think
> > we should limit it to that. For implementations, BoringSSL made accepting
> > renego an opt-in feature. I expect we'd do the same for post-handshake
> auth.
>
> I totally agree about the post-handshake stuff.  I'm somewhat inclined
> to ask that it be made an extension so that you can cleanly opt out.
>

For HTTP, doing it in an extension the obvious way doesn't quite work.
Whether Chrome is willing to do renego depends on how ALPN resolves (we
leave it at its default off state and, after the initial handshake but
before we could consume a HelloRequest, toggle it off).

Supposing post-handshake auth is still used for HTTP/1.1 + TLS 1.3 (am I
right that this is the plan?), we'd be in a similar situation. The
ClientHello would say post-handshake auth is allowed, but we may end up in
a state where it isn't anyway.

(I think implicitness is fine, though an extension seem fine too. The
application already gets to impose other restrictions on the use of TLS
like "the first application data record should begin with G, E, T, space".)


> > For specs, one might specify that post-handshake authentication is
> > forbidden. HTTP/2 did this for renegotiation. I haven't been following
> the
> > HTTP/2 client cert saga as closely, but
> draft-thomson-http2-client-certs-02
> > is the current plan, right? If so, HTTP/2 should forbid TLS-level
> > post-handshake auth too.
>
> We're doubling down on that idea and considering allowing the server
> to authenticate too.  See
> https://mikebishop.github.io/http2-client-certs/  (you might recognize
> some similarity to the SPDY CREDENTIAL frame if you squint hard
> enough).
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls