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

[Mike Bishop <[e-mail]>]

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:[e-mail]]
Sent: Friday, July 15, 2016 8:09 PM
To: Martin Thomson <[e-mail]>
Cc: Eric Rescorla <[e-mail]>; Mike Bishop <[e-mail]>; Mark Nottingham <[e-mail]>; HTTP Working Group <[e-mail]>
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.

Something went awry there.. maybe s/in/it ?

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

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

   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