Martin Rex's comments - Githubissues

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 INTHECLEAR 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.

On Wed, Oct 17, 2018 at 10:03 AM Martin Rex wrote:

Sean Turner <sean at sn3rd.com> 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.

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

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.

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

  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 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..

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

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

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).

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

Eric Rescorla wrote:

Martin Rex wrote:

Sean Turner 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.

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.

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.

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.

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 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.

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.

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

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

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:

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.

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).

This isn't really correct: the mechanism for encrypting SNI itself would 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

On Wed, Oct 17, 2018 at 4:41 PM Martin Rex wrote:

Eric Rescorla <ekr at rtfm.com> wrote:
> Martin Rex <mrex at sap.com> wrote:
>
> > Sean Turner <sean at sn3rd.com> 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.
> >
>
> 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.

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

>> 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.
>
> 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.

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.

From: David Fifield

On Wed, Oct 17, 2018 at 07:25:38PM -0700, Eric Rescorla wrote:

>> 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.
>
> 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.
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.

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"

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

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

From: Geoffrey Keating

mrex at sap.com (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.

tlswg / sniencryption

Martin Rex's comments #23