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