On Wed 2017-06-21 21:25:21 -0700, Christian Huitema wrote:
> We has many discussions of SNI encryption on this list recently, and
> that was enough motivation to write a draft about it. I am pretty sure
> that this will be met with wide approval and no discussion at all :-).
This is my (hopefully not too tardy) review of
draft-huitema-tls-sni-encryption. fwiw, i still believe that the WG
should adopt this draft. Thanks for writing it, Christian and ekr!
* i agree with concerns raised about RFC 2119-style language -- they
don't really fit in the requirements and overall description. That
said, the natural english variants of those words are still relevant,
and shouldn't be ignored. The WG should try to prioritize the
different technical risks and opportunities.
Below are some comments/questions/nitpicks:
* The document uses the terms "Fronting server" and "Gateway", i think
interchangeably. It would be clearer if it stuck to a single term.
* §2.1 (Mitigate Replay Attacks) says "SNI encryption designs MUST
mitigate this attack", but "mitigate" sounds unclear and weak. do
you mean "must successfully prevent this attack" ? It seems like
this is all-or-nothing to me, not something that can be partially
alleviated.
* §2.4 (Do not stick out) While i understand the motivation of this
section, I think it's interesting that it rules out an entire
(simple) class of solution, namely the ssh-style approach: encrypt
first (without authenticating the server), then authenticate within
the encrypted tunnel. While this approach has several drawbacks (an
extra round-trip; leakage of SNI to an active adversary willing to
break connections to learn the desired SNI; difficulties for
non-crypto loadbalancers), it is really simple and straightforward to
implement and deploy (no third-party coordination, etc). (this
proposed approach also violates §2.7, "Fronting Server Spoofing")
If this approach were widely implemented, it wouldn't "stick out" any
more than SNI-free TLS handshakes did 10 years ago. Is it worth
documenting some solution of this class, just to provide a standard
way to do it, so that everyone doing it would at least be mixed into
a single (hopefully large) anonymity set?
* §2.5 (Forward Secrecy) -- "If the corresponding public key was
compromised" should probably be "…corresponding private key…".
"Forward secrecy" is also something of an ill-defined term, since the
window of the forward secrecy depends on key deletion schedules.
What if the private key for SNI encryption was rotated out (and
deleted) daily? would that be "forward secret" enough? how about
weekly? Perhaps this section should state that "designs should
clearly state their temporal window of vulnerable communications
should any non-ephemeral key be compromised"
* §3.2 (Delegation Token) -- i think the delegation token idea might
end up useful not only for §3 ("HTTP Co-Tenancy Fronting"). for
example, it might be usful for announcing either SNI encapsulations
(e.g., §4.2.3) or combined tickets (e.g., §5.3). so its location in the
document
is a bit odd.
* §4.1 (Tunneling TLS in TLS) says "an attacker should not be able to
distinguish these cases" but does not mention timing analysis. if
the Hidden server is not physically adjacent to (or co-tenanted with)
the Gateway, then the response ServerHello will have a different
latency than would a ServerHello that comes from the Gateway itself.
I don't think this is a deal-breaker, but we should probably
acknowledge it.
* §4.2 (Tunneling design issues) this section introduces the idea of a
"RealSNI scheme" without defining it. I think i know what it's
referring to, but perhaps it could be spelled out earlier for
contrast if this document is really exploring the full design space?
I think "conversely, these modes…" is referring to "RealSNI"-style
modes, but it could be mis-read as referring to the tunnelled
ClientHello described in §4.
* §4.2.1 (Gateway Logic) "EncryptedExtensions would be the most
natural, but they were removed from the ClientHello during the TLS
standardization." For those of us with either bad memory or bad
search skills, it would be nice to have a one-sentence summary of
*why* encryptedextensions were shot down, rather than just a "we
can't have this natural thing because reasons" argument by authority.
* §4.2.2 (Early data) "would requires" → "would require"
"delimitate" → "delimit", and "end of these" → "end of the"
Another difference between the posited schemes seems to be that the
double encryption scheme doesn't require the ClientHello to be in its
own separated EarlyData TLS record, while the blind relay case
expects the ClientHello to be isolated to a single record. Is that
correct? if so, it might be worth stating explicitly.
* §5 (SNI encryption with combined
