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 21:32:27 UTC