- From: Kazuho Oku <kazuhooku@gmail.com>
- Date: Wed, 15 Nov 2017 00:20:58 +0800
- To: Mike Bishop <mbishop@evequefou.be>
- Cc: Nick Sullivan <nicholas.sullivan@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CANatvzy55RkT4ThKODOUh2e-AK_hMGV5UPw41885Ag6L8pAnHg@mail.gmail.com>
Hi Mike, 2017-11-14 23:16 GMT+08:00 Mike Bishop <mbishop@evequefou.be>: > What the draft currently says about that is: > > Client implementations need to carefully consider the impact of setting > the AUTOMATIC_USE flag. This flag is a performance optimization, permitting > the client to avoid a round-trip on each request where the server checks > for certificate authentication. However, once this flag has been sent, the > client has zero knowledge about whether the server will use the referenced > cert for any future request, or even for an existing request which has not > yet completed. Clients MUST NOT set this flag on any certificate which is > not appropriate for currently-in-flight requests, and MUST NOT make any > future requests on the same connection which they are not willing to have > associated with the provided certificate. > > > > So basically, if a client provides a certificate to example.com with > AUTOMATIC_USE set, then later decides that it doesn’t want to use that > certificate with example.org, then it MUST NOT send example.org requests > on that connection and would need to start a fresh one. > Thank you for pointing that out. I remember reading the section, but it's obvious I missed the intent of the text. I think that you’re right that negotiation isn’t needed if the client is > allowed to preemptively send USE_CERTIFICATE with every request. That > introduces a race condition where confusion could ensue about whether the > USE_CERTIFICATE was preemptive or in response to a CERTIFICATE_NEEDED. > However, that seems solvable if we specify timing rules. A strawman: > > - Eliminate AUTOMATIC_USE – the semantics are always true for servers > and never true for clients > - Clients which have previously been challenged for and provided a > certificate MAY send USE_CERTIFICATE as part of their subsequent or > still-open requests > - Servers MUST NOT send CERTIFICATE_REQUIRED before seeing a complete > request > - If the request included a USE_CERTIFICATE frame, the server MUST > NOT send CERTIFICATE_REQUIRED, but MAY reset the stream with a > NOT_WHAT_I_WANTED error code (better name TBD). > - Upon receipt of a NOT_WHAT_I_WANTED error, clients SHOULD > resend the request without a USE_CERTIFICATE frame and expect a > CERTIFICATE_REQUIRED frame > - If not, it MAY send a CERTIFICATE_REQUIRED if a certificate is > required. > > The strawman looks good to me. Thank you for writing them down. I like the fact that the approach is simpler than the current one, and that the round-trips required to perform the requests have been minimized in all cases. I have only one comment. You might want to adjust the timing so that we could cap the amount of memory need to buffer a pending request (note that in case of CGI, properties of the client certificate needs to be sent to the application before the request body. Also I would assume that such requirement exists for other gateway protocols). One way to implement such cap would be to change the timing requirement as follows: * a client that associates a client certificate to a request MUST send USE_CERTIFICATE frame prior to sending a DATA frame * otherwise, a client should send the USE_CERTIFICATE frame only in response to a CERTIFICATE_REQUIRED frame > > Something else that should have occurred to me long ago, but hit me while > writing the above: USE_CERTIFICATE will necessarily be sendable on a > half-closed stream. That’s possible in HTTP/2, but problematic in > HTTP/QUIC. We’ll have to think about that. > > > > -----Original Message----- > From: Kazuho Oku [mailto:kazuhooku@gmail.com] > Sent: Tuesday, November 14, 2017 2:24 PM > To: Nick Sullivan <nicholas.sullivan@gmail.com> > Cc: Mike Bishop <mbishop@evequefou.be>; HTTP Working Group < > ietf-http-wg@w3.org> > Subject: Re: FW: New Version Notification for draft-bishop-httpbis-http2- > additional-certs-05.txt > > > > Hi Nick, Ilari, Mike, > > > > Thank you for your responses. > > > > First, let me argue that there is no need to negotiate AUTOMATIC_USE. > > Current draft permits the server to let the client choose a certificate > even in case AUTOMATIC_USE is being used. So it is possible to cover the > CGI use case under the current draft, though the need to spend 2 RTT makes > me bit sad (especially since I do not understand the benefit of letting the > server choose the certificate). > > > > That said, let me elaborate about another issue related to AUTOMATIC_USE; > a potential privacy concern. > > > > Consider the case of a CDN terminating example.com and example.org. > > Both of the hosts require authentication using client certificates issued > by the same CA. > > > > At first, a client connects to the CDN sending a request to example.com, > and sends its client certificate with AUTOMATIC_USE flag set. > > > > Then, using the same connection, a client sends a request to example.org. > At this point, is the CDN allowed to present the certificate that was sent > for example.com to example.org? My understanding is that in HTTP/1, a > user has the total control of choosing the certificate the person wants to > send to each domain. > > > > So to me, it seems that we would be required to standardize when a > certificate sent with AUTOMATIC_USE flag set can be reused across the > authorities that are coalesced into a single connection, if we are to > enable automatic reuse (please let me know if that’s already specified; I > may have missed that). > > > > One way to avoid the issue is to drop AUTOMATIC_USE from the > specification, and require the client to specify the certificate that is > associated to every request. > > > > If we take that route, we would no longer be required to seek an agreement > and document when an intermediary can reuse a client certificate across > authorities. Elimination of AUTOMATIC_USE would give the clients total > control on how certificates are associated to the requests they send, and > the added bonus would be that the behavior could be verified by consulting > the client behavior. > > > > 2017-11-13 17:29 GMT+08:00 Nick Sullivan <nicholas.sullivan@gmail.com>: > > > Hi Kazuho, > > > > > > Thanks for this. I think you found an issue that we did not consider: > > > the fact that server support for setting AUTOMATIC_USE in client > > > certificates may not be desirable for all servers. The CGI case you > > > describe would work find as long as the client doesn't use AUTOMATIC_USE. > > > > > > Here's a possible solution to this: > > > Let the server advertise support for AUTOMATIC_USE in the > > > CERTIFICATE_REQUEST message as a flag. If the client receives a > > > CERTIFICATE_REQUEST without AUTOMATIC_USE set, then it should not be > > > able to reply with a CERTIFICATE with AUTOMATIC_USE set. > > > > > > Nick > > > > > > On Mon, Nov 13, 2017 at 3:18 PM Kazuho Oku <kazuhooku@gmail.com> wrote: > > >> > > >> Hi, Mike, Nick, Martin, > > >> > > >> I have briefly asked this in the IETF meeting, but let me question if > > >> it sounds logical to adjust the approach so that the client will be > > >> required to proactively specify the certificate that is associated to > > >> each HTTP request. > > >> > > >> I ask this due to the following reason. > > >> > > >> In HTTP/1, it was always clear from the server’s viewpoint which > > >> certificate is associated to a HTTP request. This is because the > > >> underlying connection allowed only one client certificate at maximum > > >> to be used. CGI is designed after that model. A CGI gateway is > > >> expected to designate _at most one_ certificate that has been > > >> associated to the request by using a set of environment variables > > >> (e.g., `SSL_CLIENT_S_DN` [1]). I would assume that it is the same for > > >> other de-facto standards that have evolved from CGI (e.g., FastCGI, > > >> Rack). > > >> > > >> The secondary certificates draft changes the model. Under the model > > >> proposed by the draft, the server is expected to choose from one of > > >> the certificates that it has received with AUTOMATIC_USE flag set, or > > >> to request the client to send a new certificate. > > >> > > >> However, to me (as a HTTP server developer that acts as a CGI > > >> gateway) it is unclear how a server can make such choice. > > >> Applications that are run using the CGI protocol _might_ have > > >> sufficient information to make such choice, but that is not the case > for a CGI gateway. > > >> > > >> That means that unless the draft (in the following revisions) specify > > >> the guess logic that I should implement, I would be forced into > > >> sending CERTIFICATE_NEEDED for every HTTP request I receive. Doing so > > >> would introduce one extra roundtrip. > > >> > > >> Considering that, I wonder if you could adjust the approach proposed > > >> in the draft to require the client to proactively clarify the > > >> certificate that is associated to each HTTP request. > > >> > > >> For example, I believe that the draft could specify that: > > >> * If the client does not specify a certificate that is associated to > > >> a request, a server MAY request the client to specify the certificate. > > >> * The client can specify the certificate that is associated to a > > >> request proactively, instead of sending USE_CERTIFICATE frame in > > >> response to a CERTIFICATE_NEEDED frame. > > >> > > >> By changing the approach as such, the only case in which two > > >> roundtrips are required for processing a request could become when > > >> the client is required to send a new certificate. Also, AUTOMATIC_USE > > >> flag becomes unnecessary. > > >> > > >> One downside caused by such change is that the bandwidth slightly > > >> increases due to the fact that the client would be required to > > >> specify the certificate that is associated to every HTTP request. > > >> However that is just sending Cert-ID per every HTTP request; I > > >> believe that the increase of bandwidth is negligible. > > >> > > >> To summarize, I am suggesting to push the responsibility of choosing > > >> the certificate back to the client. Note that in the current draft > > >> the client is still required to make such choice if the server sends > > >> a CERTIFICATE_NEEDED frame; so I think requiring the client to > > >> _always_ make the choice does not increase the complexity on the client > side. > > >> > > >> [1] https://httpd.apache.org/docs/2.4/mod/mod_ssl.html > > >> > > >> 2017-10-31 8:14 GMT+08:00 Mike Bishop <mbishop@evequefou.be>: > > >> > In preparation for Singapore, we've updated the Additional Certs > > >> > draft to track changes in TLS 1.3 and the Exported Authenticators TLS > draft. > > >> > There's been substantial interest here, and we'll be discussing the > > >> > draft during the WG meeting. > > >> > > > >> > -----Original Message----- > > >> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org > <internet-drafts@ietf.org>] > > >> > Sent: Monday, October 30, 2017 2:40 PM > > >> > To: Martin Thomson <martin.thomson@gmail.com>; Mike Bishop > > >> > <mbishop@evequefou.be>; Nick Sullivan <nick@cloudflare.com> > > >> > Subject: New Version Notification for > > >> > draft-bishop-httpbis-http2-additional-certs-05.txt > > >> > > > >> > > > >> > A new version of I-D, > > >> > draft-bishop-httpbis-http2-additional-certs-05.txt > > >> > has been successfully submitted by Mike Bishop and posted to the > > >> > IETF repository. > > >> > > > >> > Name: draft-bishop-httpbis-http2-additional-certs > > >> > Revision: 05 > > >> > Title: Secondary Certificate Authentication in HTTP/2 > > >> > Document date: 2017-10-30 > > >> > Group: Individual Submission > > >> > Pages: 21 > > >> > URL: > > >> > https://www.ietf.org/internet-drafts/draft-bishop-httpbis-http2-add > > >> > itional-certs-05.txt > > >> > Status: > > >> > https://datatracker.ietf.org/doc/draft-bishop-httpbis-http2-additio > > >> > nal-certs/ > > >> > Htmlized: > > >> > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-c > > >> > erts-05 > > >> > Htmlized: > > >> > https://datatracker.ietf.org/doc/html/draft-bishop-httpbis-http2-ad > > >> > ditional-certs-05 > > >> > Diff: > > >> > https://www.ietf.org/rfcdiff?url2=draft-bishop-httpbis-http2-additi > > >> > onal-certs-05 > > >> > > > >> > Abstract: > > >> > TLS provides fundamental mutual authentication services for HTTP, > > >> > supporting up to one server certificate and up to one client > > >> > certificate associated to the session to prove client and server > > >> > identities as necessary. This draft provides mechanisms for > > >> > providing additional such certificates at the HTTP layer when these > > >> > constraints are not sufficient. > > >> > > > >> > Many HTTP servers host content from several origins. HTTP/2 > > >> > [RFC7540] permits clients to reuse an existing HTTP connection to a > > >> > server provided that the secondary origin is also in the certificate > > >> > provided during the TLS [I-D.ietf-tls-tls13] handshake. > > >> > > > >> > In many cases, servers will wish to maintain separate certificates > > >> > for different origins but still desire the benefits of a shared HTTP > > >> > connection. Similarly, servers may require clients to present > > >> > authentication, but have different requirements based on the content > > >> > the client is attempting to access. > > >> > > > >> > This document describes how TLS exported authenticators > > >> > [I-D.ietf-tls-exported-authenticator] can be used to provide proof > of > > >> > ownership of additional certificates to the HTTP layer to support > > >> > both scenarios. > > >> > > > >> > > > >> > > > >> > > > >> > Please note that it may take a couple of minutes from the time of > > >> > submission until the htmlized version and diff are available at > > >> > tools.ietf.org. > > >> > > > >> > The IETF Secretariat > > >> > > > >> > > > >> > > >> > > >> > > >> -- > > >> Kazuho Oku > > >> > > > > > > > > > > > -- > > Kazuho Oku > -- Kazuho Oku
Received on Tuesday, 14 November 2017 16:21:24 UTC