Subject: [TLS] WGLC for draft-ietf-tls-sni-encryption

From: Sean Turner <[email-masked]>
Date: Tue, 16 Oct 2018 18:43:05 -0400

All,

This is the working group last call for the "Issues and Requirements for SNI Encryption in TLS" draft available at http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/.  Please review the document and send your comments to the list by 2359 UTC on 31 October 2018.

Thanks your chairs: C-J-S

---

From: Sean Turner <[email-masked]>
Date: Tue, 16 Oct 2018 19:03:42 -0400

All,

I ran I-D nits before hitting the appropriate buttons to place this draft in WGLC.  I figured we could address the following before we send the draft to Ben:

  == Outdated reference: draft-ietf-tls-tls13 has been
       published as RFC 8446

  == Outdated reference: A later version (-14) exists of
       draft-ietf-doh-dns-over-https-08

  == Outdated reference: A later version (-15) exists of
       draft-ietf-quic-tls-11

  == Outdated reference: A later version (-28) exists of
       draft-ietf-tls-dtls13-26

  == Outdated reference: draft-mm-wg-effect-encrypt has
       been published as RFC 8404

To answer the other 5 I-D nits questions "Obsolete informational reference (is this intentional?)” - the answer is yes.

spt

> On Oct 16, 2018, at 18:43, Sean Turner <[email-masked]> wrote:
> 
> All,
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Oct 2018 10:58:58 +1100

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"

On Wed, Oct 17, 2018 at 10:04 AM Sean Turner <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Oct 2018 16:24:10 +0100

Hiya,

I think this is more-or-less ready and I support
publication. My comments below, none of which are
show-stoppers but they might be worth a look.

Cheers,
S.

1. Shouldn't there be some mention of CT here somewhere?
Say if we have a good solution, but the hidden service's
cert is in CT logs, then an adversary can find those, and
see what it gets from DNS for those names (from different
vantage points) and how that correlates with addresses.
And if the certs for hidden services are special in any
way, that gets worse. (Implying that we don't want the
certs for the hidden services to be special in any way I
guess?)

2. HTTP fronting - I guess the situation has changed a bit
with respect to this over the time that the draft has been
evolving. Do we want to note that?

3. As a process-issue, I'm not sure if it'd be better or
worse to send this for publication now or wait until the
esni work has progressed some more. I don't mind either
way myself, but I guess the question'll be asked if we do
shoot it forward now, (given that some people apparently
dislike this kind of RFC;-). It'd be no harm to have the
answer on the list if that's the plan - so why publish
now, given that esni is under development?

nits:

- abstract: might be worth saying that we don't expect
solutions to necessarily meet all requirements here.
(That's stated in the security considerations, but could
be worth adding here.)

- 2.1: is it worth noting debugging tools like wireshark
here?

- 2.2: Are all of the things mentioned in 2.1 "abuses"?
I'm not sure everyone would agree. It might be worth doing
s/abuses/uses and abuses/ here to avoid a fuss at IETF LC
time.

- 2.2: "make it much harder" is maybe overstated?

- 3.4: There's the inevitable issue with not sticking out.
That being that it tends to increase the centralisation of
the Internet, in this case reducing the number of entities
to which pressure needs to be applied by the adversary.
Worth a mention here?

---

From: [email-masked] (Martin Rex)
Date: Wed, 17 Oct 2018 19:02:36 +0200 (CEST)

Sean Turner <[email-masked]> wrote:
>
> This is the working group last call for the
> "Issues and Requirements for SNI Encryption in TLS"
> draft available at
> http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/.
> Please review the document and send your comments to the list
> by 2359 UTC on 31 October 2018.

I think the idea of encrypted SNI is inherently flawed in its concept.

If anyone really thinks that there should be a scheme where a server's
hostname is no longer transfered in a cleartext (including TLS extension SNI),
then first of all a *NEW* distinct URI method should be defined for that
purpose,  e.g. "httph://"  as a reliable indicator to the client processing
this URI, that the hostname from this URI is not supposed to be sent
over the wire in the clear *anywhere*.

As it is, there are a number of servers which desperately require
the presence of TLS extension SNI, or will fail TLS handshakes either
by choking and dropping connections (Microsoft IIS 8.5+) or by
very unhelpful alerts (several others), and also HTTP/2.0 requires
unconditional cleartext presence of TLS extension SNI.  Any kind of
heuristics-based approach for clients to guess whether or not to
send TLS extension SNI is flawed from the start.  If a network
middlebox can make a client present a cleartext TLS extension SNI
by refusing connections without cleartext TLS extension SNI,
the entire effort becomes pretty useless.  It is necessary
that the client knows reliably that a hostname must not be sent
in the clear, including when the connection fails for unknown reasons,
and only a new URI method will reliably provide such a clear distinction.

I also believe the draft is contains flawed assumptions and
misleading descriptions of facts and history.

e.g. Section 2.2

   "The common name component of the server certificate generally exposes
    the same name as the SNI.  In TLS versions 1.0 [RFC2246], 1.1
    [RFC4346], and 1.2 [RFC5246]""

SubjectAltName attributes, unless you were hiding under some stone with
no internet acces for more than a decade...

rfc2818 "HTTP over TLS" section 3.1 "Server Endpoint Identification"
described retroactively, what kind of name matching TLS clients Browsers
were doing -- and what all TLS clients are supposed to be doing on a
TLS server certificate.

     https://tools.ietf.org/html/rfc2818#section-3

This approach was recommended for use in other protocols besides
HTTP over TLS by RFC 6125.

By sending TLS extension SNI in the clear to a server, the client
tells that server:  I am going to perform an rfc2818 "HTTP over TLS"
section 3.1 "Server Endpoint Identification" matching -- and if you
have several different TLS server certificates to choose from,
you better send me one that is going to succeed this specific matching,
which I am going to perform on your TLS ServerCertificate response.

The TLS server certificate could only be conveyed *IN*THE*CLEAR* in SSLv3,
could be conveyed only in the clear in TLSv1.0, when TLS extension SNI was
proposed in rfc3546 to allow virtual hosting from HTTP to work with HTTPS,
and could be conveyed only in the clear in TLSv1.2, when SNI was rev'ed
by rfc6066.

In protocol version SSLv3->TLSv1.2, encryption keys are only established
*AFTER* successful authentication of the server through its server
certificate. So it was obviously impossible to encrypt the information
whose only purpose it was to allow the server to decide *which* TLS Server
certificate to use for authentication (hen-and-egg).

DH_anon cipher suites do not have a server certificate handshake message,
and they are well-known to be completely insecure to man-in-the-middle
attacks anyways, which is why TLSv1.2 (rfc5246) says this about them:

   The following cipher suites are used for completely anonymous
   Diffie-Hellman communications in which neither party is
   authenticated.  Note that this mode is vulnerable to man-in-the-
   middle attacks.  Using this mode therefore is of limited use: These
   cipher suites MUST NOT be used by TLS 1.2 implementations unless the
   application layer has specifically requested to allow anonymous key
   exchange.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Oct 2018 15:10:52 -0700

> I think the idea of encrypted SNI is inherently flawed in its concept.

It's pretty late to raise this point as we've had repeated consensus calls
to
work on this.
If anyone really thinks that there should be a scheme where a server's

> over the wire in the clear *anywhere*
>

> the entire effort becomes pretty useless.

Yes, clients must not fall back to cleartext SNI in this case.

  It is necessary
> and only a new URI method will reliably provide such a clear distinction.

I don't agree with this claim, given that we have a number of other proposed
mechanisms for the client to know when ESNI is allowed, including DNS.
It's true that middleboxes might block these requests, but
https://tools.ietf.org/html/draft-ietf-tls-esni-01#section-6.2 has some
material on this. Comments welcome. In any case, I don't see why
a URI is better than DNS in this case..

> section 3.1 "Server Endpoint Identification" matching

I don't know where you get this from, given that RFC 6066 doesn't
even cite 2818.

> certificate to use for authentication (hen-and-egg).

This isn't really correct: the mechanism for encrypting SNI itself would
actually work
fine in previous versions of TLS as well. It's just that you don't encrypt
the *certificate* so that it wouldn't be useful

-Ekr

---

From: [email-masked] (Martin Rex)
Date: Thu, 18 Oct 2018 01:41:10 +0200 (CEST)

Eric Rescorla <[email-masked]> wrote:
> Martin Rex <[email-masked]> wrote:
> 
> It's pretty late to raise this point

Nope, I've raised this *EVERY* time on the list when the dead horse was
newly beaten.

> Yes, clients must not fall back to cleartext SNI in this case.

Please give a clear deterministic algorithm how a client can
tell apart a server that requires cleartext SNI from a server
that does not want cleartext SNI.

> mechanisms for the client to know when ESNI is allowed, including DNS.

DNS is a non-starter for several reasons.

Ever heard of firewalled networks, private DNS universes and HTTP CONNECT
proxies?

Then the TLS implementation itself may be completely free of blocking
network IO.  

> I don't know where you get this from, given that RFC 6066 doesn't

Simply to avoid a downref.  I should not have to explain this to you.

rfc2818, section 3.1:

   3.1.  Server Identity

   In general, HTTP/TLS requests are generated by dereferencing a URI.
   As a consequence, the hostname for the server is known to the client.
   If the hostname is available, the client MUST check it against the
   server's identity as presented in the server's Certificate message,
   in order to prevent man-in-the-middle attacks.

rfc6066, section 3:

   3.  Server Name Indication

   TLS does not provide a mechanism for a client to tell a server the
   name of the server it is contacting.  It may be desirable for clients
   to provide this information to facilitate secure connections to
   servers that host multiple 'virtual' servers at a single underlying
   network address.

It looks blatantly obvious to me that
  rfc2818:  "check the hostname of the server agains the server's identity
             as presented in the server's Certifcate messag"
and
  rfc6066:  "a mechanism for a client to tell a server the name of the server
             it is contacting"

refers to the VERY SAME THING, and that the check urged by rfc2818 section 3.1
is the reason why the server responding with the _wrong_ certificate is
a problem.

> actually work fine in previous versions of TLS as well.

Actually, no, it will not work at all in TLSv1.2
(this would not be TLSv1.2 anymore, or an entirely different TLS extension)

My server-side implementation of TLS extension SNI is entirely outside
of the TLS protocol stack.  My middleware selects the Server certificate,
and my middleware also provides the convenience function for rfc2818
section 3.1 server endpoint identification as well as the client-side
SSL session cache management, because you essentially can not do this
within TLS, and rfc5246 even clearly says, your implementatin shouldn't
(acutally it is pretty close to a TLS must not, rfc5246, top of page 5):

                        The TLS standard, however, does not specify how
   protocols add security with TLS; the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Oct 2018 19:25:38 -0700

> Nope, I've raised this *EVERY* time on the list when the dead horse was

And there have been multiple consensus calls to the contrary, so this
is just re-raising a decided issue.

> that does not want cleartext SNI.

This isn't really the relevant question, as there are many servers
now which do not require SNI.

The relevant question is how a client can be made aware that
a server does support ESNI and can have high confidence that
it will accept it. Such an algorithm is provided in:
https://tools.ietf.org/html/draft-ietf-tls-esni-01#section-4

Note that as explained in detail, it is not necessary that all clients
send ESNI to that server.

> Ever heard of firewalled networks, private DNS universes and HTTP CONNECT

Yes, I've heard of all of these. They're not relevant to the question at
hand.

>   rfc6066:  "a mechanism for a client to tell a server the name of the

It may be obvious to you, but I don't believe it's correct. For instance,
the server might be using some form of certificates other than X.509.

> of the TLS protocol stack.

This is actually quite compatible with the encrypted SNI mechanism
specified in draft-ietf-tls-esni, because it was designed to work
with split architectures.

-Ekr

---

From: Geoffrey Keating <[email-masked]>
Date: 17 Oct 2018 20:09:11 -0700

[email-masked] (Martin Rex) writes:

> If anyone really thinks that there should be a scheme where a
> server's hostname is no longer transfered in a cleartext (including
> TLS extension SNI), then first of all a *NEW* distinct URI method
> should be defined for that purpose, e.g. "httph://" as a reliable
> indicator to the client processing this URI, that the hostname from
> this URI is not supposed to be sent over the wire in the clear
> *anywhere*.

Although I can see how this, or some other mechanism, might be helpful,
I don't agree it has to happen *first*.  Why can we not start by providing
an ESNI mechanism, and then later standardize a mechanism to require it
for particular hostnames?

A limited-purpose client can just require TLS 1.3 and ESNI for all
connections, so such a mechanism would not be required for that
client.  In the future TLS 1.3 and ESNI deployment may be sufficiently
widespread that all clients could require them, making the mechanism
unnecessary.

Even if ESNI is opportunistic and so subject to active attacks, that
still eliminates passive network sniffing.  Even an active attack
would not (I think) lead to a successful connection, because of the
TLS anti-downgrade features, with consequences including user-visible
error messages or the device deciding the network is non-functional
and ceasing to use it, so although some hostnames may be revealed, the
user or device may stop before revealing all of them.  So ESNI is
still useful even if not mandatory.

---

From: David Fifield <[email-masked]>
Date: Thu, 18 Oct 2018 09:16:57 -0600

> send ESNI to that server.

Right -- it's not a matter of a server requiring or not requiring ESNI.
The way I understand it, a server that supports ESNI merely affords
clients an opportunity to better protect themselves -- it is still the
client's responsibility to resist downgrades, and to somehow discover
(through DNS or otherwise) that the server supports ESNI in the first
place. I imagine that most servers that support ESNI will continue to
simultaneously support plaintext SNI connections.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 18 Oct 2018 15:29:20 +0000

newly beaten.
  
And you were in the minority, the WG consensus has clearly been to work on this, despite your objections.