Re: [TLS] Commentary on the client authentication presentation slides
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. While this might have been the structure of a few legacy sites, this will meet the axe longe before TLSv1.3 is done, because HTTP/2 prohibits renegotiation with TLSv1.2 as well. R.I.P. renegotiation. -Martin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
Indeed, I think cant-care has a number of disadvantages: 1. Introduces round-trips to establish a new TCP connection; 2. Requires a new TLS handshake, with associated costs. 3. Uses two CertificateRequests: one at the HTTP layer, and another at the TLS layer. Somehow we would need to figure out how to make them match, or have the client ignore TLS-level cert filtering parameters? 4. Pushes the problem to the application layer: any application protocol that uses mid-stream client auth will require an update. (I know, some will say we are only aware of HTTPS scenarios right now.) At the cost of all of the above, cant-care allows the client to determine exactly which HTTP request has resulted in the client auth request. I think there may be a compromise where we can identify this HTTP request without requiring a reconnect. E.g. what about CertificateRequest at the HTTP layer + TLS client sending Certificate/CertificateVerify after the handshake in the middle of the existing TLS connection? Cheers, Andrei -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson Sent: Tuesday, August 11, 2015 9:39 AM To: Dave Garrett Cc: tls@ietf.org Subject: Re: [TLS] Commentary on the client authentication presentation slides Before people get too far down that road, here: https://tools.ietf.org/html/draft-thomson-httpbis-cant-01 https://tools.ietf.org/html/draft-thomson-tls-care-00 Andrei has made it clear that these do not work for his use case (I'm not yet convinced that they are inadequate, but I am convinced of the fact that Andrei thinks that they are inadequate ;). Also: https://tools.ietf.org/html/draft-ietf-httpbis-http2-00#section-2.6.9 This is well-trodden ground. On 10 August 2015 at 23:05, Dave Garrett wrote: > 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 ___ 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
Before people get too far down that road, here: https://tools.ietf.org/html/draft-thomson-httpbis-cant-01 https://tools.ietf.org/html/draft-thomson-tls-care-00 Andrei has made it clear that these do not work for his use case (I'm not yet convinced that they are inadequate, but I am convinced of the fact that Andrei thinks that they are inadequate ;). Also: https://tools.ietf.org/html/draft-ietf-httpbis-http2-00#section-2.6.9 This is well-trodden ground. On 10 August 2015 at 23:05, Dave Garrett wrote: > 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 ___ 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
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
> 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
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
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
> 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 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
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 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
> 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. > - 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. > - Application-level client auth (via CB capability of TLS). The proposed mechanism does not preclude this option. Cheers, Andrei -Original Message- From: Ilari Liusvaara [mailto:ilari.liusva...@elisanet.fi] Sent: Sunday, August 2, 2015 11:29 AM To: David Benjamin Cc: Andrei Popov ; tls@ietf.org Subject: Re: [TLS] Commentary on the client authentication presentation slides On Sun, Aug 02, 2015 at 03:38:00PM +, David Benjamin wrote: > On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara > > wrote: > > > > What I think would be very useful: A way for client to signal it has > > a client certificate it expects to use, regardless of if valid > > configuration is known. The vast majority of times client > > certificate is used, the client knows about that before initiating a > > connection. > > Unless I misunderstand you, this isn't true for a browser. Browsers > only look for client certificates based on a CertificateRequest > message. Some platforms, like Android, don't even let you list the > user's certificate store. Instead there's an API to show a trusted > certificate picker prompt. Well, TLS is also used for non-browser HTTPS and stuff other than HTTPS. There one likely "preconfigures" client certificates if needed. > Or, given the paragraph below, are you suggesting that we'd start a > second connection on receiving CertificateRequest and only advertise it then? > Yeah, that's actually how Chrome implements client auth anyway. We > always start a second connection with a client certificate configured, > even if the server sent CertificateRequest on a renego. It makes a few things > simpler. Doesn't that count as "knowing about client certificate before connecting" (even if the knowledge has been received split-second before TLS handshake starts)? Also, signaling can be at application layer, as talked about below. > > IMO, the proper way to handle "this resource requires client certificate" > > is for server to signal that in application protocol and then client > > to establish a new connection with client certificate (or if > > application protocol supports it, do the authentication at > > application layer without ever involving TLS, except for channel binding). > > Certainly. Chrome doesn't implement TLS_RENEG_PERMITTED for HTTP/2, > and I don't want to allow this mechanism for it either. I consider > renego-based per-resource client auth in HTTP/1.1 to be a legacy > mistake we're currently stuck with. (It's the only reason we ever have > to renego. In BoringSSL, we've settled on stripping renego down to the > bare minimum needed to support this. Simplifies a lot of stuff.) Yeah, I consider it (renego auth in HTTP/1.1) a poor idea as well, and I consider it would be actively dangerous in browser HTTP/2 (due to the multipoint nature of the environment and multiplexed nature of HTTP/2)... Good thing it is banned. > I'm guessing Microsoft has different constraints/goals, given this > proposal and TLS_RENEG_PERMITTED, so if we must have it in the > transport, I'd rather it be some opt-in corner that I don't have to > deal with. (Applications can return HTTP_1_1_REQUIRED in HTTP/2 if > they really must do per-resource client auth.) But I do agree this is > a problematic mechanism and don't think it belongs in TLS. Let the > application layer do it with a channel binding. No need for new > connections, and no messy questions about scope and multi-request protocols. Summary of what auth modes I think are needed: - 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). - Application-level client auth (via CB capability of TLS). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
On Sun, Aug 02, 2015 at 03:38:00PM +, David Benjamin wrote: > On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara > wrote: > > > > What I think would be very useful: A way for client to signal it has a > > client certificate it expects to use, regardless of if valid configuration > > is known. The vast majority of times client certificate is used, the > > client knows about that before initiating a connection. > > Unless I misunderstand you, this isn't true for a browser. Browsers only > look for client certificates based on a CertificateRequest message. Some > platforms, like Android, don't even let you list the user's certificate > store. Instead there's an API to show a trusted certificate picker prompt. Well, TLS is also used for non-browser HTTPS and stuff other than HTTPS. There one likely "preconfigures" client certificates if needed. > Or, given the paragraph below, are you suggesting that we'd start a second > connection on receiving CertificateRequest and only advertise it then? > Yeah, that's actually how Chrome implements client auth anyway. We always > start a second connection with a client certificate configured, even if the > server sent CertificateRequest on a renego. It makes a few things simpler. Doesn't that count as "knowing about client certificate before connecting" (even if the knowledge has been received split-second before TLS handshake starts)? Also, signaling can be at application layer, as talked about below. > > IMO, the proper way to handle "this resource requires client certificate" > > is for server to signal that in application protocol and then client to > > establish a new connection with client certificate (or if application > > protocol supports it, do the authentication at application layer without > > ever involving TLS, except for channel binding). > > Certainly. Chrome doesn't implement TLS_RENEG_PERMITTED for HTTP/2, and I > don't want to allow this mechanism for it either. I consider renego-based > per-resource client auth in HTTP/1.1 to be a legacy mistake we're currently > stuck with. (It's the only reason we ever have to renego. In BoringSSL, > we've settled on stripping renego down to the bare minimum needed to > support this. Simplifies a lot of stuff.) Yeah, I consider it (renego auth in HTTP/1.1) a poor idea as well, and I consider it would be actively dangerous in browser HTTP/2 (due to the multipoint nature of the environment and multiplexed nature of HTTP/2)... Good thing it is banned. > I'm guessing Microsoft has different constraints/goals, given this proposal > and TLS_RENEG_PERMITTED, so if we must have it in the transport, I'd rather > it be some opt-in corner that I don't have to deal with. (Applications can > return HTTP_1_1_REQUIRED in HTTP/2 if they really must do per-resource > client auth.) But I do agree this is a problematic mechanism and don't > think it belongs in TLS. Let the application layer do it with a channel > binding. No need for new connections, and no messy questions about scope > and multi-request protocols. Summary of what auth modes I think are needed: - 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). - Application-level client auth (via CB capability of TLS). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara wrote: > > On Tue, Jul 28, 2015 at 6:28 PM David Benjamin > wrote: > > > > > Are you intending that this mechanism be enabled by default for HTTP/2 > or > > > would the prohibition against renego still apply? Without any way for > the > > > client to tie the CertificateRequest to the HTTP request that > triggered it, > > > this mechanism would have many of the same problems as renego as far as > > > HTTP/2 is concerned. (I realize Microsoft has a draft floating around > for a > > > TLS_RENEG_PERMITTED HTTP/2 setting. The setting can control this too I > > > suppose.) > > Even if there would be way to tie it to request that triggered the request, > it would still IMO have some of the nastiest problems of renegotiation, > especially in context of HTTP/2 in web (the privilege involved is almost > impossible to handle in any sane way). > > > What I think would be very useful: A way for client to signal it has a > client certificate it expects to use, regardless of if valid configuration > is known. The vast majority of times client certificate is used, the > client knows about that before initiating a connection. > Unless I misunderstand you, this isn't true for a browser. Browsers only look for client certificates based on a CertificateRequest message. Some platforms, like Android, don't even let you list the user's certificate store. Instead there's an API to show a trusted certificate picker prompt. Or, given the paragraph below, are you suggesting that we'd start a second connection on receiving CertificateRequest and only advertise it then? Yeah, that's actually how Chrome implements client auth anyway. We always start a second connection with a client certificate configured, even if the server sent CertificateRequest on a renego. It makes a few things simpler. > IMO, the proper way to handle "this resource requires client certificate" > is for server to signal that in application protocol and then client to > establish a new connection with client certificate (or if application > protocol supports it, do the authentication at application layer without > ever involving TLS, except for channel binding). Certainly. Chrome doesn't implement TLS_RENEG_PERMITTED for HTTP/2, and I don't want to allow this mechanism for it either. I consider renego-based per-resource client auth in HTTP/1.1 to be a legacy mistake we're currently stuck with. (It's the only reason we ever have to renego. In BoringSSL, we've settled on stripping renego down to the bare minimum needed to support this. Simplifies a lot of stuff.) I'm guessing Microsoft has different constraints/goals, given this proposal and TLS_RENEG_PERMITTED, so if we must have it in the transport, I'd rather it be some opt-in corner that I don't have to deal with. (Applications can return HTTP_1_1_REQUIRED in HTTP/2 if they really must do per-resource client auth.) But I do agree this is a problematic mechanism and don't think it belongs in TLS. Let the application layer do it with a channel binding. No need for new connections, and no messy questions about scope and multi-request protocols. David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
> On Tue, Jul 28, 2015 at 6:28 PM David Benjamin wrote: > > > Are you intending that this mechanism be enabled by default for HTTP/2 or > > would the prohibition against renego still apply? Without any way for the > > client to tie the CertificateRequest to the HTTP request that triggered it, > > this mechanism would have many of the same problems as renego as far as > > HTTP/2 is concerned. (I realize Microsoft has a draft floating around for a > > TLS_RENEG_PERMITTED HTTP/2 setting. The setting can control this too I > > suppose.) Even if there would be way to tie it to request that triggered the request, it would still IMO have some of the nastiest problems of renegotiation, especially in context of HTTP/2 in web (the privilege involved is almost impossible to handle in any sane way). What I think would be very useful: A way for client to signal it has a client certificate it expects to use, regardless of if valid configuration is known. The vast majority of times client certificate is used, the client knows about that before initiating a connection. IMO, the proper way to handle "this resource requires client certificate" is for server to signal that in application protocol and then client to establish a new connection with client certificate (or if application protocol supports it, do the authentication at application layer without ever involving TLS, except for channel binding). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
Sent from the right email this time. (Sorry folks who got it twice. One of these days I'll not mess this up! :-) ) On Tue, Jul 28, 2015 at 6:28 PM David Benjamin wrote: > On Fri, Jul 24, 2015 at 1:02 AM Andrei Popov > wrote: > >> Thanks for the detailed comments, Ilari. >> >> Based on the discussion at the TLS WG meeting, I created a pull request: >> https://github.com/tlswg/tls13-spec/pull/209 >> >> > - Mechanism like proposed looks dangerous when combined with HTTP/2. >> I believe the same issue already exists in HTTP/1 where multiple requests >> can be in flight at the same time. >> The way we handle this in HTTP/1 is by having the server application >> query the HTTP stack for the client cred. >> If there's no cred available, the HTTP stack triggers client >> authentication (and the server application waits until the client cred is >> provided so it can authorize the request). >> > > The issue only exists in HTTP/1 if the client does pipelining. As far as I > know, no current[*] major browser deploys HTTP pipelining by default. > Chrome certainly doesn't. > > [*] Wikipedia says Opera used to do it before they switched to Chromium? > > Are you intending that this mechanism be enabled by default for HTTP/2 or > would the prohibition against renego still apply? Without any way for the > client to tie the CertificateRequest to the HTTP request that triggered it, > this mechanism would have many of the same problems as renego as far as > HTTP/2 is concerned. (I realize Microsoft has a draft floating around for a > TLS_RENEG_PERMITTED HTTP/2 setting. The setting can control this too I > suppose.) > > >> > - Regarding last point about interleaving: Assuming the scheme works >> in 1RTT (and I see no reason for requiring more rounds), you can't >> prevent application_data transmission after certificate_request. >> We discussed at the meeting that this restriction cannot be implemented. >> Instead, a server may block the processing of any in-flight requests >> while waiting for the client to authenticate (if the server's architecture >> requires this). >> > > This requires the server buffer arbitrarily many requests from the client, > which seems poor. For renego-based mid-stream auth, I believe Apache httpd > does not do this and will actually fail the connection on interleave. (But > I've never tested this, just glanced at how they use OpenSSL, so I could be > wrong.) > > > - The certificate_types field in CertificateRequest is pretty much >> useless, since all supported algorithms are of signature type. >> If the signature_algorithms extension officially becomes MTI, then >> perhaps we can discus getting rid of certificate_types in the >> CertificateRequest. Except we may want to use this field when we introduce >> new certificate types (e.g. something like IEEE1609 certs). >> >> > - How does extension_values work? If multiple values for one >> OID are allowed, then the OID/value pair is repeated, once for >> each value? >> Multiple values are DER-encoded per RFC that defines the OID that allows >> multiple values. >> The idea here is to simply reuse the existing OID-parsing code. A TLS >> implementation (or certificate API) that recognizes the OID in the cert, >> already knows how to parse its representation. A TLS implementation (or >> certificate API) that does not recognize the OID in the cert will also skip >> this OID in the extension_values. In the degenerate case, an implementation >> may choose to skip all extension_values. >> >> Cheers, >> >> Andrei >> >> -Original Message- >> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara >> Sent: Monday, July 20, 2015 4:11 PM >> To: tls@ietf.org >> Subject: [TLS] Commentary on the client authentication presentation slides >> >> Some commentary on client authentication slides (there is no linked draft >> nor other material yet). >> >> - Mechanism like proposed looks dangerous when combined with HTTP/2. >> Multiplexed protocols are in general not safe to authenticate without >> application-layer signaling (which can be implicit via separate >> connections), especially if dealing with something like web >> environment. >> - Regarding last point about interleaving: Assuming the scheme works >> in 1RTT (and I see no reason for requiring more rounds), you can't >> prevent application_data transmission after certificate_request. >> The best that can be done is to require the client to send all >> the authentication-related data in one go. >> - The certificate_types field in CertificateRequest is pretty much >> useless, since all supported algorithms are of signature type. >> - One can't just remove fields without breaking parse compatiblity, >> but adding field breaks parse compatiblity too, so removing >> field at the same time isn't a problem. >> - How does extension_values work? If multiple values for one >> OID are allowed, then the OID/value pair is repeated, once for >> each value? >> >> >> >> -I
Re: [TLS] Commentary on the client authentication presentation slides
Sound good to me; if the group agrees to remove certificate_types, I'll make this change in the PR. -Original Message- From: Ilari Liusvaara [mailto:ilari.liusva...@elisanet.fi] Sent: Friday, July 24, 2015 8:33 AM To: Andrei Popov Cc: tls@ietf.org Subject: Re: [TLS] Commentary on the client authentication presentation slides On Fri, Jul 24, 2015 at 05:01:37AM +, Andrei Popov wrote: > > > - The certificate_types field in CertificateRequest is pretty much > > useless, since all supported algorithms are of signature type. > If the signature_algorithms extension officially becomes MTI, then > perhaps we can discus getting rid of certificate_types in the > CertificateRequest. Except we may want to use this field when we > introduce new certificate types (e.g. something like IEEE1609 certs). Don't confuse signature_algorithms extension and supported_signature_algorithms field of CertificateRequest. Those two carry similar tasks in opposite directions, except that ssa is REQUIRED with signature certs. There are seemingly no defaults for SSA, so it has to be non-empty for signature certs to work at all. And all present types of TLS 1.3 key exchange can only use signature certs. As for IEEE1609 certs, those are negotiated via certificate format negotiation, which is entierely separate mechanism (described in RFC 7250), not involving CertificateRequest message at all. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
On Fri, Jul 24, 2015 at 05:01:37AM +, Andrei Popov wrote: > > > - The certificate_types field in CertificateRequest is pretty much > > useless, since all supported algorithms are of signature type. > If the signature_algorithms extension officially becomes MTI, then > perhaps we can discus getting rid of certificate_types in the > CertificateRequest. Except we may want to use this field when we > introduce new certificate types (e.g. something like IEEE1609 certs). Don't confuse signature_algorithms extension and supported_signature_algorithms field of CertificateRequest. Those two carry similar tasks in opposite directions, except that ssa is REQUIRED with signature certs. There are seemingly no defaults for SSA, so it has to be non-empty for signature certs to work at all. And all present types of TLS 1.3 key exchange can only use signature certs. As for IEEE1609 certs, those are negotiated via certificate format negotiation, which is entierely separate mechanism (described in RFC 7250), not involving CertificateRequest message at all. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
Thanks for the detailed comments, Ilari. Based on the discussion at the TLS WG meeting, I created a pull request: https://github.com/tlswg/tls13-spec/pull/209 > - Mechanism like proposed looks dangerous when combined with HTTP/2. I believe the same issue already exists in HTTP/1 where multiple requests can be in flight at the same time. The way we handle this in HTTP/1 is by having the server application query the HTTP stack for the client cred. If there's no cred available, the HTTP stack triggers client authentication (and the server application waits until the client cred is provided so it can authorize the request). > - Regarding last point about interleaving: Assuming the scheme works in 1RTT (and I see no reason for requiring more rounds), you can't prevent application_data transmission after certificate_request. We discussed at the meeting that this restriction cannot be implemented. Instead, a server may block the processing of any in-flight requests while waiting for the client to authenticate (if the server's architecture requires this). > - The certificate_types field in CertificateRequest is pretty much useless, since all supported algorithms are of signature type. If the signature_algorithms extension officially becomes MTI, then perhaps we can discus getting rid of certificate_types in the CertificateRequest. Except we may want to use this field when we introduce new certificate types (e.g. something like IEEE1609 certs). > - How does extension_values work? If multiple values for one OID are allowed, then the OID/value pair is repeated, once for each value? Multiple values are DER-encoded per RFC that defines the OID that allows multiple values. The idea here is to simply reuse the existing OID-parsing code. A TLS implementation (or certificate API) that recognizes the OID in the cert, already knows how to parse its representation. A TLS implementation (or certificate API) that does not recognize the OID in the cert will also skip this OID in the extension_values. In the degenerate case, an implementation may choose to skip all extension_values. Cheers, Andrei -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara Sent: Monday, July 20, 2015 4:11 PM To: tls@ietf.org Subject: [TLS] Commentary on the client authentication presentation slides Some commentary on client authentication slides (there is no linked draft nor other material yet). - Mechanism like proposed looks dangerous when combined with HTTP/2. Multiplexed protocols are in general not safe to authenticate without application-layer signaling (which can be implicit via separate connections), especially if dealing with something like web environment. - Regarding last point about interleaving: Assuming the scheme works in 1RTT (and I see no reason for requiring more rounds), you can't prevent application_data transmission after certificate_request. The best that can be done is to require the client to send all the authentication-related data in one go. - The certificate_types field in CertificateRequest is pretty much useless, since all supported algorithms are of signature type. - One can't just remove fields without breaking parse compatiblity, but adding field breaks parse compatiblity too, so removing field at the same time isn't a problem. - How does extension_values work? If multiple values for one OID are allowed, then the OID/value pair is repeated, once for each value? -Ilari ___ 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
