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