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

From: Mike Bishop <[email-masked]>
Date: Tue, 26 Jan 2016 20:23:00 +0000

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 26 Jan 2016 23:38:13 +0200

On Tue, Jan 26, 2016 at 08:23:00PM +0000, Mike Bishop wrote:
> 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!

Some quick comments (some less sensible, some more sensible):

- Needs to require EMS or TLS 1.3. Any use of TLS-EXPORTER for auth on
  connections vulernable to THS is no-no.
- What does "future streams associated with this request" mean exactly.
  Covering a stream client did not intend to is no-no.
- How does client revoke AUTOMATIC_USE on some certificate (or all
  certificates) in sequentially consistent way? For the same reasons
  as previous.
- Why 1024 byte exporter output? That seems excessively large. 64
  bytes is already 512 bits, which is high even if actual security
  is cut in half somehow.
- There are all sorts of crappy TLS HashAndSignatureAlgorithm values
  that need forbidding, like DSA or ones using MD5 or SHA1.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Jan 2016 09:04:09 +1100

Thanks for the prompt feedback Ilari,

>   connections vulernable to THS is no-no.

Yes, absolutely.

>   Covering a stream client did not intend to is no-no.

Context?

>   certificates) in sequentially consistent way? For the same reasons

GOAWAY & close.  Note that you might be better off asking for the
removal of AUTOMATIC_USE if this is a concern you have.  Also note
that you are asking for a level of control that the server doesn't
get.

>   bytes is already 512 bits, which is high even if actual security

Hmm, yes, 64 bytes is plenty.

>   that need forbidding, like DSA or ones using MD5 or SHA1.

Good point.  We should limit this to DSA with SHA1.

---

From: Mike Bishop <[email-masked]>
Date: Wed, 27 Jan 2016 00:00:36 +0000

I believe the other comment is also around AUTOMATIC_USE, since both occurrences of "future streams" are in that context.  Basically, it means any future stream on which the server would have made the same request, the server can just use the provided cert and not burn an RTT asking.

Yes, the client loses visibility into whether the cert has been used, and loses the ability to *not* use the cert if it chooses.  That's a trade-off the client can make -- if it wants to retain those capabilities (at the expense of 1 RTT per request), it just doesn't set AUTOMATIC_USE.

The client makes the call -- and as Martin points out, it's state-changing for the connection.  Once you AUTOMATIC_USE a certificate, the server MAY apply it to any future request you make on the connection.  If you change your mind later, new connection (and presumably GOAWAY the old one).

As to requiring EMS, reducing exporter, and appropriate HashAndSignature algorithms, I'll defer to those with more expertise in TLS-land.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Tuesday, January 26, 2016 2:04 PM
To: Ilari Liusvaara <[email-masked]>
Cc: Mike Bishop <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: FW: New Version Notification for draft-thomson-http2-client-certs-01.txt

Yes, absolutely.

Context?

>   certificates) in sequentially consistent way? For the same reasons

GOAWAY & close.  Note that you might be better off asking for the removal of AUTOMATIC_USE if this is a concern you have.  Also note that you are asking for a level of control that the server doesn't get.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 27 Jan 2016 10:47:59 +0200

On Wed, Jan 27, 2016 at 12:00:36AM +0000, Mike Bishop wrote:
> I believe the other comment is also around AUTOMATIC_USE, since both
> occurrences of "future streams" are in that context.  Basically, it
> means any future stream on which the server would have made the same
> request, the server can just use the provided cert and not burn an RTT
> asking.

And requests where that cert is inapporiate MUST NOT made on that
connection.

Also, can it apply to streams that are none of:
1) The stream AUTOMATIC_USE is sent on
2) Stream in IDLE.
3) Stream in PUSH_PROMISE

At the time AUTOMATIC_USE is sent?

If yes, that would be a nasty surprise...

> Yes, the client loses visibility into whether the cert has been used,
> and loses the ability to *not* use the cert if it chooses.  That's a
> trade-off the client can make -- if it wants to retain those
> capabilities (at the expense of 1 RTT per request), it just doesn't
> set AUTOMATIC_USE.

I don't think server chosing to ignore cert is a problem, as it is
equivalent to cert just provoding no privilege at all. But using a
cert that should not be used is a *serious* security problem in
presence of more than 2 parties (like in Web (but Web is far from being
the only place where security problems happen)).

> The client makes the call -- and as Martin points out, it's
> state-changing for the connection.  Once you AUTOMATIC_USE a certificate,
> the server MAY apply it to any future request you make on the connection.
> If you change your mind later, new connection (and presumably GOAWAY the
> old one).

Actually, in many cases where one would want to revoke certificate use,
the old connection is not GOAWAY'd as it still might be useful.

> As to requiring EMS, 

Basically, if you don't require EMS, maliscous server can hijack
autenticated connection and misuse the certificates. HTTP/2 TLS use
guidelines don't even come close to being able to prevent attacks
like this.

> reducing exporter, and appropriate HashAndSignature
> algorithms, I'll defer to those with more expertise in TLS-land.

Basically, I favor dropping insecure or excessively weak algorithms
from new specifications or versions, even at severe cost to deploy-
ability. We have gotten burned *far* too many times from not doing that,
and *will* get burned in future if we continue allowing those.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Jan 2016 04:41:34 +1100

> and *will* get burned in future if we continue allowing those.

I'm always happy to use support for a new feature as a signal that
it's safe to ratchet the security knob one step further.  Let's just
make sure that we have good justification.  EMS and reduced signature
algorithms is a fine suggestion here because they have a material
impact on the properties we are looking to gain.

If you want to suggest anything else, I'm open to it, but I think we
need at least a little justification.

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 28 Jan 2016 06:31:57 +0900

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 <[email-masked]>:
> 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!
>
>
>
> ·         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.
>
>
>
> 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:
>
> 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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 27 Jan 2016 22:02:45 +0000

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:[email-masked]] 
Sent: Wednesday, January 27, 2016 1:32 PM
To: Mike Bishop <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
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.

```

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 <[email-masked]>:
> 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:
>
> 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.
>
> 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
> 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:
>
> 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.)
>
> 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.
>
>
>
> 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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 27 Jan 2016 23:01:13 +0000

Require EMS:  https://github.com/MikeBishop/http2-client-certs/commit/dfa59df62aec64044a407b0e8f67704e8eb91981
Smaller export:  https://github.com/MikeBishop/http2-client-certs/commit/3880e6069480523fcdfa6130fd28bc26ff6ebe9f
Cautions on AUTOMATIC_USE:  https://github.com/MikeBishop/http2-client-certs/commit/f1479486149e3d815662358d60d7be0bd877952c

I'm not doing the signature/hash changes quite yet, because I'm not sure what we want to restrict.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, January 27, 2016 12:48 AM
To: Mike Bishop <[email-masked]>
Cc: Martin Thomson <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: FW: New Version Notification for draft-thomson-http2-client-certs-01.txt

> request, the server can just use the provided cert and not burn an RTT 

And requests where that cert is inapporiate MUST NOT made on that connection.

> capabilities (at the expense of 1 RTT per request), it just doesn't 

I don't think server chosing to ignore cert is a problem, as it is equivalent to cert just provoding no privilege at all. But using a cert that should not be used is a *serious* security problem in presence of more than 2 parties (like in Web (but Web is far from being the only place where security problems happen)).

> state-changing for the connection.  Once you AUTOMATIC_USE a 
> certificate, the server MAY apply it to any future request you make on the connection.
> If you change your mind later, new connection (and presumably GOAWAY 
> the old one).

Actually, in many cases where one would want to revoke certificate use, the old connection is not GOAWAY'd as it still might be useful.

> As to requiring EMS,

Basically, if you don't require EMS, maliscous server can hijack autenticated connection and misuse the certificates. HTTP/2 TLS use guidelines don't even come close to being able to prevent attacks like this.

> reducing exporter, and appropriate HashAndSignature algorithms, I'll 
> defer to those with more expertise in TLS-land.

Basically, I favor dropping insecure or excessively weak algorithms from new specifications or versions, even at severe cost to deploy- ability. We have gotten burned *far* too many times from not doing that, and *will* get burned in future if we continue allowing those.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Jan 2016 12:01:51 +1100

GIthub is unicorny again [1], so I'm going to dump this into email for
later action.

This should say that only the signature algorithms supported in the
negotiated version of TLS can be used.  Plus the following MUST NOT be
used:
 - MD5
 - SHA1
 - SHA224
 - DSA
 - ECDSA with curves on prime fields that are less than 240 bits wide
 - RSA with a prime modulus less than 2048 bits

I think that's about as aggressive without starting to prohibit some
things that are in common use.  Would that work for you Ilari?

[1] translation: argh, my Internet is down again

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 28 Jan 2016 10:21:52 +0900

Thank you for the response.

> 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…

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.

-- 
Kazuho Oku

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Jan 2016 13:31:54 +1100

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.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 28 Jan 2016 09:29:48 +0200

> things that are in common use.  Would that work for you Ilari?

Sure, seems reasonable.

-Ilari

---

From: Mike Bishop <[email-masked]>
Date: Thu, 28 Jan 2016 17:56:43 +0000

Yes, doing a separate CERTIFICATE frame for each cert in a chain is also reasonable -- the overhead isn't terribly high, and it does simplify processing.  Once you have to allow multiple frames to hold a chain anyway, that may be a better form to take.

Do we have data on how commonly certificates are greater than 16KB in size?  I see we (Microsoft) had a bug that occurred when the Certificate *Store* got bigger than 16KB, so that's certainly an argument that individual certificates shouldn't be that big in the expected case.  But then, we said that about headers, too.  :-)  I also don't know how many people are turning down to the minimum frame size; is there a reason to impose the minimum maximum frame size, rather than the actual maximum frame size?

Even with the current wording, I'm not expecting the server to actually do anything -- it's just a mechanism to convey information the server might want to log.  This isn't a "please increase your maximum frame size to X and ask me again" message -- though if a server wanted to implement that, it would permit it.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Wednesday, January 27, 2016 6:32 PM
To: Kazuho Oku <[email-masked]>
Cc: Mike Bishop <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: FW: New Version Notification for draft-thomson-http2-client-certs-01.txt

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 <[email-masked]> wrote:
>>> 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
>>> 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:
>>>
>>> the same request.  (You can refuse to link the cert back, though, 
>>> and hope the server sends a fresh request, though.)
>>>
>>> https://www.ietf.org/internet-drafts/draft-thomson-http2-client-cert
>>> s-
>>> 01.txt
>>>
>>> Status:

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Jan 2016 09:02:25 +1100

On 29 January 2016 at 04:56, Mike Bishop <[email-masked]> wrote:
> Do we have data on how commonly certificates are greater than 16KB in size?

I suppose that someone could check the CT log, but that is server
certs only, so it might be a poor data source for client certs.

I'm inclined to take the bloody minded approach here and wait until
someone complains.  16k is a pretty big cert.

And before someone brings up post-quantum crypto and 8M McEliece keys,
I think that public key sizes need to be much smaller than 16k if
that's going to be deployed.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 28 Jan 2016 23:31:16 +0000

https://github.com/MikeBishop/http2-client-certs/commit/2315bd353bfe8aa123838b873205c6675fa60633

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Thursday, January 28, 2016 2:02 PM
To: Mike Bishop <[email-masked]>
Cc: Kazuho Oku <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: FW: New Version Notification for draft-thomson-http2-client-certs-01.txt

> Do we have data on how commonly certificates are greater than 16KB in size?

I suppose that someone could check the CT log, but that is server certs only, so it might be a poor data source for client certs.

I'm inclined to take the bloody minded approach here and wait until someone complains.  16k is a pretty big cert.

And before someone brings up post-quantum crypto and 8M McEliece keys, I think that public key sizes need to be much smaller than 16k if that's going to be deployed.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 28 Jan 2016 23:31:31 +0000

https://github.com/MikeBishop/http2-client-certs/commit/33262d527e88948a9fb3b9f10cbb2988c4cc50dc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, January 27, 2016 11:30 PM
To: Martin Thomson <[email-masked]>
Cc: Mike Bishop <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: FW: New Version Notification for draft-thomson-http2-client-certs-01.txt

Sure, seems reasonable.

-Ilari

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 29 Jan 2016 16:56:33 +1300

> https://github.com/MikeBishop/http2-client-certs/commit/2315bd353bfe8aa123838b873205c6675fa60633

+1. That looks good to me.

Amos