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