Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3

[[e-mail] (Martin Rex)]

Ralf Skyper Kaiser wrote:
> 
> On Fri, Nov 8, 2013 at 5:02 AM, Martin Rex <[e-mail]> wrote:
> >
> > Don't fix it if it ain't broken.
> > SNI was specifically DESIGNED to convey the server name in the clear.
> 
> SNI was NOT DESIGNED to be convey the server name in clear. SNI was
> designed so that the server can pick the right certificate.

SNI was DESIGNED to be in the clear.  In our server implementation,
I have implemented the server-side of SNI only at the application
level, not in the TLS protocol stack, i.e. I select the credential
that is used to perform the TLS handshake _before_ I start the
handshake.


> 
> SNI can be transmitted encrypted and should be transmitted encrypted (see
> recent plenary sessions at IETF88).

What you seem to want to do is not SNI, but something else.


> 
> Martin, with your argument why should we fix anything at all in any product
> or design?

Don't fix it if it ain't broken.  SNI is not broken.


> 
> The proposed solution FIXES passive pervasive surveillance in TLS 1.3.

This is going to be a waste of energy that is only making things
more complex, but neither better nor more secure.


> 
> Let's make pervasive passive surveillance harder.

To me, this is self-illusion.  Why should NSA look at SNI at all?
They're collecting meta-data based on information that is always present
and necessary for the communication to succeed at all.  There are still
lots of clients around which do not send SNI.  And you could send crap
in SNI to servers that don't implement or use SNI, but I strongly doubt
that you would confuse XKeyScore by doing this.


-Martin