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

Reply via email to