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

[[e-mail] (Martin Rex)]

Eric Rescorla <[e-mail]> wrote:
> Martin Rex <[e-mail]> wrote:
> 
> > Sean Turner <[e-mail]> 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:

   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