huitema
commented
5 years ago "But any attack that modifies the ClientHello will cause the handshake to fail when the client receives the Finished from the server (i.e., immediately)." The text is about MITM attacks.
This is a pretty good piece of information that is very nearly done.
Regarding the idnits results, DoH is done, but DTLS and QUIC are still a way off. Would we prefer publication with downref or waiting? For me, this depends somewhat on the maturity of the documents that depend on this. I'd be willing to wait until those documents would have to wait for this one.
3.6 mentions attack by the fronting server or the multiplexed server. But the multiplexed server is the desired endpoint. I think that you can drop any reference to the multiplexed server here. It might require some reframing.
3.8.1 says that it "is thus desirable that SNI Encryption mechanisms be also able hide the ALPN." I think that we ultimately decided that while the techniques might be usable, it would be preferable to encrypt these independently. (Noting that SNI encryption as specified is rather bulky...)
3.9 suggests that parameters might be stripped from the ClientHello:
When designing SNI encryption schemes, we have to take into account attacks that strip parameters from the Client Hello, or replay attacks. In both cases, the desired behavior is to fall back to a connection with the fronting server, so there is no visble difference between a regular connection to that server and an attempt to reach the hidden server.
But any attack that modifies the ClientHello will cause the handshake to fail when the client receives the Finished from the server (i.e., immediately). Not to mention the server certificate being for a name the client doesn't expect.
The problem is that you can construct scenarios with controlled release of a spoofed server flight to test whether a client is willing to continue the connection. Note that you can't do a controlled release of a real flight from a server because any modification to the ClientHello will result in different handshake keys.
(Note also the typo: visble)
I don't know what was really intended by this section, but it needs work.
4 fails to acknowledge other work in this area, like draft-ietf-httpbis-http2-secondary-certs and the ORIGIN frame (RFC 8336).
Nits:
The document contains a mix of title- and sentence- case headings.
Terms are inconsistently capitalized throughout (like Fronting Server).
2.1 list construction requires "and" or "or" o Enterprise firewalls blocking web sites not deemed appropriate for work, +and+
2.3 missing "of" Deploying SNI encryption will help thwarting most +of+ the "unanticipated"
3.8 subject object disagreement The SNI encryption requirement do+es+ not stop with HTTP over TLS.
3.9. Fail to fronting <- not sure what this phrase means
3.9 also has inconsistent use of "client hello" vs. "Client Hello". I think that it's supposed to be "ClientHello".
4 just drop "/some-content" from the example, it doesn't help (and it's badly wrapped) 4 mismatched quotes on 'co-tenant"