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

[Kazuho Oku <[e-mail]>]

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 <[e-mail]>:
> 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 <[e-mail]> 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).
>>
>> 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 <[e-mail]>:
>> > 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: [e-mail] [mailto:[e-mail]]
>> > Sent: Monday, October 30, 2017 2:40 PM
>> > To: Martin Thomson <[e-mail]>; Mike Bishop
>> > <[e-mail]>; Nick Sullivan <[e-mail]>
>> > 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
>>
>



-- 
Kazuho Oku