Yet another trusted proxy suggestion

So after several threads, both here and and in private, I get a feeling 
that the opposition is more to breaking TLS than to having an HTTP(S) proxy.

Given that, I would like to lay out a a proposal for the flow of proxy 
detection and usage, without getting too low-level.

As an example, we'll assume there's a user, alice@example.com, who uses 
her computer to download something from https://download.adobe.com.  
There are two proxies involved in this:
  - one is a next-generation firewall: sslproxy.example.com
  - one is a CDN server called a1953.d.cdn.net

Note that under this scenario, a1953.d.cdn.net resolves to the same IP 
address (192.0.2.5) as download.adobe.com. Maybe this can be improved, 
but that's how CDNs work for now.

Another thing to note is that there are actually two entities in the 
first part. There's the proxy, which deals in HTTP(S), and then there's 
the firewall which prevents E2E communications. They may be co-located, 
but then don't have to be.

Step #1
=======
The browser resolves download.adobe.com, and opens a connection to 
192.0.2.5 port 443. The firewall blocks this. I'm not sure it it's 
preferable to block this with some ICMP or with a new TLS alert (so the 
firewall completes the 3-way TCP handshake, receives the ClientHello and 
only then sends the error), but I'm tending towards the latter. The new 
TLS alert is called "mandatory proxy" and contains the URL of that 
proxy: https://sslproxy.example.com:443


Step #2
=======
The browser consults local policy about whether such a proxy might be 
acceptable, and if so, opens a new TLS connection to the proxy and 
verifies the certificate. This allows adding some clever UX that shows 
the user what device is on-path, and also allows pre-configuring the 
trusted proxy based on name.

Step #3
=======
The browser sends a CONNECT command to the proxy (maybe that has to be 
enhanced as well?) to connect to https://download.adobe.com. The proxy 
tries to connect, and then either of two things happens:
  1. a1953.d.cdn.net has a certificate for download.adobe.com - that is 
what we do today.
  2. a1953.d.cdn.net has a certificate for a1953.d.cdn.net, and issues a 
"mandatory proxy" alert with its name.
In the former case, things will work as today. In the latter case, I'm 
not sure how the proxy (or browser for that matter) can know that 
a1953.d.cdn.net is a trusted proxy for download.adobe.com. Having the 
private key is a good indication, but I think we want to get away from that.
Either way, the connection is established

Step #4
=======
If there is some personalized information, the CDN server can open a 
connection to the real server. This time there is a pre-arrangement, so 
the names in the certificate may be different.

Step #5
=======
Requests and responses go through the series of nodes. We should note 
that things like flow control are hop-by-hop, so the SETTINGS frame is 
not forwarded, but is hop-by-hop. We would also like to have some 
information for both client and server. Here's my suggestion for this:
ClientInfo structure:
  - certificate chain sent by the client (if any)
  - ciphersuite used
  - this)proxy certificate chain.
  - subject (or SKID) of received server (or next proxy) certificate

ServerInfo structure:
  - certificate chain sent by the server (or another proxy)
  - ciphersuite used
  - subject (or SKID) or (this) proxy certificate

Each proxy sends a ClientInfo structure to the server. This could be 
done as a POST to a /.well-known URI or as a new special frame. I prefer 
the latter, but I don't know how well that will sit with several proxies 
trying to push the same resource to the server.
Each proxy also sends a ServerInfo structure to the client. Again, this 
could be a pushed resource or a special frame. Same concern applies.

Step #6
=======
At the end of this, both client and server can construct the chain of 
certificate chains and the ciphersuite used in each leg of the trip.

TLS is not changed by this, but HTTPS is.

I'd love to hear comments on this. If there's interest I could write it 
up in a draft, but having been burned twice, I'd like to know there's 
interest first.

Yoav