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

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jun 2016 10:41:03 +1000

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 24 Jun 2016 10:28:33 +0300

On Fri, Jun 24, 2016 at 10:41:03AM +1000, Mark Nottingham wrote:
> 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.

I have been arguing before that doing certificate authentication in
HTTP/2 safely requires HTTP-level coordination, and still hold this
view. This spec is one way to do it.

What I don't like is MUST not send USE_CERTFICATE without
CERTIFICATE_REQUIRED. This forces client that wants to maintain
the required control in order to safely mux across authoriteies to
eat extra RTT for every request (yes, it would be guessing without,
but likely highly accurate guessing[1]).

Also, with regard to certificate chains, there are still loads of
certificate chains that contain PKCS#1v1.5 signatures, and there will
likely be for forseeable future[2].

[1] Note that endpoints that deal with multiple authorities and
client certificates (e.g. browsers!) need to do such guessing today,
even for HTTP/1.1.

[2] Even if the signing certificate is not RSA, there might be RSA
signatures higher up. And even the signature from root certificate
"leaks" into second-highest certificate.

-Ilari

---

From: Cory Benfield <[email-masked]>
Date: Fri, 24 Jun 2016 09:28:44 +0100

> On 24 Jun 2016, at 01:41, Mark Nottingham <[email-masked]> wrote:
> 

This draft seems like it does address several of the concerns that have been raised about certificates in HTTP/2.

My biggest concern with it is that this is a *massive* draft that appears to address several related but independent concerns at once. I’m not immediately sure that that’s the best approach with this: is there any value in breaking this draft up until multiple drafts, each of which addresses a single concern? At the very least we could have two: one for the AltSvc case of multiple origins on one connection, and one for the client certificate case.

Cory

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 24 Jun 2016 21:58:13 +0900

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

I support adoption and am interested in implementing it.

We are now considering of implementing TLS 1.3 ourselves for our
HTTP/2 server, but do not want to implement the client-authentication
part, since it cannot be used to present multiple credentials over a
single connection. Instead, it would be great if we could just
implement this specification to support authentication using client
certificates.

-- 
Kazuho Oku

---

From: Mike Bishop <[email-masked]>
Date: Fri, 24 Jun 2016 13:52:35 +0000

That was actually the previous state -- in BA, the working group decided to merge them before the CfA, since they use the same frames in opposite directions.  I don't feel too strongly either way, though I tend to prefer the merged version simply because otherwise you spend the whole second draft defining how to use the same frames in a different way.

-----Original Message-----
From: Cory Benfield [mailto:[email-masked]] 
Sent: Friday, June 24, 2016 1:29 AM
To: Mark Nottingham <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: Call for Adoption: Secondary Certificate Authentication in HTTP/2

Cory

---

From: Nick Sullivan <[email-masked]>
Date: Sat, 25 Jun 2016 12:44:20 +0100

I support adoption of this draft and will consider implementing it for
serving multiple domains over the same HTTP/2 connection.

There are still some open questions about whether the use of the SETTINGS
frame and the creation of two additional IANA registries is preferable to
the use of an Extended SETTINGS (
https://datatracker.ietf.org/doc/draft-bishop-httpbis-extended-settings/)
frame and the existing TLS Extensions IANA registry. However, I think this
can be resolved here.

Nick

On Sat, Jun 25, 2016 at 11:16 AM, Nick Sullivan <[email-masked]> wrote:

>
> That was actually the previous state -- in BA, the working group decided
> to merge them before the CfA, since they use the same frames in opposite
> directions.  I don't feel too strongly either way, though I tend to prefer
> the merged version simply because otherwise you spend the whole second
> draft defining how to use the same frames in a different way.
>
> > <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.
>
> This draft seems like it does address several of the concerns that have
> been raised about certificates in HTTP/2.
>
> My biggest concern with it is that this is a *massive* draft that appears
> to address several related but independent concerns at once. I’m not
> immediately sure that that’s the best approach with this: is there any
> value in breaking this draft up until multiple drafts, each of which
> addresses a single concern? At the very least we could have two: one for
> the AltSvc case of multiple origins on one connection, and one for the
> client certificate case.
>
> Cory
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Jun 2016 12:06:43 +1000

> but likely highly accurate guessing[1]).

This is something I'm not entirely happy with myself.  Hopefully we
can find some way that we can define an interaction that doesn't
require both the extra round trip AND the complexity.  As Cory notes,
this is more complex than ideal.

> likely be for forseeable future[2].

That's fine.  But we are explicitly not saying what is permitted in
the certificate chain, we are only saying what *this* protocol can
carry.  (In my opinion, saying that signature_algorithms also applies
to signatures on certificates is a mistake in TLS; and we we don't
need to replicate that.)

On 25 June 2016 at 21:44, Nick Sullivan <[email-masked]> wrote:
> the use of an Extended SETTINGS
> (https://datatracker.ietf.org/doc/draft-bishop-httpbis-extended-settings/)

I agree.   For the record, we should have built h2 settings like in
Mike's draft in the first place, but retrofitting it is harder.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 27 Jun 2016 20:39:13 +0300

> this is more complex than ideal.

Well, basically IMO the needs for client-server direction are:

1) Client to select the certificate set on per-request basis (including
   selecting the empty set).
2) Not to have to eat extra RTT for per-request control (as having to
   do that would be a perverse incentive).
3) Server to indicate that more certs are needed.
4) Client to be able to refuse server's request for extra certificate.

The set selection in 1) is obviously client-specific. E.g. Curl and
Firefox will do it in rather different ways.
 
An optimization would be for client to signal that the certificate set
it sent for request is closed: Any request to extend it will be denied
(the set will probably be empty, but not necressarily).

Capability to unilaterially send certificates would obviously
complicate things, as one would need to handle wild guesses about
capabilities of the server.

For the server-client direction:

1) Ability for server to push a new certificate unilaterially, and
   have the names appear in authority set.

IMO, no need to be ever able to remove names from that set or to
temporarily disable entries.

> to signatures on certificates is a mistake in TLS; and we we don't

Oh, looks like I misinterpretted it then...

And yeah, what is acceptable for end-entity signature and certificate
chain are two different things.

Also, the legacy constraints are different (where one can use modern
stuff and limit the combinations for EE signature, there is lot worse
stuff still out there with CA certs and signatures).

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Jun 2016 09:52:22 +1000

> temporarily disable entries.

This is a good summary of the requirements.  The question we are
struggling with is whether orthogonality of the two solutions is
possible.  Assembling all the pieces for the client to server
direction is challenging, but once you have those pieces, maybe you
don't want a whole different set of mechanisms for the reverse
direction.