Re: [TLS] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-02.txt

[Daniel Kahn Gillmor <[e-mail]>]

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