- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 28 Jan 2016 13:31:54 +1100
- To: Kazuho Oku <kazuhooku@gmail.com>
- Cc: Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
We could test to see whether a split is necessary. Or, we can say that this protocol doesn't support certificates that are larger than 16k in size (the minimum for the setting). I think that I prefer the latter. If we do decide to allow splitting, then continuations aren't necessary. We can allow interleaving of other frames. It's not like we have some precious state to maintain between each portion. As I think more about this, I also think that we could do away with Cert-Count. The CERTIFICATE_PROOF frame is a fine terminator for a given request. We could provision a setting that advertises a limit on certificate size, but I don't see much gain in return for the incremental complexity. The same goes for the number of certificates. I suspect that for client authentication we will see 1 or maybe 2 certificates in the majority of cases. Servers can just ignore excess certificates. On 28 January 2016 at 12:21, Kazuho Oku <kazuhooku@gmail.com> wrote: > Thank you for the response. > > 2016-01-28 7:02 GMT+09:00 Mike Bishop <Michael.Bishop@microsoft.com>: >> I considered having a CERTIFICATE_CONTINUATION frame or something like that, but given the large number of frames we were already creating (and the general hatred for CONTINUATION frames during H2 standardization) I didn't want to create that myself. If others support it, I'm happy to add it. >> >> For that matter, we could do that instead of having multiple CERTIFICATE frames with disjoint certs -- just send as many CERTIFICATE frames as needed to hold the serialized chain and break wherever needed. (Maybe SHOULD break on a cert boundary if possible?) You don't really need an END_CERTIFICATE flag, since the CERTIFICATE_PROOF tells you it was the last one. > > Agreed. > > In your response, I see two aspects being discussed: a) whether if it > should be allowed to convey more than one certificate in one frame, > and b) whether if it should be allowed to splitting a certificate (or > certificates) into multiple frames. > > My concern was about b, but regarding a, I personally believe it would > be better _not_ to allow storing multiple certificates in a single > frame. > > By changing the definition of a CERTIFICATE frame to contain only one > certificate (or portion of it), you would no longer need to convey the > number of certificates (i.e. Cert-Count) within each CERTIFICATE > frame, or define the structure to hold multiple certificates. Entire > payload of the frame can be used to store a single certificate (or > portion of it), thereby eliminating the need to specify the length of > the certificate within the frame payload. You could either use a > dedicated frame ID or define a flag to indicate a certificate split > into multiple frames. > > The downside would be that the bandwidth required for sending multiple > certificates becomes slightly larger (possibly 4-bytes per > certificate), but I wouldn't expect that to be a big issue. > > To be honest I wouldn't care how the certificates would be conveyed if > the requirement to support expanding maximum frame size gets removed; > but could not resist to discuss about potential optimizations. > >> I personally think the risk of having a single certificate this large is fairly remote, but it's certainly possible, and moreso if the server has turned down the default maximum frame size. >> >> -----Original Message----- >> From: Kazuho Oku [mailto:kazuhooku@gmail.com] >> Sent: Wednesday, January 27, 2016 1:32 PM >> To: Mike Bishop <Michael.Bishop@microsoft.com> >> Cc: HTTP Working Group <ietf-http-wg@w3.org> >> Subject: Re: FW: New Version Notification for draft-thomson-http2-client-certs-01.txt >> >> Thank you for the draft. >> >> It would be great to see the use of client certificates supported in HTTP/2, and as a server-side implementor of HTTP/2 protocol, I think the draft can be implemented fairly straightforward. >> >> The only concern I have now regarding the draft is the following paragraph in section 2.4. >> >> ``` >> Particularly when a certificate contains a large number of Subject >> Alternative Names, it might not fit into a single "CERTIFICATE" frame >> even as the only provided certificate. Senders unable to transfer a >> requested certificate due to the recipient's >> "SETTINGS_MAX_FRAME_SIZE" value SHOULD increase their own >> "SETTINGS_MAX_FRAME_SIZE" to a size that would accomodate their >> certificate, then terminate affected streams with >> "CERTIFICATE_TOO_LARGE". >> ``` >> >> Is there any possibility that this restriction gets eliminated, for example by allowing a certificate to be split into multiple frames (much like the way we do with DATA frames using the END_STREAM flag)? >> >> IMO, buffering a portion of a certificate until the following frames arrive would be much easier than communicating to increase the maximum frame size, especially considering the fact that the draft already requires the server to preserve the provided certificates until it receives the CERTIFICATE_PROOF frame. >> >> FWIW, in case of H2O, the maximum frame size is a hard-coded value, and I believe other servers might be doing the same; having the value being fixed opens up possibilities for optimizations. >> >> 2016-01-27 5:23 GMT+09:00 Mike Bishop <Michael.Bishop@microsoft.com>: >>> Based on feedback from this WG in Yokohama and on-list feedback from >>> the TLS WG, Martin and I have a new (largely rewritten) version of the >>> client cert draft. As I promised Mark, people will hate it, but they >>> will at least hate it in different ways than the previous version! >>> >>> >>> >>> You can read the draft for the details, but here are the two >>> high-level ideas that drove this version: >>> >>> · TLS 1.2 doesn't prohibit continuing to pass application data >>> during a renegotiation, but nearly every implementation has that >>> restriction and doesn’t intend to change it. For a multiplexed >>> protocol like HTTP/2, that’s not a good thing, and deploying >>> fundamental changes to all TLS 1.2 implementations is on par with just making everyone upgrade to TLS 1.3. >>> >>> · We discussed in Yokohama why it’s not feasible to transparently >>> replace cert auth with something at the HTTP semantic layer. But the >>> HTTP/2 framing layer has no such restriction. >>> >>> >>> >>> This draft replicates the TLS 1.3 messages in HTTP/2 frames on stream >>> zero instead – CertificateRequest (a CERTIFICATE_REQUEST frame), >>> Certificate (one or more CERTIFICATE frames), and CertificateVerify (a >>> CERTIFICATE_PROOF frame). Because these are shared context in the >>> session and need to be tied back to the streams, two more frames >>> (CERTIFICATE_REQUIRED and >>> USE_CERTIFICATE) exist to provide that stream-to-request link on each side. >>> It’s more frames than we wanted and we’ve argued them in circles, but >>> each provides a useful property that we ultimately didn’t want to give >>> up. The result provides client certificate authentication for HTTP/2 >>> regardless of the underlying TLS version (but does still require TLS). >>> >>> >>> >>> In the current form, it maintains a couple of TLS 1.3 properties that >>> may or may not be desirable, and we’re looking for feedback on those especially: >>> >>> · One CertificateRequest gets one Certificate (with chain) back, >>> even if tied to multiple streams. You can’t “split” a request and >>> send different certs for different streams on which the server made >>> the same request. (You can refuse to link the cert back, though, and >>> hope the server sends a fresh request, though.) >>> >>> · Martin says the TLS WG has agreed to remove spontaneous client >>> authentication from TLS 1.3, so this draft doesn’t allow for the >>> client to send a certificate the server hasn’t asked for yet. >>> >>> >>> >>> With that as preface, it’s open for discussion! >>> >>> >>> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Friday, January 22, 2016 2:23 PM >>> To: Martin Thomson <martin.thomson@gmail.com>; Mike Bishop >>> <Michael.Bishop@microsoft.com> >>> Subject: New Version Notification for >>> draft-thomson-http2-client-certs-01.txt >>> >>> >>> >>> >>> >>> A new version of I-D, draft-thomson-http2-client-certs-01.txt >>> >>> has been successfully submitted by Mike Bishop and posted to the IETF >>> repository. >>> >>> >>> >>> Name: draft-thomson-http2-client-certs >>> >>> Revision: 01 >>> >>> Title: Reactive Certificate-Based Client Authentication >>> in HTTP/2 >>> >>> Document date: 2016-01-22 >>> >>> Group: Individual Submission >>> >>> Pages: 19 >>> >>> URL: >>> https://www.ietf.org/internet-drafts/draft-thomson-http2-client-certs- >>> 01.txt >>> >>> Status: >>> https://datatracker.ietf.org/doc/draft-thomson-http2-client-certs/ >>> >>> Htmlized: >>> https://tools.ietf.org/html/draft-thomson-http2-client-certs-01 >>> >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-thomson-http2-client-certs-01 >>> >>> >>> >>> Abstract: >>> >>> Some HTTP servers provide a subset of resources that require >>> >>> additional authentication to interact with. HTTP/1.1 servers rely >>> on >>> >>> TLS renegotiation that is triggered by a request to a protected >>> >>> resource. HTTP/2 made this pattern impossible by forbidding the >>> use >>> >>> of TLS renegotiation. While TLS 1.3 provides an alternate >>> mechanism >>> >>> to obtain client certificates, this mechanism does not map well to >>> >>> usage in TLS 1.2. >>> >>> >>> >>> This document describes a how client authentication might be >>> >>> requested by a server as a result of receiving a request to a >>> >>> protected resource. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 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 >
Received on Thursday, 28 January 2016 02:32:23 UTC