Re: [WIP/Idea] A protocol for securing CDN-related communications

The QUIC transport supports client or server initiating bidirectional or
unidirectional streams.

HTTP/3, which runs on QUIC, supports server push, but I don't think server
push quite fits your intended use of server-initiated streams?  If so, you
could still use HTTP/3, but define an extension stream type for
server-initiated streams of a different sort.
https://tools.ietf.org/html/draft-ietf-quic-http-18#section-7

On Tue, Feb 19, 2019 at 2:45 PM Soni L. <fakedme+http@gmail.com> wrote:

> I don't know a lot about QUIC. Does it support the server opening streams
> towards the client?
>
> In SCTP, the side that receives INIT (sends INIT_ACK) can open streams
> towards the side that receives INIT_ACK (sends INIT). This doesn't cause
> any issues with firewall/NAT tho, because it's being multiplexed within the
> same connection.
>
> On 2019-02-19 12:34 p.m., Ian Swett wrote:
>
> As an alternative to SCTP, you may want to consider QUIC:
> https://datatracker.ietf.org/wg/quic/about/
>
> On Tue, Feb 19, 2019 at 10:29 AM Patrick McManus <mcmanus@ducksong.com>
> wrote:
>
>> you might be interested in this, expired and individual, draft:
>> https://datatracker.ietf.org/doc/html/draft-thomson-http-bc
>>
>>
>>
>> On Tue, Feb 19, 2019 at 6:39 AM Soni L. <fakedme+http@gmail.com> wrote:
>>
>>> I'm upset that CDNs encourage bad practices like letting the CDN
>>> re-encrypt all communications and/or sending data in plaintext between the
>>> CDN and the server.
>>>
>>> As such I came up with this idea for a protocol that attempts to better
>>> secure that communication, and treats the CDN as a mostly untrusted MITM.
>>> (Keep in mind one of the attack modes of any untrusted MITM is website
>>> fingerprinting, where the attacker examines traffic flow to determine which
>>> webpages an user is browsing, even if the connection is encrypted. This
>>> attack mode is reflected in some of the decisions I've made while writing
>>> down this idea - the CDN gets to decrypt some data, but cannot modify any
>>> of it.)
>>>
>>> It's also meant to allow for ISPs to run transparent proxies (as if a
>>> CDN), in the hopes that mobile networks can use this to lower their
>>> operational costs, making mobile internet cheaper!
>>>
>>> (Ps: I forgot to include a thing about the signed response, namely that
>>> it should also include the request path. But, as I said, "WIP/Idea". I
>>> probably forgot more stuff also. It also doesn't follow the RFC format.)
>>>
>>> - - -
>>>
>>> https://cybre.tech/SoniEx2/paste/src/branch/mhttp/mhttp.md
>>>
>>> # Mobile Hypertext Transfer Protocol, version 1.1
>>>
>>> ## Introduction
>>>
>>> Mobile Hypertext Transfer Protocol (MHTTP) is a protocol that helps speed up the web and protect it from DDoS attacks, while providing strong security guarantees. It's heavily based on HTTPS, and also uses SCTP where available.
>>>
>>> The "Mobile" in the name refers to mobile phones.
>>>
>>> The MHTTP version tracks the corresponding HTTP version it's built on. As such, there's no MHTTP/1.0 or MHTTP/0.9 as there are no versions of MHTTP built on those HTTP versions.
>>>
>>> This protocol builds on:
>>>
>>> - SCTP
>>> - TLS Application-Layer Protocol Negotiation (ALPN)
>>> - A new type of TLS certificate
>>> - HTTPS/1.1 (HTTP/1.1 over TLS)
>>>
>>> This protocol shall define the TLS ALPN protocol ID `"mhttp/1.1"`.
>>>
>>> This protocol also makes use of the TLS ALPN protocol ID `"http/1.1"`.
>>>
>>> ## New certificate types (and new certificate authority types)
>>>
>>> Two new kinds of certificates shall be created:
>>>
>>> - \[TBD], the public-facing certificate type in mhttp/1.1.
>>> - \[TBD], used by CAs to sign the above.
>>>
>>> They have to be added so as to prevent Let's Encrypt from being able to issue them at the moment. This is a temporary measure and should be revised once certificate providers adjust to this new protocol.
>>>
>>> ## The Network Model
>>>
>>> This protocol is built upon the following network model:
>>>
>>>     client <--------> CDN <--------> server
>>>
>>> Currently, existing protocols are used to provide CDN services like so:
>>>
>>>     client <--HTTPS-> CDN <--HTTP--> server
>>>
>>> ## Securing communications between client and server
>>>
>>> The MHTTP protocol attempts to secure communication between client and server through the whole path. It puts both the client and the server in control, as it should be, where the existing options put the CDN in control.
>>>
>>> To be able to do this, it needs to cover a few different scenarios.
>>>
>>> ### Backwards compatibility with HTTPS, TCP, client certificates.
>>>
>>> For backwards compatibility with HTTPS, TCP, client certificates, the following section applies, but for all HTTP methods.
>>>
>>> ### Client-to-server (private) data
>>>
>>> The most basic scenario is when sending "private" data. This is used when modifying server data. This includes the following HTTP methods:
>>>
>>> - POST
>>> - PUT
>>> - DELETE
>>> - PATCH
>>> - \[TBD]
>>>
>>> In this scenario, the client may use a TCP or SCTP connection and must use the `"http/1.1"` protocol. The CDN must pass this stream through unchanged, but may choose to restrict the client's bandwidth and/or connection limits. The CDN must use SCTP for any connections to the server.
>>>
>>> This scenario should be used whenever the client would make a request using one of the above HTTP methods.
>>>
>>> ### Client-to-CDN, cached data
>>>
>>> In most cases, the client wants to request data from the \[server/CDN] instead. In MHTTP/1.1, the client must use an SCTP connection, and request the `"mhttp/1.1"` and `"http/1.1"` protocols, in that order, in descending order of preference.
>>>
>>> If a CDN exists and supports MHTTP/1.1, it must negotiate a TLS stream with the client using the CDN certificate mentioned in section 2.
>>>
>>> MHTTP/1.1 requests look just like HTTP/1.1 requests, but with some key differences:
>>>
>>> - POST, PUT, DELETE, PATCH, \[TBD] are not supported.
>>> - Cookies are not supported.
>>> - "MHTTP/1.1" is used instead of "HTTP/1.1".
>>> - \[TBD]
>>>
>>> The CDN must cache based on at least:
>>>
>>> - Resource Path
>>> - Accept/Content-Type header
>>> - Accept-Language header
>>>
>>> If the CDN has the response in its cache, it should just send that response out, without hitting the server.
>>>
>>> The CDN should not choose to send the same response for different Accept headers, and should take preference into account if doing so. For example, if the first request contains the header:
>>>
>>>     Accept: */*
>>>
>>> And the response contains:
>>>
>>>     Content-Type: text/html
>>>
>>> But the second request contains:
>>>
>>>     Accept: application/xhtml+xml, text/html; q=0.5
>>>
>>> Then the CDN should hit the server for an `application/xhtml+xml`. If one is found, a subsequent request with `Accept: */*` may retrieve an `application/xhtml+xml` instead of `text/html`.
>>>
>>> If the CDN does not have the response in its cache, the next scenario applies.
>>>
>>> ### Client-to-CDN, uncached data
>>>
>>> If the CDN does not have the response in its cache, it must open a stream to the server, using the `"mhttp/1.1"` protocol and the CDN certificate as the TLS client certificate.
>>>
>>> The CDN must then repeat the exact same request it was given, as in plain HTTP/1.1. \[TODO: specify how to identify the client to the server] The server may then choose to send the CDN a response. However, the response has some key differences from HTTP/1.1.
>>>
>>> First, the response starts with the server's certificate.
>>>
>>> Second, the response must contain the cache control headers:
>>>
>>> - `Expires`
>>> - \[TBD]
>>>
>>> It should contain additional cache control headers for use by the CDN and client.
>>>
>>> Third, the response (headers and body) must be signed by the provided certificate's key (server's private key). The certificate itself is not included in this signature.
>>>
>>> If the CDN provides an expired response to the client, as defined by the `Expires` header, the client must warn the user and discard the response. To account for network latency, the CDN may choose to expire the response a few seconds or a few minutes before the true expiry date.
>>>
>>> If the server chooses not to send the CDN a response, it can do so in the next scenario.
>>>
>>> ### CDN-mediated client-to-server, (true) private data
>>>
>>> If the server doesn't want the CDN to cache a GET/\[TBD] request, it can open a new SCTP stream for sending the data directly to the client.
>>>
>>> If the server opens an SCTP stream to the CDN instead of responding to a request, the CDN must forward this new stream as a new stream to the client. The client should then start a TLS handshake with the server, using the `"http/1.1"` protocol, and run a normal HTTP request with all normal HTTP headers, including cookies. See the backwards compatibility section for details.
>>>
>>> (This requires SCTP because TCP-based alternatives would either require the CDN to signal a connection closed, which could be caused by another network factor not involving the CDN, and thus unnecessarily increase server load as well as reducing the reliability of the backwards compatibility mechanisms, or it'd involve a reverse TCP connection and we already know how that went for FTP.)
>>>
>>>
>