ISC Handler Rob sent the team a draft RFC currently under review by the IETF that seemingly fits quite nicely in the "What could possibly go wrong?" category.

Take a second and read Explicit Trusted Proxy in HTTP/2.0 then come back for further discussion.

Collect jaw from floor, and recognize that what's being proposed "buggers the CA concept and browser implementation enough to allow ISP’s to stand up “trusted proxies” to MITM and cache SSL content in the name of "increasing performance." Following are highlights of my favorite content from this poorly oddly written draft, as well as some initial comments:

• "This document addresses proxies that act as intermediary for HTTP2 traffic and therefore the security and privacy implications of having those proxies in the path need to be considered."
  • We agree. :-)
• "Users should be made aware that, different than end-to-end HTTPS, the achievable security level is now also dependent on the security features/capabilities of the proxy as to what cipher suites it supports, which root CA certificates it trusts, how it checks certificate revocation status, etc.  Users should also be made aware that the proxy has visibility to the actual content they exchange with Web servers, including personal and sensitive information."
  • All I have is "wow".
• There are opt-out options, sure, but no one's every disguised or abused such options, right?
  • Opt out 1 (proxy certificate): "If the user does not give consent, or decides to opt out from the proxy for a specific connection, the user-agent will negotiate HTTP2 connection using "h2" value in the Application Layer Protocol    Negotiation (ALPN) extension field.  The proxy will then notice that the TLS connection is to be used for a https resource or for a http resource for which the user wants to opt out from the proxy."    
  • Opt out 2 (captive proxy): "Specifies how an user can opt out (i.e. refuse) the presence of a Proxy for all the subsequent requests toward "http" URI resources while it stays in that network."
• Section 7's title is Privacy Considerations. None are listed.
  • Er? Here, I'll write the section for you. Opt in and you have no privacy.
• The draft states that the Via general-header field MUST be used by the user-agent to indicate the presence of the secure proxy between the User-Agent and the server on requests, and between the origin server and the User-Agent on responses in order to signal the presence of a Proxy in between, or loosely translated into MITM. 
  • And if it's not used? Session disallowed? Appears not:
    • The draft has said MUST re: the Via header but then says...
      • "If any of the following checks fails the User-Agent should immediately exit this Proxy mode:
        1.  the server's certificate is issued by a trusted CA and the certificate is valid;
        2.  the Extended Key Usage extension is present in the certificate and indicates the owner of this certificate is a proxy;
        3.  the server possesses the private key corresponding to the certificate."
    • ...but says nothing about what happens if the headers are wrong or Via is not used.
• Love this one: "To further increase the security, the validation by the CA could also include technical details and processes relevant for the security.  The owner could for example be obliged to apply security patches in a timely fashion."
  • Right...because everyone patches in a timely fashion. And the Patch Police agency to enforce this control will be...?

Maybe I'm reading this wrong and don't know what I'm talking about (common), but we think this draft leaves much to be desired.

What do readers think? Imagine this as industry standard in the context of recent NSA allegations or other similar concerns. Feedback and comments invited and welcome.