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

On Mon, Nov 13, 2017 at 03:09:30PM +0800, Kazuho Oku wrote:
> 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).

It is the same for FastCGI (FastCGI is essentially just CGI with
multiplexing). No knowledge of 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.

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.

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

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).

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

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

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

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).

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

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

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

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.

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

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


-Ilari

Received on Monday, 13 November 2017 10:47:40 UTC