Sean Turner <s...@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.
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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
