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

[Kazuho Oku <[e-mail]>]

Hi Mike,

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

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

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.
>
>
>
> -----Original Message-----
> From: Kazuho Oku [mailto:[e-mail]]
> Sent: Tuesday, November 14, 2017 2:24 PM
> To: Nick Sullivan <[e-mail]>
> Cc: Mike Bishop <[e-mail]>; HTTP Working Group <
> [e-mail]>
> Subject: Re: FW: New Version Notification for draft-bishop-httpbis-http2-
> additional-certs-05.txt
>
>
>
> 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]
> <[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-add
>
> >> > itional-certs-05.txt
>
> >> > Status:
>
> >> > https://datatracker.ietf.org/doc/draft-bishop-httpbis-http2-additio
>
> >> > nal-certs/
>
> >> > Htmlized:
>
> >> > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-c
>
> >> > erts-05
>
> >> > Htmlized:
>
> >> > https://datatracker.ietf.org/doc/html/draft-bishop-httpbis-http2-ad
>
> >> > ditional-certs-05
>
> >> > Diff:
>
> >> > https://www.ietf.org/rfcdiff?url2=draft-bishop-httpbis-http2-additi
>
> >> > onal-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
>



-- 
Kazuho Oku