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

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 <kazuhooku@gmail.com> 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 <mbishop@evequefou.be>:
> > 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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > Sent: Monday, October 30, 2017 2:40 PM
> > To: Martin Thomson <martin.thomson@gmail.com>; Mike Bishop <
> mbishop@evequefou.be>; Nick Sullivan <nick@cloudflare.com>
> > 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
>
>