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

[Daniel Kahn Gillmor <[e-mail]>]

On 11/12/2013 01:50 PM, Martin Rex wrote:
> Browsers perform the reconnect fallback failures transparently and
> silently, and NSA hat their Foxacid servers in place to shoot down
> any TLSv1.3 requests they like with a TCP RST.

I note that you're talking about an active attacker here.

But in general, yes, any tool that silently performs a fallback to an
older version will not get any of the security enhancements offered by a
newer version.  This doesn't mewn we shouldn't try to add any security
enhancements to newer versions, though.  It means we should try to
figure out ways to discourage fallback, or to identify and isolate and
expose peers who require these fallback mechanisms.

> A single connection failure per client&server pair per day would be
> sufficient to elicit cleartext SNIs from clients & cleartext certificates
> from servers.

Yes, it would, i agree.  These mechanisms seem unlikely to protect the
requested identity of the server in the face of an active attacker.  If
we assume that the client has never connected to the server before (i.e.
no pre-cached server public keys, etc), then i don't see any way to
design a protocol that could hide the identity of the party that the
client is trying to reach from an active attacker who is willing to
cause connection failures.  Do you?

> We should design our protocol to provide security in a robust and
> resilient fashion, not in a brittle "weather permitting" fashion
> that is being suggested.

That's exactly what this discussion is trying to do.  It's clear that
the current SNI mechanism always leaks the requested server identity to
anyone on the network path.  The proposal to encrypt it with keys
derived from the as-yet-unauthenticated DH exchange will hide this
information from any passive attacker on the network path.  It even
allows the client to detect a failed connection (and possible requested
server name leak) when an active attacker attempts a MITM.  These are
both a clear improvements over the current situation.

If you have a proposal for a way to hide this information from everyone
on the network path, including active attackers who are willing to cause
connection failures, that would be an even better improvement.

	--dkg