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

Oh, I forgot to mention, there's also two other small issues on this
design, both of which are tied to the content of the signature and come up
in situations of partial compromise.

1. It's not possible to force a counterparty to demonstrate that he still
has control of a given signing key. So, for instance, if you were a server
and wanted a user to demonstrate that he still had access to the key (like,
it's in a token and you're authorizing a high value transaction). Because
what he signs is the same every time, the counterparty can just replay the
previous assertion.

2. If you have two certificates with the same key pair, a signature for one
is a signature for both (for the same reason as #1).

I don't have any non-contrived scenarios where this is a real security
problem (which doesn't mean there aren't any), but if we're willing to
entertain contrived scenarios, consider what happens if you have a
kiosk-type application where the client authenticates with a hardware
token; the traffic keys get compromised (unbeknowst to the server);  but
the server wants to verify that the client still has access to the token.
The attacker could replay the previous assertion and there's no way for the
server to detect it.

If you contrast the design here to the Authentication block in TLS 1.3, you
can see that i 1.3, the client CertificateVerify covers both (a) a unique
value provided by the server and (b) the client's certificate, which (I
believe) should preclude these issues.

-Ekr


On Thu, Jul 7, 2016 at 3:30 PM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

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