RE: FW: New Version Notification for draft-thomson-http2-client-certs-01.txt

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.

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

Received on Wednesday, 27 January 2016 22:03:15 UTC