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

[Mike Bishop <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
Sent: Friday, January 22, 2016 2:23 PM
To: Martin Thomson <[e-mail]>; Mike Bishop <[e-mail]>
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