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 tickets)
This proposal seems to require trial decryption by the Fronting
server against both its own preferred STEK, and by the K_sni that it
shares with the Hidden service. If one Fronting server wants to
front for N Hidden services, it will need N different K_sni values,
and it will need to do N+1 trial decryptions on each proposed session
resumption. This seeems to run afoul of §2.3 ("Prevent SNI-based
Denial of Service Attacks"). §6 appears to claim that this is OK
because it is not an asymmetric operation, though. How many
symmetric trial decryptions can we expect a Fronting server to
perform for each incoming Client Hello before it amounts to a DoS
threat?
* §5.1 (Session resumption with combined tickets) "as follow:" → "as
follows:" and "three of requirements" → "three requirements"
* §5.2 (New Combined Session Ticket)
It's not clear what specifically is impractical about the hidden
server encrypting its tickets with the public key of the fronting
server, or on which hops those tickets are encrypted. That
parenthetical aside probably needs to either be fleshed out more or
dropped, since as it stands it seems like it adds confusion.
"stateful design" sounds like the traditional TLS "session ID", but
with some coordination between Hidden and Fronting servers so that
there is no session ID collision between the two. Is it worth
describing in this way explicitly? Perhaps the "stateful design" and
"shared key design" should be broken out as separate subsections for
clarity.
"When the client reconnects to the fronting server, it decrypts" →
"When the client reconnects to the fronting server, the fronting
server decrypts"
"CH" → "Client Hello"
"to hides behind" → "to hide behind"
"Frinting Service" → "Fronting Service"
* §5.3 (First session)
"directly connects to" → "directly connect to"
"and then asks for" → "and then ask for"
"exposes clients to" → "exposes the client to"
It's unclear what is meant by "the second Client Hello can be sent as
0-RTT data" here. It sounds more like this refers to §4 than to the
shared ticket approach. Do you maybe mean "subsequent Client Hello",
as in "the Client Hello that contains the shared ticket"? If so, why
mention 0-RTT data?
* §6.1 (Replay attacks and side channels)
This section starts by claiming to address §2.1 ("replay attacks") but
is mainly about side channels observable by a global netowrk
adversary, which are not mentioned in §2 at all. In prior sections,
the adversary appears to have the capacity to monitor the link
between the client and the fronting server. This section apparently
expands the scope of the adversary's monitoring capacity.
"adversaries cannot receive" → "adversaries cannot decrypt"
"Adversaries can associate" → "An adversary capable of observing all
network traffic at the fronting server can associate"
"the setting of a connection to" → "the TCP handshake between the
fronting server and"
This section doesn't clearly describe what an acceptable, leak-free
alternative would be.
* §6.3 (Forward Secrecy)
The final paragraph of this section refers to the "encapsulation
protocol", which i think is the proposal in §4. However, the
paragraph mentions K_sni, which is only relevant to the "combined
ticket" proposal from §5. This is confusing guidance, unless we plan
to implement a combination of the plans. Maybe the final paragraph
is meant to refer to "implementations of the combined ticket
protocol" instead of "implementations of the TLS encapsulation
protocol"?
The guidance to rotate K_sni frequently is constrained by "If they do
rely STEK-protected tickets" -- why should that be relevant to the
forward secrecy of the SNI information? Shouldn't the recommendation
to rotate (and destroy old copies) K_sni frequently be made without
reservation if the goal is to promote forward secrecy?
OK, i think that's it from me for now, sorry that it's such a long note,
and that it's later than i meant it to be.
--dkg
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
