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

[David Benjamin <[e-mail]>]

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-mail]> 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 <[e-mail]>
> 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-mail]> 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 <[e-mail]>
>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>>
>>>
>