RE: Call for Adoption: Secondary Certificate Authentication in HTTP/2

Eric, thanks for the detailed write-up!

To your points:

·         Yes, the identity request is a little shoehorned.  Part of that is to maintain the symmetry, as you noted.  Another part is that the format the server uses already contains the ability to specify what the client will be looking for, so writing something separate (albeit simpler) seems needless duplication.  In a previous version, a field that clients don’t need to use was repurposed to contain a desired server identity, until I realized that the CertificateRequest already conveys the desired SAN and thought I could simplify it.  However, that’s a refinement the working group can debate in as much detail as they wish.  I don’t feel that strongly.

·         IIUC, TOKBIND doesn’t really prove an identity per se; it provides keying material that can be used to strongly bind generated values (e.g. Cookies) to the keypair-pair of the parties communicating.  That’s largely orthogonal to this draft.  This draft is much more akin to the certificate exchanges in TLS, simply the fact that we can do more of them and keep them out of your implementations.

·         1.1 (Encrypted SNI):  True; I’m not considering the gateway and the end-server as distinct.  It’s a passing reference to a possible use-case.

·         2 (AUTOMATIC_USE):  Here is where two viewpoints collide.  There are the security-minded, who think that clients should never use this.  There are the latency-minded who think that clients will always use this.  Putting a flag in lets the client implementer decide which camp he lives in.  Two notes of interest:

o   Allowing a client to unilaterally send a USE_CERTIFICATE without being challenged would allow a client to effectively replicate this behavior if we took the flag out.  It might be a good compromise.

o   TLS client certs effectively put AUTOMATIC_USE on everything – there’s no way to apply a client certificate to only certain requests.

·         2.3 (MUST NOT):  Mostly because there are weird corner cases you get into where the server can’t actually be sure whether the client violated the MUST.  I prefer unenforceable requirements to be SHOULDs.  I don’t feel strongly that there’s a good reason for a client to do this, so if the WG wants a stronger keyword, I’m amenable.

·         3.1 (ID length):  No strong feelings here.  Just trying not to spend bytes without cause.  If one cert per direction has been sufficient in TLS for so long, I wasn’t sure we’d quickly exhaust 255….

·         3.3 (REQUEST contents):  Happy to add/remove things as needed.  This is currently outright theft of the TLS 1.3 CertificateRequest as of the time I wrote it, so it doesn’t pick up things that are conveyed in TLS extensions outside the CertificateRequest.

·         3.3 (duplicate REQUEST):  That’s a very common race condition; send a USE_CERTIFICATE pointing to the appropriate cert and keep going.

·         3.5 (signed value):  All good suggestions.  I defer to my TLS brethren for all things crypto.

·         6.1 (bitfield):  That’s actually what sparked the EXTENDED_SETTINGS draft, because a bitfield in the first place feels like needless silliness, but HTTP/2 defines all settings to be two bytes in length.  If that draft also gets adopted, we can just use the values from the TLS registries here.

All in all, I agree with you – there’s a lot here that needs to be fleshed out with area experts and real-world implementation before publication.

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Monday, July 4, 2016 3:48 PM
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Call for Adoption: Secondary Certificate Authentication in HTTP/2

Document: draft-bishop-httpbis-http2-additional-certs-01

OVERALL
I don't have a strong position on the level of demand for the
functionality in this draft (though the fact that Nick, Martin, and
MikeB all think it's useful counts for a lot with me). My comments
below are restricted to the technical functionality.

This document is targeted at two primary use cases:

- Servers which have multiple certificates corresponding to
  >1 origins and want to mux them over the same connections.
- On-the-fly client authentication conditioned on access to
  protected resources.

In each of these cases, it seems like there are two phases:

1. The relying party indicates the identity it would like the
   peer to authenticate for.
2. The authenticating party supplies a certificate and proves
   possession of the private key corresponding to the certificate.

The second of these seems pretty similar for both use cases, but the
first actually is rather different and seems rather shoe-horned in in
an attempt to make it symmetrical. I would suggest instead that we
provide different mechanisms for the "certificate request" phase that
more closely track the TLS 1.3 mechanisms. Specifically:

- When requesting that the server authenticate for a new origin,
  the client should supply a new domain name.
- When requesting that the client authenticate for a new certificate
  the server should supply a CertificateRequest which indicates
  detailed certificate properties (this is more or less what the
  draft does).

I think that this would be clearer and provide a better match for the
use case.

I'd also like to understand the relationship of this mechanism
with TOKBIND, as it seems that it has extremely similar properties,
albeit being restricted to H2.

I think it would be OK to adopt this document, but IMO it will need
a fair bit of work before it's ready for publication.


DETAILED COMMENTS
S 1.1.
I'm a bit skeptical of this encrypted SNI use case, though I suppose
it might work in some settings. As DKG has suggested, there are applications
of encrypted SNI where you want the gateway not to be able to see the
plaintext.


S 2.
This AUTOMATIC_USE thing seems very dangerous, as indicated in S 5.  I
would suggest instead that servers always have this semantic (you
require this anyway in S 3.5) and that clients never have this
semantic. In addition, I would forbid ambient authentication with
any certificate (including one established at the TLS layer) once
the client has authenticated with a certificate at the HTTP layer,
and reserve some indicator for the certificates established in TLS.


S 2.3.
It would be nice to be clear that the client MUST NOT send a request
to an unauthenticated domain prior to completion of the CERT_REQUIRED.

I see that you are retroactively authenticating pushed resources.
I guess we've decided to live with this, but...


S 3.1.
This Request-ID seems very short. Surely it's easily possible to
do >1 requests. What is the benefit in making it so short?

Same thing for Cert-ID.


S 3.3.
It's pretty odd that you allow servers to take a position on which
extensions should be in certs but not on what signature algorithms
should be used to sign them. Also, as noted above, all the fields here
are useless in the server->client authentication case (it's not like
you're going to provide the whole trust anchor list). You should
use a different format here for server and client, because most of
the signaling here in client->server is cruft.

What is a peer supposed to do if it receies a request that it
thinks it has already satisfied (e.g., a duplicate SAN?).


S 3.5.
Signing the same value with every CERTIFICATE_PROOF seems like it's
really living on the edge. Minimally, it seems like you have a
reflection attack where the client is able to replay the server's
CERTIFICATE_PROOF back to it. I would recommend that:

- You sign over the certificate and the RequestID (I don't have a
  concrete attack but it just seems like an abundance of caution).
  You could just stuff it in the context parameter.
- Have the client and server exporters be different to avoid reflection.
- Also, nothing wrong with 64 bytes, but it seems a bit long, no?


S 6.1.
A two byte bitfield indicating which algorithms you support seems
like premature optimization. It's easy to see how this gets to be
half-full, just with algorithms that we know of today (4Q, digest
signatures, some sort of lattice-based post-quantum thing). I would
think at least 32-bit field would be wise.


On Thu, Jun 23, 2016 at 5:41 PM, Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>> wrote:
<https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs>

We've discussed carrying certificates and related artefacts in HTTP for a long time. This draft from Mike and Martin is an evolution of several previous approaches.

Please state whether you support adoption, and ideally why. Expressions of interest in implementation would also be very helpful.

We'll wait at least one week before making a decision.

Cheers,


--
Mark Nottingham   https://www.mnot.net/