Subject: Re: FW: New Version Notification for draft-bishop-httpbis-http2-additional-certs-05.txt

From: Kazuho Oku <[email-masked]>
Date: Mon, 13 Nov 2017 15:09:30 +0800

Hi, Mike, Nick, Martin,

I have briefly asked this in the IETF meeting, but let me question if
it sounds logical to adjust the approach so that the client will be
required to proactively specify the certificate that is associated to
each HTTP request.

I ask this due to the following reason.

In HTTP/1, it was always clear from the server’s viewpoint which
certificate is associated to a HTTP request. This is because the
underlying connection allowed only one client certificate at maximum
to be used. CGI is designed after that model. A CGI gateway is
expected to designate _at most one_ certificate that has been
associated to the request by using a set of environment variables
(e.g., `SSL_CLIENT_S_DN` [1]). I would assume that it is the same for
other de-facto standards that have evolved from CGI (e.g., FastCGI,
Rack).

The secondary certificates draft changes the model. Under the model
proposed by the draft, the server is expected to choose from one of
the certificates that it has received with AUTOMATIC_USE flag set, or
to request the client to send a new certificate.

However, to me (as a HTTP server developer that acts as a CGI gateway)
it is unclear how a server can make such choice. Applications that are
run using the CGI protocol _might_ have sufficient information to make
such choice, but that is not the case for a CGI gateway.

That means that unless the draft (in the following revisions) specify
the guess logic that I should implement, I would be forced into
sending CERTIFICATE_NEEDED for every HTTP request I receive. Doing so
would introduce one extra roundtrip.

Considering that, I wonder if you could adjust the approach proposed
in the draft to require the client to proactively clarify the
certificate that is associated to each HTTP request.

For example, I believe that the draft could specify that:
* If the client does not specify a certificate that is associated to a
request, a server MAY request the client to specify the certificate.
* The client can specify the certificate that is associated to a
request proactively, instead of sending USE_CERTIFICATE frame in
response to a CERTIFICATE_NEEDED frame.

By changing the approach as such, the only case in which two
roundtrips are required for processing a request could become when the
client is required to send a new certificate. Also, AUTOMATIC_USE flag
becomes unnecessary.

One downside caused by such change is that the bandwidth slightly
increases due to the fact that the client would be required to specify
the certificate that is associated to every HTTP request. However that
is just sending Cert-ID per every HTTP request; I believe that the
increase of bandwidth is negligible.

To summarize, I am suggesting to push the responsibility of choosing
the certificate back to the client. Note that in the current draft the
client is still required to make such choice if the server sends a
CERTIFICATE_NEEDED frame; so I think requiring the client to _always_
make the choice does not increase the complexity on the client side.

[1] https://httpd.apache.org/docs/2.4/mod/mod_ssl.html

2017-10-31 8:14 GMT+08:00 Mike Bishop <[email-masked]>:
> In preparation for Singapore, we've updated the Additional Certs draft to track changes in TLS 1.3 and the Exported Authenticators TLS draft.  There's been substantial interest here, and we'll be discussing the draft during the WG meeting.
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 30, 2017 2:40 PM
> To: Martin Thomson <[email-masked]>; Mike Bishop <[email-masked]>; Nick Sullivan <[email-masked]>
> Subject: New Version Notification for draft-bishop-httpbis-http2-additional-certs-05.txt
>
>
> A new version of I-D, draft-bishop-httpbis-http2-additional-certs-05.txt
> has been successfully submitted by Mike Bishop and posted to the IETF repository.
>
> Name:           draft-bishop-httpbis-http2-additional-certs
> Revision:       05
> Title:          Secondary Certificate Authentication in HTTP/2
> Document date:  2017-10-30
> Group:          Individual Submission
> Pages:          21
> URL:            https://www.ietf.org/internet-drafts/draft-bishop-httpbis-http2-additional-certs-05.txt
> Status:         https://datatracker.ietf.org/doc/draft-bishop-httpbis-http2-additional-certs/
> Htmlized:       https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-05
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-bishop-httpbis-http2-additional-certs-05
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-bishop-httpbis-http2-additional-certs-05
>
> Abstract:
>   TLS provides fundamental mutual authentication services for HTTP,
>   supporting up to one server certificate and up to one client
>   certificate associated to the session to prove client and server
>   identities as necessary.  This draft provides mechanisms for
>   providing additional such certificates at the HTTP layer when these
>   constraints are not sufficient.
>
>   Many HTTP servers host content from several origins.  HTTP/2
>   [RFC7540] permits clients to reuse an existing HTTP connection to a
>   server provided that the secondary origin is also in the certificate
>   provided during the TLS [I-D.ietf-tls-tls13] handshake.
>
>   In many cases, servers will wish to maintain separate certificates
>   for different origins but still desire the benefits of a shared HTTP
>   connection.  Similarly, servers may require clients to present
>   authentication, but have different requirements based on the content
>   the client is attempting to access.
>
>   This document describes how TLS exported authenticators
>   [I-D.ietf-tls-exported-authenticator] can be used to provide proof of
>   ownership of additional certificates to the HTTP layer to support
>   both scenarios.
>
>
>
>
> 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: Nick Sullivan <[email-masked]>
Date: Mon, 13 Nov 2017 09:29:19 +0000

Hi Kazuho,

Thanks for this. I think you found an issue that we did not consider: the
fact that server support for setting AUTOMATIC_USE in client certificates
may not be desirable for all servers. The CGI case you describe would work
find as long as the client doesn't use AUTOMATIC_USE.

Here's a possible solution to this:
Let the server advertise support for AUTOMATIC_USE in the
CERTIFICATE_REQUEST message as a flag. If the client receives a
CERTIFICATE_REQUEST without AUTOMATIC_USE set, then it should not be able
to reply with a CERTIFICATE with AUTOMATIC_USE set.

Nick

On Mon, Nov 13, 2017 at 3:18 PM Kazuho Oku <[email-masked]> wrote:

> > In preparation for Singapore, we've updated the Additional Certs draft
> to track changes in TLS 1.3 and the Exported Authenticators TLS draft.
> There's been substantial interest here, and we'll be discussing the draft
> during the WG meeting.
> >
> > To: Martin Thomson <[email-masked]>; Mike Bishop <
> [email-masked]>; Nick Sullivan <[email-masked]>
> > Subject: New Version Notification for
> draft-bishop-httpbis-http2-additional-certs-05.txt
> >
> >
> > URL:
> https://www.ietf.org/internet-drafts/draft-bishop-httpbis-http2-additional-certs-05.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-bishop-httpbis-http2-additional-certs/
> > Htmlized:
> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-05
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-bishop-httpbis-http2-additional-certs-05
> > Diff:
> https://www.ietf.org/rfcdiff?url2=draft-bishop-httpbis-http2-additional-certs-05
> >
> > 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: Ilari Liusvaara <[email-masked]>
Date: Mon, 13 Nov 2017 12:47:10 +0200

> other de-facto standards that have evolved from CGI (e.g., FastCGI,

It is the same for FastCGI (FastCGI is essentially just CGI with
multiplexing). No knowledge of Rack.
 
> to request the client to send a new certificate.

Yes, the model is subtly different from the present one:

Cardinality goes from 0-1 to 0-*.

And what will application only using one certificate (all current
applications that use certificates!) do when it receives multiple
certificates? Will it even know what is going on?

Currently application that does not use certificates has much easier
time: It can just toss away the certificate.

So it is not clear that it is even safe to attach multiple certificates
to one request without application approval. Oh, and then you have the
scoping issues with such approval.

> such choice, but that is not the case for a CGI gateway.

And even if not using CGI, the application would have to coordinate
with HTTP server. Which has two problems:

1) It is a new interface (apps are not using it currently).
2) Possibly insufficient separation between HTTP server and application
   (e.g. bleeding or grabbing TLS keys due to application bugs).

Yes, it would be possible to extend FastCGI (not sure about CGI) to
support the coordination with proper isolation. But that would still
leave 1).

> would introduce one extra roundtrip.

Browsers that use AUTOMATIC_USE need to shard connections anyway.
Anything else would be a major problem.

> certificate that is associated to each HTTP request.

Yes, this would also eliminate the possiblity of server becoming
confused about client authority (in the other direction, the client can
always track the server authority properly).

> response to a CERTIFICATE_NEEDED frame.

Might also make sense for application to signal that the request will
not have a certificate (server behaves like any CERTIFICATE_NEEDED got
rejected).

> increase of bandwidth is negligible.

There would also be some nasty hacks that would allow coalescing the
cert-IDs of multiple consequtive requests with the same cert-ID.
However, any such mechanisms would need to ensure synchronization
between reads and writes of cert-ID, so that race conditions can
not corrupt the cert-ID.

E.g. using SETTINGS to write the cert-ID field and latching the
value on HEADERS frame that opens the stream.

> make the choice does not increase the complexity on the client side.

The clients must make such choice _anyway_. And then hopefully
signal the server properly about the result (if necressary, by
sharding).

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 13 Nov 2017 13:05:13 +0200

> find as long as the client doesn't use AUTOMATIC_USE.

I think it is more multiple certificates that causes problems here than
AUTOMATIC_USE.

(AUTOMATIC_USE has its problems, but those seem to be mostly related to
the server becoming confused about what the client actually meant).

-Ilari

---

From: Mike Bishop <[email-masked]>
Date: Mon, 13 Nov 2017 16:37:18 +0000

It might also be an option to remove AUTOMATIC_USE; clients that want a certificate applied to all requests generate the extra frame for each stream, but that's fairly small overhead.

I think for legacy reasons, it makes sense to restrict sending USE_CERTIFICATE 0-1 times *unless* the server sends multiple CERTIFICATE_REQUIRED messages.  This support was added to parallel TLS 1.3, which permits multiple simultaneous demands for (presumably different) certificates.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 13, 2017 7:05 PM
To: Nick Sullivan <[email-masked]>
Cc: Kazuho Oku <[email-masked]>; Mike Bishop <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: FW: New Version Notification for draft-bishop-httpbis-http2-additional-certs-05.txt

On Mon, Nov 13, 2017 at 09:29:19AM +0000, Nick Sullivan wrote:
> Hi Kazuho,
> 
> Thanks for this. I think you found an issue that we did not consider: 
> the fact that server support for setting AUTOMATIC_USE in client 
> certificates may not be desirable for all servers. The CGI case you 
> describe would work find as long as the client doesn't use AUTOMATIC_USE.

I think it is more multiple certificates that causes problems here than AUTOMATIC_USE.

(AUTOMATIC_USE has its problems, but those seem to be mostly related to the server becoming confused about what the client actually meant).

-Ilari

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 14 Nov 2017 14:23:50 +0800

Hi Nick, Ilari, Mike,

Thank you for your responses.

First, let me argue that there is no need to negotiate AUTOMATIC_USE.
Current draft permits the server to let the client choose a
certificate even in case AUTOMATIC_USE is being used. So it is
possible to cover the CGI use case under the current draft, though the
need to spend 2 RTT makes me bit sad (especially since I do not
understand the benefit of letting the server choose the certificate).

That said, let me elaborate about another issue related to
AUTOMATIC_USE; a potential privacy concern.

Consider the case of a CDN terminating example.com and example.org.
Both of the hosts require authentication using client certificates
issued by the same CA.

At first, a client connects to the CDN sending a request to
example.com, and sends its client certificate with AUTOMATIC_USE flag
set.

Then, using the same connection, a client sends a request to
example.org. At this point, is the CDN allowed to present the
certificate that was sent for example.com to example.org? My
understanding is that in HTTP/1, a user has the total control of
choosing the certificate the person wants to send to each domain.

So to me, it seems that we would be required to standardize when a
certificate sent with AUTOMATIC_USE flag set can be reused across the
authorities that are coalesced into a single connection, if we are to
enable automatic reuse (please let me know if that’s already
specified; I may have missed that).

One way to avoid the issue is to drop AUTOMATIC_USE from the
specification, and require the client to specify the certificate that
is associated to every request.

If we take that route, we would no longer be required to seek an
agreement and document when an intermediary can reuse a client
certificate across authorities. Elimination of AUTOMATIC_USE would
give the clients total control on how certificates are associated to
the requests they send, and the added bonus would be that the behavior
could be verified by consulting the client behavior.

2017-11-13 17:29 GMT+08:00 Nick Sullivan <[email-masked]>:
> CERTIFICATE_REQUEST without AUTOMATIC_USE set, then it should not be able to
> reply with a CERTIFICATE with AUTOMATIC_USE set.
>
> Nick
>
>> > To: Martin Thomson <[email-masked]>; Mike Bishop
>> > <[email-masked]>; Nick Sullivan <[email-masked]>

-- 
Kazuho Oku

---

From: Mike Bishop <[email-masked]>
Date: Tue, 14 Nov 2017 15:16:50 +0000

What the draft currently says about that is:

Client implementations need to carefully consider the impact of setting the AUTOMATIC_USE flag. This flag is a performance optimization, permitting the client to avoid a round-trip on each request where the server checks for certificate authentication. However, once this flag has been sent, the client has zero knowledge about whether the server will use the referenced cert for any future request, or even for an existing request which has not yet completed. Clients MUST NOT set this flag on any certificate which is not appropriate for currently-in-flight requests, and MUST NOT make any future requests on the same connection which they are not willing to have associated with the provided certificate.

So basically, if a client provides a certificate to example.com with AUTOMATIC_USE set, then later decides that it doesn’t want to use that certificate with example.org, then it MUST NOT send example.org requests on that connection and would need to start a fresh one.

I think that you’re right that negotiation isn’t needed if the client is allowed to preemptively send USE_CERTIFICATE with every request.  That introduces a race condition where confusion could ensue about whether the USE_CERTIFICATE was preemptive or in response to a CERTIFICATE_NEEDED.  However, that seems solvable if we specify timing rules.  A strawman:

  *   Eliminate AUTOMATIC_USE – the semantics are always true for servers and never true for clients
  *   Clients which have previously been challenged for and provided a certificate MAY send USE_CERTIFICATE as part of their subsequent or still-open requests
  *   Servers MUST NOT send CERTIFICATE_REQUIRED before seeing a complete request
     *   If the request included a USE_CERTIFICATE frame, the server MUST NOT send CERTIFICATE_REQUIRED, but MAY reset the stream with a NOT_WHAT_I_WANTED error code (better name TBD).
        *   Upon receipt of a NOT_WHAT_I_WANTED error, clients SHOULD resend the request without a USE_CERTIFICATE frame and expect a CERTIFICATE_REQUIRED frame
     *   If not, it MAY send a CERTIFICATE_REQUIRED if a certificate is required.

Something else that should have occurred to me long ago, but hit me while writing the above:  USE_CERTIFICATE will necessarily be sendable on a half-closed stream.  That’s possible in HTTP/2, but problematic in HTTP/QUIC.  We’ll have to think about that.

-----Original Message-----
From: Kazuho Oku [mailto:[email-masked]]
Sent: Tuesday, November 14, 2017 2:24 PM
To: Nick Sullivan <[email-masked]>
Cc: Mike Bishop <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: FW: New Version Notification for draft-bishop-httpbis-http2-additional-certs-05.txt

Hi Nick, Ilari, Mike,

Current draft permits the server to let the client choose a certificate even in case AUTOMATIC_USE is being used. So it is possible to cover the CGI use case under the current draft, though the need to spend 2 RTT makes me bit sad (especially since I do not understand the benefit of letting the server choose the certificate).

That said, let me elaborate about another issue related to AUTOMATIC_USE; a potential privacy concern.

Both of the hosts require authentication using client certificates issued by the same CA.

At first, a client connects to the CDN sending a request to example.com, and sends its client certificate with AUTOMATIC_USE flag set.

Then, using the same connection, a client sends a request to example.org. At this point, is the CDN allowed to present the certificate that was sent for example.com to example.org? My understanding is that in HTTP/1, a user has the total control of choosing the certificate the person wants to send to each domain.

So to me, it seems that we would be required to standardize when a certificate sent with AUTOMATIC_USE flag set can be reused across the authorities that are coalesced into a single connection, if we are to enable automatic reuse (please let me know if that’s already specified; I may have missed that).

One way to avoid the issue is to drop AUTOMATIC_USE from the specification, and require the client to specify the certificate that is associated to every request.

If we take that route, we would no longer be required to seek an agreement and document when an intermediary can reuse a client certificate across authorities. Elimination of AUTOMATIC_USE would give the clients total control on how certificates are associated to the requests they send, and the added bonus would be that the behavior could be verified by consulting the client behavior.

> CERTIFICATE_REQUEST without AUTOMATIC_USE set, then it should not be

> able to reply with a CERTIFICATE with AUTOMATIC_USE set.

> On Mon, Nov 13, 2017 at 3:18 PM Kazuho Oku <[email-masked]<mailto:[email-masked]>> wrote:

>> However, to me (as a HTTP server developer that acts as a CGI

>> gateway) it is unclear how a server can make such choice.

>> Applications that are run using the CGI protocol _might_ have

>> sufficient information to make such choice, but that is not the case for a CGI gateway.

>> * If the client does not specify a certificate that is associated to

>> a request, a server MAY request the client to specify the certificate.

>> roundtrips are required for processing a request could become when

>> the client is required to send a new certificate. Also, AUTOMATIC_USE

>> flag becomes unnecessary.

>> increases due to the fact that the client would be required to

>> specify the certificate that is associated to every HTTP request.

>> However that is just sending Cert-ID per every HTTP request; I

>> believe that the increase of bandwidth is negligible.

>> the certificate back to the client. Note that in the current draft

>> the client is still required to make such choice if the server sends

>> a CERTIFICATE_NEEDED frame; so I think requiring the client to

>> _always_ make the choice does not increase the complexity on the client side.

>> 2017-10-31 8:14 GMT+08:00 Mike Bishop <[email-masked]<mailto:[email-masked]>>:

>> > In preparation for Singapore, we've updated the Additional Certs

>> > draft to track changes in TLS 1.3 and the Exported Authenticators TLS draft.

>> > There's been substantial interest here, and we'll be discussing the

>> > draft during the WG meeting.

>> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

>> > To: Martin Thomson <[email-masked]<mailto:[email-masked]>>; Mike Bishop

>> > <[email-masked]<mailto:[email-masked]>>; Nick Sullivan <[email-masked]<mailto:[email-masked]>>

>> > A new version of I-D,

>> > has been successfully submitted by Mike Bishop and posted to the

>> > IETF repository.

>> > https://www.ietf.org/internet-drafts/draft-bishop-httpbis-http2-add

>> > itional-certs-05.txt

>> > https://datatracker.ietf.org/doc/draft-bishop-httpbis-http2-additio

>> > nal-certs/

>> > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-c

>> > erts-05

>> > https://datatracker.ietf.org/doc/html/draft-bishop-httpbis-http2-ad

>> > ditional-certs-05

>> > https://www.ietf.org/rfcdiff?url2=draft-bishop-httpbis-http2-additi

>> > onal-certs-05

--

Kazuho Oku

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 15 Nov 2017 00:20:58 +0800

Hi Mike,

2017-11-14 23:16 GMT+08:00 Mike Bishop <[email-masked]>:

> Client implementations need to carefully consider the impact of setting
> the AUTOMATIC_USE flag. This flag is a performance optimization, permitting
> the client to avoid a round-trip on each request where the server checks
> for certificate authentication. However, once this flag has been sent, the
> client has zero knowledge about whether the server will use the referenced
> cert for any future request, or even for an existing request which has not
> yet completed. Clients MUST NOT set this flag on any certificate which is
> not appropriate for currently-in-flight requests, and MUST NOT make any
> future requests on the same connection which they are not willing to have
> associated with the provided certificate.
>
>
>
> So basically, if a client provides a certificate to example.com with
> AUTOMATIC_USE set, then later decides that it doesn’t want to use that
> certificate with example.org, then it MUST NOT send example.org requests
> on that connection and would need to start a fresh one.
>

Thank you for pointing that out. I remember reading the section, but it's
obvious I missed the intent of the text.

I think that you’re right that negotiation isn’t needed if the client is
> allowed to preemptively send USE_CERTIFICATE with every request.  That
> introduces a race condition where confusion could ensue about whether the
> USE_CERTIFICATE was preemptive or in response to a CERTIFICATE_NEEDED.
> However, that seems solvable if we specify timing rules.  A strawman:
>
>    - Eliminate AUTOMATIC_USE – the semantics are always true for servers
>    and never true for clients
>    - Clients which have previously been challenged for and provided a
>    certificate MAY send USE_CERTIFICATE as part of their subsequent or
>    still-open requests
>    - Servers MUST NOT send CERTIFICATE_REQUIRED before seeing a complete
>    request
>       - If the request included a USE_CERTIFICATE frame, the server MUST
>       NOT send CERTIFICATE_REQUIRED, but MAY reset the stream with a
>       NOT_WHAT_I_WANTED error code (better name TBD).
>          - Upon receipt of a NOT_WHAT_I_WANTED error, clients SHOULD
>          resend the request without a USE_CERTIFICATE frame and expect a
>          CERTIFICATE_REQUIRED frame
>       - If not, it MAY send a CERTIFICATE_REQUIRED if a certificate is
>       required.
>
>
The strawman looks good to me. Thank you for writing them down. I like the
fact that the approach is simpler than the current one, and that the
round-trips required to perform the requests have been minimized in all
cases.

I have only one comment.

You might want to adjust the timing so that we could cap the amount of
memory need to buffer a pending request (note that in case of CGI,
properties of the client certificate needs to be sent to the application
before the request body. Also I would assume that such requirement exists
for other gateway protocols).

One way to implement such cap would be to change the timing requirement as
follows:

* a client that associates a client certificate to a request MUST send
USE_CERTIFICATE frame prior to sending a DATA frame
* otherwise, a client should send the USE_CERTIFICATE frame only in
response to a CERTIFICATE_REQUIRED frame

>
> Something else that should have occurred to me long ago, but hit me while
> writing the above:  USE_CERTIFICATE will necessarily be sendable on a
> half-closed stream.  That’s possible in HTTP/2, but problematic in
> HTTP/QUIC.  We’ll have to think about that.
>
>
>
> Current draft permits the server to let the client choose a certificate
> even in case AUTOMATIC_USE is being used. So it is possible to cover the
> CGI use case under the current draft, though the need to spend 2 RTT makes
> me bit sad (especially since I do not understand the benefit of letting the
> server choose the certificate).
>
>
>
> At first, a client connects to the CDN sending a request to example.com,
> and sends its client certificate with AUTOMATIC_USE flag set.
>
>
>
> Then, using the same connection, a client sends a request to example.org.
> At this point, is the CDN allowed to present the certificate that was sent
> for example.com to example.org? My understanding is that in HTTP/1, a
> user has the total control of choosing the certificate the person wants to
> send to each domain.
>
>
>
> enable automatic reuse (please let me know if that’s already specified; I
> may have missed that).
>
>
>
> specification, and require the client to specify the certificate that is
> associated to every request.
>
>
>
> If we take that route, we would no longer be required to seek an agreement
> and document when an intermediary can reuse a client certificate across
> authorities. Elimination of AUTOMATIC_USE would give the clients total
> control on how certificates are associated to the requests they send, and
> the added bonus would be that the behavior could be verified by consulting
> the client behavior.
>
>
>
> >> > From: [email-masked] [mailto:[email-masked]
> <[email-masked]>]
>

-- 
Kazuho Oku

---

From: Mike Bishop <[email-masked]>
Date: Wed, 15 Nov 2017 10:05:49 +0000

(If it’s helpful, the updated version of the doc, rather than the Markdown diff, can be found at https://mikebishop.github.io/http2-certs/not_automatic/draft-bishop-httpbis-http2-additional-certs.html.)

From: Mike Bishop
Sent: Wednesday, November 15, 2017 6:05 PM
To: 'Kazuho Oku' <[email-masked]>
Cc: Nick Sullivan <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: RE: FW: New Version Notification for draft-bishop-httpbis-http2-additional-certs-05.txt

I’ve put together a PR with a first pass at implementing your suggestion.  Give it a look before I merge?  Feedback from anyone else is welcome as well.

https://github.com/MikeBishop/http2-certs/pull/17

From: Kazuho Oku [mailto:[email-masked]]
Sent: Wednesday, November 15, 2017 12:21 AM
To: Mike Bishop <[email-masked]<mailto:[email-masked]>>
Cc: Nick Sullivan <[email-masked]<mailto:[email-masked]>>; HTTP Working Group <[email-masked]<mailto:[email-masked]>>
Subject: Re: FW: New Version Notification for draft-bishop-httpbis-http2-additional-certs-05.txt

Hi Mike,

2017-11-14 23:16 GMT+08:00 Mike Bishop <[email-masked]<mailto:[email-masked]>>:

So basically, if a client provides a certificate to example.com<http://example.com> with AUTOMATIC_USE set, then later decides that it doesn’t want to use that certificate with example.org<http://example.org>, then it MUST NOT send example.org<http://example.org> requests on that connection and would need to start a fresh one.

Thank you for pointing that out. I remember reading the section, but it's obvious I missed the intent of the text.

The strawman looks good to me. Thank you for writing them down. I like the fact that the approach is simpler than the current one, and that the round-trips required to perform the requests have been minimized in all cases.

I have only one comment.

You might want to adjust the timing so that we could cap the amount of memory need to buffer a pending request (note that in case of CGI, properties of the client certificate needs to be sent to the application before the request body. Also I would assume that such requirement exists for other gateway protocols).

One way to implement such cap would be to change the timing requirement as follows:

* a client that associates a client certificate to a request MUST send USE_CERTIFICATE frame prior to sending a DATA frame
* otherwise, a client should send the USE_CERTIFICATE frame only in response to a CERTIFICATE_REQUIRED frame

-----Original Message-----
From: Kazuho Oku [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, November 14, 2017 2:24 PM
To: Nick Sullivan <[email-masked]<mailto:[email-masked]>>
Cc: Mike Bishop <[email-masked]<mailto:[email-masked]>>; HTTP Working Group <[email-masked]<mailto:[email-masked]>>
Subject: Re: FW: New Version Notification for draft-bishop-httpbis-http2-additional-certs-05.txt

Hi Nick, Ilari, Mike,

Consider the case of a CDN terminating example.com<http://example.com> and example.org<http://example.org>.

At first, a client connects to the CDN sending a request to example.com<http://example.com>, and sends its client certificate with AUTOMATIC_USE flag set.

Then, using the same connection, a client sends a request to example.org<http://example.org>. At this point, is the CDN allowed to present the certificate that was sent for example.com<http://example.com> to example.org<http://example.org>? My understanding is that in HTTP/1, a user has the total control of choosing the certificate the person wants to send to each domain.

>> > tools.ietf.org<http://tools.ietf.org>.

--

Kazuho Oku

--
Kazuho Oku

---

From: Mike Bishop <[email-masked]>
Date: Wed, 15 Nov 2017 10:04:45 +0000

To: Mike Bishop <[email-masked]>

Hi Mike,

I have only one comment.

-----Original Message-----
From: Kazuho Oku [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, November 14, 2017 2:24 PM
To: Nick Sullivan <[email-masked]<mailto:[email-masked]>>
Cc: Mike Bishop <[email-masked]<mailto:[email-masked]>>; HTTP Working Group <[email-masked]<mailto:[email-masked]>>
Subject: Re: FW: New Version Notification for draft-bishop-httpbis-http2-additional-certs-05.txt

Hi Nick, Ilari, Mike,

--

Kazuho Oku

--
Kazuho Oku