Re: [TLS] Commentary on the client authentication presentation slides
Hi Ilari, > What sort of usecase you have in mind for this? This is to support a fairly common website design where the landing page does not require client auth, but subsequent request to a protected resource triggers client authentication within an existing TLS connection. In TLS<=1.2, this was accomplished via renegotiation. In TLS1.3, there is no renegotiation, so we need an alternative solution if we want to support these existing sites over TLS1.3. > Where's the capability for client to unilaterially decide to send a > certificate without valid configuration? My pull request is designed to address client auth in the middle of a TLS connection, after the handshake is complete, which is an existing scenario that was broken by the removal of renegotiation in TLS 1.3. If enough people want the capability for the client to volunteer a certificate, I don't mind adding this to my pull request. Right now I don't have a sense of how useful WG participants think this would be. Cheers, Andrei -Original Message- From: Ilari Liusvaara [mailto:ilari.liusva...@elisanet.fi] Sent: Saturday, August 8, 2015 2:04 AM To: Andrei Popov Cc: David Benjamin ; tls@ietf.org Subject: Re: [TLS] Commentary on the client authentication presentation slides On Tue, Aug 04, 2015 at 12:37:47AM +, Andrei Popov wrote: > > Well, TLS is also used for non-browser HTTPS and stuff other than HTTPS. > > There one likely "preconfigures" client certificates if needed. > The proposed client authentication mechanism specifically addresses > the case where the client does not have one "preconfigured" cert. What sort of usecase you have in mind for this? I can't come up with single one that I don't think is a hack at best. Note: It is very easy to misuse capability like this (even if it is restricted to work only once per connection) to create nasty security issues (one example being trying to use this for HTTP/2 in browser environment). > > - TLS-level client certificate auth on client request on connect > > (this currently can't be cleanly done, sometimes one even sees that > > "renego immediately to provoke CR" hack). > With the proposed change, there will be no need to renegotiate in > order to authenticate the client. Where's the capability for client to unilaterially decide to send a certificate without valid configuration? The 0-RTT certificate authentication requires a valid configuration. E.g. one way to implement that would be certificate_request_request extension, which would request server to send a CertificateRequest. Tho with the changes to always sign the key exchange, using 0-RTT client certs doesn't work unless the server requested certificates back then. > > - Application-level client auth (via CB capability of TLS). > The proposed mechanism does not preclude this option. That was given as second of two entries in list of kinds of authentication I think are useful (and precluding it would mean removing TLS-Unique and TLS-Extractor, which is something that I really don't see happening). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
> On Aug 10, 2015, at 8:10 PM, Andrei Popov wrote: > > Hi Ilari, > >> What sort of usecase you have in mind for this? > This is to support a fairly common website design where the landing page does > not require client auth, but subsequent request to a protected resource > triggers client authentication within an existing TLS connection. > In TLS<=1.2, this was accomplished via renegotiation. In TLS1.3, there is no > renegotiation, so we need an alternative solution if we want to support these > existing sites over TLS1.3. I’d like to point out that I am very interested in this use case, but I’m not sure that this is the solution. Such sites were first broken by HTTP/2 which forbade renegotiation. Then they were broken again by TLS 1.3 that does not include renegotiation. Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2. Assuming that HTTP/2 is the HTTP of the future (meaning that relegating these sites to HTTP/1 is a temporary thing), I don’t think that this new mechanism fixes the issue with renegotiation that caused httpbis to reject its usage. We still get a race condition where several requests might be answered before, after or during authentication depending on the timing of the TLS handshake message vs the HTTP messages. It would be useless IMO to create an alternate renegotiation in TLS only for it to not be used in HTTP/2. Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
> Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS 1.3, > HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2. Correct, anything less than this will create deployment problems. > I’d like to point out that I am very interested in this use case, but I’m not > sure that this is the solution. I'm open to alternatives that fix the broken use case. > We still get a race condition where several requests might be answered > before, after or during authentication depending on the timing of the TLS > handshake message vs the HTTP messages. The idea is that before answering a request that requires client auth, the server checks if a client cred is available. If there is no suitable client cred available, the request is blocked until the client authenticates. This does not necessarily have to block other requests that do not require client auth. Cheers, Andrei -Original Message- From: Yoav Nir [mailto:ynir.i...@gmail.com] Sent: Monday, August 10, 2015 10:28 AM To: Andrei Popov Cc: Ilari Liusvaara ; tls@ietf.org Subject: Re: [TLS] Commentary on the client authentication presentation slides > On Aug 10, 2015, at 8:10 PM, Andrei Popov wrote: > > Hi Ilari, > >> What sort of usecase you have in mind for this? > This is to support a fairly common website design where the landing page does > not require client auth, but subsequent request to a protected resource > triggers client authentication within an existing TLS connection. > In TLS<=1.2, this was accomplished via renegotiation. In TLS1.3, there is no > renegotiation, so we need an alternative solution if we want to support these > existing sites over TLS1.3. I’d like to point out that I am very interested in this use case, but I’m not sure that this is the solution. Such sites were first broken by HTTP/2 which forbade renegotiation. Then they were broken again by TLS 1.3 that does not include renegotiation. Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2. Assuming that HTTP/2 is the HTTP of the future (meaning that relegating these sites to HTTP/1 is a temporary thing), I don’t think that this new mechanism fixes the issue with renegotiation that caused httpbis to reject its usage. We still get a race condition where several requests might be answered before, after or during authentication depending on the timing of the TLS handshake message vs the HTTP messages. It would be useless IMO to create an alternate renegotiation in TLS only for it to not be used in HTTP/2. Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
On Mon, Aug 10, 2015 at 3:05 PM Andrei Popov wrote: > > Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS > 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2. > Correct, anything less than this will create deployment problems. > But this proposal is only suitable for HTTP/1 over TLS 1.3 anyway. It can't be used for HTTP/2 over TLS 1.3 as a client has no way to correlate transport-level certificate requests with the HTTP request. This is part of why renego was rightly banned for HTTP/2. Otherwise you need to show a contextless prompt on a client, and that's really bad UI. Chrome tries very hard to avoid those. I would grudgingly consider it acceptable for HTTP/1 over TLS 1.3, but only because it's no worse than the renego one and we're stuck with that legacy mistake right now. If that weren't the case, I wouldn't want it in HTTP/1 either. Changing connection-level state mid-stream underneath a multi-request protocol is very messy, particularly when combined with socket-pooling optimizations. Why not do this using HTTP's own auth framework? Have the client sign something which includes a channel binding, placing it and the certificate chain in an Authorization header. You could even transition to it in TLS 1.2 deployments, provided EMS is negotiated. When TLS 1.3 and EMS are not negotiated, fall back to the legacy thing. David > > I’d like to point out that I am very interested in this use case, but > I’m not sure that this is the solution. > I'm open to alternatives that fix the broken use case. > > > We still get a race condition where several requests might be answered > before, after or during authentication depending on the timing of the TLS > handshake message vs the HTTP messages. > The idea is that before answering a request that requires client auth, the > server checks if a client cred is available. If there is no suitable client > cred available, the request is blocked until the client authenticates. This > does not necessarily have to block other requests that do not require > client auth. > > Cheers, > > Andrei > > -Original Message- > From: Yoav Nir [mailto:ynir.i...@gmail.com] > Sent: Monday, August 10, 2015 10:28 AM > To: Andrei Popov > Cc: Ilari Liusvaara ; tls@ietf.org > Subject: Re: [TLS] Commentary on the client authentication presentation > slides > > > > On Aug 10, 2015, at 8:10 PM, Andrei Popov > wrote: > > > > Hi Ilari, > > > >> What sort of usecase you have in mind for this? > > This is to support a fairly common website design where the landing page > does not require client auth, but subsequent request to a protected > resource triggers client authentication within an existing TLS connection. > > In TLS<=1.2, this was accomplished via renegotiation. In TLS1.3, there > is no renegotiation, so we need an alternative solution if we want to > support these existing sites over TLS1.3. > > I’d like to point out that I am very interested in this use case, but I’m > not sure that this is the solution. > > Such sites were first broken by HTTP/2 which forbade renegotiation. Then > they were broken again by TLS 1.3 that does not include renegotiation. > > Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS > 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2. > > Assuming that HTTP/2 is the HTTP of the future (meaning that relegating > these sites to HTTP/1 is a temporary thing), I don’t think that this new > mechanism fixes the issue with renegotiation that caused httpbis to reject > its usage. We still get a race condition where several requests might be > answered before, after or during authentication depending on the timing of > the TLS handshake message vs the HTTP messages. > > It would be useless IMO to create an alternate renegotiation in TLS only > for it to not be used in HTTP/2. > > Yoav > > ___ > 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] Commentary on the client authentication presentation slides
> On Aug 10, 2015, at 10:04 PM, Andrei Popov wrote: > >> Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS 1.3, >> HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2. > Correct, anything less than this will create deployment problems. > >> I’d like to point out that I am very interested in this use case, but I’m >> not sure that this is the solution. > I'm open to alternatives that fix the broken use case. One solution would be to move the authentication for this use case (and perhaps for HTTPS in general) from the transport layer to either HTTP as an authentication method or to the application (through some standardized exchange of JSON objects). Another option is to allow renegotiation and your mechanism in HTTP/2 with some change of behavior that eliminates the race condition. For example: 1. The server receives a request for a resource that requires a client certificate 2. The server sends a new HTTP message (or code) that says that client certificate authentication is required. 3. The client sends a new HTTP control frame with the highest number of resource that it has requested. 4. The server finishes serving all resources that don’t need authentication with a number below what the client sent 5. The client does not initiate any new requests. 6. When the server is done, it initiates renegotiation or the new mechanism 7. After renegotiation, the client can resume sending requests, all of which are authenticated. The details may be different, but something like this can bring determinism to the process. >> We still get a race condition where several requests might be answered >> before, after or during authentication depending on the timing of the TLS >> handshake message vs the HTTP messages. > The idea is that before answering a request that requires client auth, the > server checks if a client cred is available. If there is no suitable client > cred available, the request is blocked until the client authenticates. This > does not necessarily have to block other requests that do not require client > auth. This is a somewhat contrived example, but consider an object in the web page that says “Hello, guest” when no credential is available, and “Hello, Andrei” when a credential is available. If the page has optional authentication and you have presented the certificate, then depending on timing you might still see “Hello, guest” on the page. Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
> One solution would be to move the authentication for this use case (and > perhaps for HTTPS in general) from the transport layer to either HTTP as an > authentication method or to the application (through some standardized > exchange of JSON objects). Doesn't this require an update of the site? If so, it defeats our goal of supporting existing sites over new protocols. > Another option is to allow renegotiation and your mechanism in HTTP/2 with > some change of behavior that eliminates the race condition. I'm not sure what purpose #3 (HTTP control frame with the highest number of resource) serves. Couldn't we just say the client must not send new requests after receiving CertificateRequest and until sending CertificateVerify? > This is a somewhat contrived example, but consider an object in the web page > that says “Hello, guest” when no credential is available, and “Hello, Andrei” > when a credential is available. If the page has optional authentication and > you have presented the certificate, then depending on timing you might still > see “Hello, guest” on the page. This just means that a request was answered at the time there was no client credential. This page probably needs to be a resource that requires client auth. -Original Message- From: Yoav Nir [mailto:ynir.i...@gmail.com] Sent: Monday, August 10, 2015 12:53 PM To: Andrei Popov Cc: Ilari Liusvaara ; tls@ietf.org Subject: Re: [TLS] Commentary on the client authentication presentation slides > On Aug 10, 2015, at 10:04 PM, Andrei Popov wrote: > >> Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS 1.3, >> HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2. > Correct, anything less than this will create deployment problems. > >> I’d like to point out that I am very interested in this use case, but I’m >> not sure that this is the solution. > I'm open to alternatives that fix the broken use case. One solution would be to move the authentication for this use case (and perhaps for HTTPS in general) from the transport layer to either HTTP as an authentication method or to the application (through some standardized exchange of JSON objects). Another option is to allow renegotiation and your mechanism in HTTP/2 with some change of behavior that eliminates the race condition. For example: 1. The server receives a request for a resource that requires a client certificate 2. The server sends a new HTTP message (or code) that says that client certificate authentication is required. 3. The client sends a new HTTP control frame with the highest number of resource that it has requested. 4. The server finishes serving all resources that don’t need authentication with a number below what the client sent 5. The client does not initiate any new requests. 6. When the server is done, it initiates renegotiation or the new mechanism 7. After renegotiation, the client can resume sending requests, all of which are authenticated. The details may be different, but something like this can bring determinism to the process. >> We still get a race condition where several requests might be answered >> before, after or during authentication depending on the timing of the TLS >> handshake message vs the HTTP messages. > The idea is that before answering a request that requires client auth, the > server checks if a client cred is available. If there is no suitable client > cred available, the request is blocked until the client authenticates. This > does not necessarily have to block other requests that do not require client > auth. This is a somewhat contrived example, but consider an object in the web page that says “Hello, guest” when no credential is available, and “Hello, Andrei” when a credential is available. If the page has optional authentication and you have presented the certificate, then depending on timing you might still see “Hello, guest” on the page. Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Last Call: (A TLS ClientHello padding extension) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'A TLS ClientHello padding extension' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2015-08-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes a TLS extension that can be used to pad ClientHello messages to a desired size. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-padding/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-padding/ballot/ No IPR declarations have been submitted directly on this I-D. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
On Mon, Aug 10, 2015 at 07:33:53PM +, David Benjamin wrote: > > Why not do this using HTTP's own auth framework? Have the client sign > something which includes a channel binding, placing it and the certificate > chain in an Authorization header. You could even transition to it in TLS > 1.2 deployments, provided EMS is negotiated. When TLS 1.3 and EMS are not > negotiated, fall back to the legacy thing. Yeah, that would be much cleaner (and indeed was one[1] of the two ways I think HTTP/2 client auth can be done without gross hacks). Except that because for clean operation HTTP needs request-level authentication, one would have to transmit the authentication on each request (fortunately, on subsequent retransmits, it can be compressed very well[2]). [1] The other would be signaling via HTTP 401 and using that to trigger new connection with client-driven client auth. [2] Unless the payload needs internal nonces (and I don't think it does), one can assume the same certificate on the same connection always generates the same cert+signature block (if using deterministic signatures, that happens even if one tries to sign again). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
On Monday, August 10, 2015 01:10:38 pm Andrei Popov wrote: > > What sort of usecase you have in mind for this? > > This is to support a fairly common website design where the landing page does > not require client auth, but subsequent request to a protected resource > triggers client authentication within an existing TLS connection. > In TLS<=1.2, this was accomplished via renegotiation. In TLS1.3, there is no > renegotiation, so we need an alternative solution if we want to support these > existing sites over TLS1.3. This is just an idea, but what about just allowing a renegotiation-like mechanism via 0-RTT with PSK resumption to be triggered on a TLS alert or HTTP response code? The rough idea would be like this: 1) client connects to server and fetches public resources 2) client requests restricted resource; server sends auth required response (TLS alert or HTTP code) 3) client creates a replacement connection using PSK-based resumption and early data in the first flight for the request along with the client cert. There's a 1 roundtrip cost in there for a new TCP connection, which could possibly be optimized away by using TCP fast open. This general concept is relatively simple in comparison to doing something mid-connection. Instead of attempting to renegotiate on an existing connection, just make creation of resumed connections cheap enough to start over with client auth in the handshake from the start. It's a very rough idea, but I'm wondering if it sounds like something worth discussing. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
