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

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Jul 2016 15:48:24 -0700

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 <[email-masked]> 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/
>
>
>

---

From: Mike Bishop <[email-masked]>
Date: Thu, 7 Jul 2016 22:30:06 +0000

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:[email-masked]]
Sent: Monday, July 4, 2016 3:48 PM
To: Mark Nottingham <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: Call for Adoption: Secondary Certificate Authentication in HTTP/2

OVERALL

DETAILED COMMENTS
S 1.1.

S 2.

S 2.3.

S 3.1.

Same thing for Cert-ID.

S 3.3.

S 3.5.

S 6.1.

On Thu, Jun 23, 2016 at 5:41 PM, Mark Nottingham <[email-masked]<mailto:[email-masked]>> 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.

Cheers,

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 10 Jul 2016 18:23:47 -0700

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 <[email-masked]>
wrote:

> ·         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.
>
> ·         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:[email-masked]]
> *Sent:* Monday, July 4, 2016 3:48 PM
> *To:* Mark Nottingham <[email-masked]>
> *Cc:* HTTP Working Group <[email-masked]>
> *Subject:* Re: Call for Adoption: Secondary Certificate Authentication in
> HTTP/2
>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Jul 2016 14:01:50 +1000

> what he signs is the same every time, the counterparty can just replay the

I think that there is still room for restructuring how the assertions
are made so that integrating a request identifier (which might be
large and random) into the signature is a good idea.

> is a signature for both (for the same reason as #1).

Yes, we should cover the certificate with the signature.  It's
relatively easy to do.  And even if this isn't something that can be
exploited, it keeps this design from diverging too much from TLS
unnecessarily.

---

From: Patrick McManus <[email-masked]>
Date: Fri, 15 Jul 2016 14:09:26 -0400

Mike - thanks for this draft. As I noted at the mic in BA I strongly
support its adoption.

I have some feedback, some editorial some not.

*HTTP clients need to know that the content they receive on aconnection
comes from the origin that they intended to retrieve infrom.*
Something went awry there.. maybe s/in/it ?

B*ecause the TLS SNI extension is exchanged in the clear, clients
   might also prefer to retrieve certificates inside the encrypted
   context.*

not just clients who might prefer that.. perhaps "implementations" or
"peers"

c
*iphersuite at the TLS layer, while acquiring the "real" certificatein HTTP
after the connection is established.*

I know what you're going for - but saying scare quotes real makes me wonder
what the fake (i.e. not valid PKI) certificate is. Perhaps "final"?

*1.2.1 and 1.2.2*
Those sections about h1 are pretty long, detailed, and don't have a lot to
do with the mechanism being defined here other than as motivation. I think
they're targets for cutting and perhaps replacing with a short graf on the
challenges of auth of a transport stream when it is muxed between multiple
transactions. fwiw.

* defined in [RFC7540 <https://tools.ietf.org/html/rfc7540>], when a
client finds that a https:// origin
   (or Alternative Service [I-D.ietf-httpbis-alt-svc
<https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01#ref-I-D.ietf-httpbis-alt-svc>])
to which it needs
   to make a request has the same IP address as a server to which it is
   already connected, it MAY check whether the TLS certificate provided
   contains the new origin as well, and if so, reuse the connection.*

alt-svc never changes an origin so I don't think you need the parenthetical
and by calling it out it kinda adds to that general confusion. You might
just change all of

*https:// origin
   (or Alternative Service [I-D.ietf-httpbis-alt-svc
<https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01#ref-I-D.ietf-httpbis-alt-svc>])*

to be "server".

*   A server MAY push resources from an origin for which it is
   authoritative but for which the client has not yet received the
   certificate.  In this case, the client MUST verify the server's
   possession of an appropriate certificate by sending a
   "CERTIFICATE_REQUIRED" frame on the pushed stream to inform the
   server that progress is blocked until the request is satisfied.  The
   client MUST NOT use the pushed resource until an appropriate
   certificate has been received and validated.*

I think this might worry me the most. in practicality that means
certificate required is going to be sent on a closed stream a lot of the
time. The extension probably needs to work harder to say this is OK, given
that it is overriding 7540 - but in practice it seems like a hard
requirement to make work. And worse, you're adding a 1 RTT delay into push
when push is really only a 1 RTT mechanism anyhow. What if we could push
the certificate_required bit on the non-zero stream as some kind of
extension to push_promise?

   *This could also increase the impact of a key compromise.  Rather than
   needing to subvert DNS or IP routing in order to use a compromised
   certificate, a malicious server now only needs a client to connect to
   _some_ HTTPS site under its control.  Clients SHOULD continue to
   validate that destination IP addresses are valid for the origin
   either by direct DNS resolution or resolution of a validated
   Alternative Service.  (Future work could include a mechanism for a
   server to offer proofs.)*

I certainly think some text is needed here - but I have a fundamental
objection. Routing - whether that be IP routing, DNS routing, Alt-Svc
Routing, Proxy use or lookup, tcp hijack via inline proxy, or origin frames
is simply not part of the security model of https. The model is all about
the cert and the origin - not about how you got the bytes. The fact that
many of these are (ab)used pervasively on the Internet and https is
distinctly more secure in practice (not just theory) than http:// is
basically because of that. IP addresses don't even play a role in some of
those mechanisms (proxies?) and creating SHOULD language around validating
them over constrains us for no real gain. I would suggest some
non-normative text describing how certificates are the real security model
here and as we scrape away the compromised detritus that surrounds them
that becomes clearer.

Lastly, I liked how the general text called out the security benefit of
being able to hide SNI especially from passive attacks. The security
considerations mentions how this is still subject to active probing but it
might be worth re-iterating the passive benefit explicitly in the security
considerations.

Thanks again for this - this is an important draft with a lot of hard work
in it.

-P

---

From: Mike Bishop <[email-masked]>
Date: Sat, 16 Jul 2016 19:30:16 +0000

Thanks for the editorial catches!

Server might also prefer encrypted SNI, but with this model it’s only the client that decides whether to conceal the identity it actually intends to make requests of.  We can tweak the wording.  Your point about not calling it the “”real” certificate” with quotes is another candidate for wordsmithing.  The certificate of the origin to which it actually intends to make requests?  I’m basically taking this off of EKR and DKG’s idea that you do an external TLS handshake with an innocuous hostname, then get the cert for the hostname you actually care about inside the encrypted context.  So “fake” in that it’s not actually the origin you care about, not “fake” in the not-valid sense.

Yeah, the stream states aren’t ideal.  I was trying to define invalid stream states, and basically came down to only one stream state where this exchange can’t be made.  And you’re correct – it will normally either be done on an idle stream (pre-HEADERS) or a closed stream (unauthenticated push).  We could simplify that if we just said that servers MUST provide the certificate prior to pushing, which is probably worthwhile.  If we’re not expecting/permitting clients to just remember which certificates were collocated, then the server always knows exactly what set of certificates the client has seen from it on the current connection.

We’ve gotten into the is-it/isn’t-it of IP routing, name resolution, and the PKI’s interrelationship in the security model a couple times now.  I think you’ve mostly convinced me that we’re effectively betting the farm on certs and routing is just our security blanket, but the reality is that this would still make the use of a cert compromise / spoof much nastier.  I don’t have to get you to connect to me with the origin I compromised, I just have to get you to connect to me with some origin.  And the restriction does exist in HTTP/2 already, so I’d like a little better motivation to change it than just having thought better of it.  If it’s actually wrong, should we be updating RFC 7540 independent of this work?  Do you ignore DNS for coalescing purposes if the presented cert is valid for the origin?  But yes, I’d like to see us clarify our security model and assumptions, and if this helps move us down that road, I’m happy.

From: Patrick McManus [mailto:[email-masked]]
Sent: Friday, July 15, 2016 8:09 PM
To: Martin Thomson <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; Mike Bishop <[email-masked]>; Mark Nottingham <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: Call for Adoption: Secondary Certificate Authentication in HTTP/2

Mike - thanks for this draft. As I noted at the mic in BA I strongly support its adoption.
I have some feedback, some editorial some not.

HTTP clients need to know that the content they receive on a
connection comes from the origin that they intended to retrieve in
from.

Because the TLS SNI extension is exchanged in the clear, clients

   context.
not just clients who might prefer that.. perhaps "implementations" or "peers"

ciphersuite at the TLS layer, while acquiring the "real" certificate
in HTTP after the connection is established.
I know what you're going for - but saying scare quotes real makes me wonder what the fake (i.e. not valid PKI) certificate is. Perhaps "final"?

1.2.1 and 1.2.2
Those sections about h1 are pretty long, detailed, and don't have a lot to do with the mechanism being defined here other than as motivation. I think they're targets for cutting and perhaps replacing with a short graf on the challenges of auth of a transport stream when it is muxed between multiple transactions. fwiw.

 defined in [RFC7540<https://tools.ietf.org/html/rfc7540>], when a client finds that a https:// origin

   (or Alternative Service [I-D.ietf-httpbis-alt-svc<https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01#ref-I-D.ietf-httpbis-alt-svc>]) to which it needs

   contains the new origin as well, and if so, reuse the connection.
alt-svc never changes an origin so I don't think you need the parenthetical and by calling it out it kinda adds to that general confusion. You might just change all of

https:// origin

   (or Alternative Service [I-D.ietf-httpbis-alt-svc<https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01#ref-I-D.ietf-httpbis-alt-svc>])
to be "server".

   A server MAY push resources from an origin for which it is

   certificate has been received and validated.
I think this might worry me the most. in practicality that means certificate required is going to be sent on a closed stream a lot of the time. The extension probably needs to work harder to say this is OK, given that it is overriding 7540 - but in practice it seems like a hard requirement to make work. And worse, you're adding a 1 RTT delay into push when push is really only a 1 RTT mechanism anyhow. What if we could push the certificate_required bit on the non-zero stream as some kind of extension to push_promise?

   This could also increase the impact of a key compromise.  Rather than

   server to offer proofs.)
I certainly think some text is needed here - but I have a fundamental objection. Routing - whether that be IP routing, DNS routing, Alt-Svc Routing, Proxy use or lookup, tcp hijack via inline proxy, or origin frames is simply not part of the security model of https. The model is all about the cert and the origin - not about how you got the bytes. The fact that many of these are (ab)used pervasively on the Internet and https is distinctly more secure in practice (not just theory) than http:// is basically because of that. IP addresses don't even play a role in some of those mechanisms (proxies?) and creating SHOULD language around validating them over constrains us for no real gain. I would suggest some non-normative text describing how certificates are the real security model here and as we scrape away the compromised detritus that surrounds them that becomes clearer.
Lastly, I liked how the general text called out the security benefit of being able to hide SNI especially from passive attacks. The security considerations mentions how this is still subject to active probing but it might be worth re-iterating the passive benefit explicitly in the security considerations.
Thanks again for this - this is an important draft with a lot of hard work in it.
-P

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 17 Jul 2016 19:49:33 +1200

On 17/07/2016 7:30 a.m., Mike Bishop wrote:
> Server might also prefer encrypted SNI, but with this model it’s only
> the client that decides whether to conceal the identity it actually
> intends to make requests of.  We can tweak the wording.  Your point
> about not calling it the “”real” certificate” with quotes is another
> candidate for wordsmithing.  The certificate of the origin to which
> it actually intends to make requests?  I’m basically taking this off
> of EKR and DKG’s idea that you do an external TLS handshake with an
> innocuous hostname, then get the cert for the hostname you actually
> care about inside the encrypted context.  So “fake” in that it’s not
> actually the origin you care about, not “fake” in the not-valid
> sense.

So one certificate is about the channel and one about the origin. Can we
agree to use those terms (or similar polite equivalents) to describe them?

I agree with Patrick. Lets avoid branding anything "fake" if its an
expected or required part of the protocol, even if only by implication
of derived from something else being "real".

> 
> Yeah, the stream states aren’t ideal.  I was trying to define invalid
> stream states, and basically came down to only one stream state where
> this exchange can’t be made.  And you’re correct – it will normally
> either be done on an idle stream (pre-HEADERS) or a closed stream
> (unauthenticated push).  We could simplify that if we just said that
> servers MUST provide the certificate prior to pushing, which is
> probably worthwhile.  If we’re not expecting/permitting clients to
> just remember which certificates were collocated, then the server
> always knows exactly what set of certificates the client has seen
> from it on the current connection.

Considered the other way, what use is the certificate if its not
received until (long?) after the recipient has delivered the related
stream data[1] on to other unsuspecting actors?

Because thats what it will probably be doing once a stream is closed.
There is also the case of the stream closure triggering the whole
connection closure and in-transit octets being discarded unseen.

[1] I mean the transaction data in its general sense. HTTP headers,
metadata and payload inclusive, either partially or in whole

> 
> We’ve gotten into the is-it/isn’t-it of IP routing, name resolution,
> and the PKI’s interrelationship in the security model a couple times
> now.  I think you’ve mostly convinced me that we’re effectively
> betting the farm on certs and routing is just our security blanket,

I don't see why you would need convincing of that. This draft is about
certificate security - its name says as much. One expects it to focus on
the certificate part of the system and rely on external resources to
define the other parts.

> but the reality is that this would still make the use of a cert
> compromise / spoof much nastier.  I don’t have to get you to connect
> to me with the origin I compromised, I just have to get you to
> connect to me with some origin.  And the restriction does exist in
> HTTP/2 already, so I’d like a little better motivation to change it
> than just having thought better of it.  If it’s actually wrong,
> should we be updating RFC 7540 independent of this work?  Do you
> ignore DNS for coalescing purposes if the presented cert is valid for
> the origin?  But yes, I’d like to see us clarify our security model
> and assumptions, and if this helps move us down that road, I’m
> happy.

Calling the important dependencies out is good of course, but not at
expense of drowning out the document focus.

HTH
Amos

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 24 Jul 2016 13:34:35 +0300

> more closely track the TLS 1.3 mechanisms. Specifically:

Or if one wanted to really hack things, one could put the server
name in client request as certificate extension of SubjectAlternativeName
type.
 
> I think that this would be clearer and provide a better match for the

I think one needs to also sign and MAC over any implicit parameters
that are shared over multiple authentications. E.g. Supported end-
certificate signature algorithms.
 
> albeit being restricted to H2.

Not really:

TOKBIND is intended to restrict usage of cookies and other similar
resources. It is not intended to convey any sort of authority, and
using it for that purpose is highly dangerous. Whereas this mechanism
is explicitly to convey authority.

> of encrypted SNI where you want the gateway not to be able to see the

My understanding is that "encrypted SNI" usecase is that here it is
intededed to be used when both the "real" resources and "decoy"
resources are hosted on the same server.

One could do "gateway" already (albeit at cost of double encryption
as is fundamental to riding on top of TLS) using CONNECT (at least
for low-level implementation).

> and reserve some indicator for the certificates established in TLS.

Or better yet, subject any TLS certs to same control mechanism once
flag indicating support for this is flipped.
 
Such control mechanism is needed for client side anyway. I'm not sure
it is needed for server side, since server always designates its
authority.

> the signaling here in client->server is cruft.

If one wanted symmetry, having empty trust anchor list (which means
"implicit") wouldn't be that bad. Yeah, the whole browser list is far
too big to send.
 
> thinks it has already satisfied (e.g., a duplicate SAN?).

I think signaling no certificate would be reasonable.

However, if done that way, one has to be careful to explicitly
specify how certificate sets behave on resumption (e.g. clear all).

> - Also, nothing wrong with 64 bytes, but it seems a bit long, no?

I thought client and server already use different contexts to prevent
reflection (but maybe not, I think they should)?

RequestID/Context could be a counter?

> think at least 32-bit field would be wise.

Also note that if you have fields like this, I think you would need to
sign and MAC over their values, even if not actually part of every
request.

Also, I got an idea of sending the certificate on non-0 stream,
opened for the purpose. However, this might hit nasty implementability
problems (the original HTTP/2 spec is not careful with schemes, e.g.
doesn't require stream error on unknown scheme) and also could possibly
cause deadlocks. At least one could send clear stream errors, and not
mess with frame types.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Sun, 24 Jul 2016 12:56:31 +0200

> certificate signature algorithms.

My understanding of SIGMA is that the MAC needs to cover the identity
and other properties, but the signature only has to cover the key
shares (or shared key).  Thankfully we don't need to worry about that
distinction because of the way that TLS 1.3 and EMS cause everything
to depend on everything else: keys depend on identity and negotiation
parameters as much as the MAC does.

Either way, I am increasingly of the opinion that we should ask for
this facility from the TLS working group.  There are subtleties to
this that are easy to get wrong and good analysis is crucial.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 24 Jul 2016 14:18:30 +0300

> parameters as much as the MAC does.

I thought the easiest way is to multi-tap hashes (in the same style
TLS 1.3 does), which impiles that the both cover the same things
(modulo MAC also covering the signature)...

And if MAC needs to cover the "implicit" properties, it means you
need to be able to include those into computations.

> this that are easy to get wrong and good analysis is crucial.

I think before that, one should plan the interface to HTTP/2 and
some rough ideas for what information is passed.

E.g.
- Are the requests transferred as header blocks or binary blobs
  (I presume responses are binary blobs)?
- At least which parameters are present for each request?
- What of above parameters are shared over multiple requests?
- How many flights are allowable (I presume 1 request + 1 response,
  but this should be explicit)?
- If typed auxillary data (e.g. OCSP staple or SCT staple) can be
  passed back or not?

This is to know what to request, so one avoids nasty surprises
of having hard time figuring out how to pluck the result into
HTTP/2.

And I think certificate use control should be separate mechanism,
operating over proven certificates in client->server direction.

-Ilari