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

Martin,

I disagree.

1. The user can decide to force TLS 1.3
2. The attack that you describe requires active packet injection. We just
increased the cost for the attacker from passive recording of data to
active packet injection. Active packet injection does not scale and is
detectable. The proposed solution solves pervasive surveillance. That's the
goal.

I hear you loud and clear that you wish for a protocol where the SNI is
transmitted encrypted _and_ without the attacker
being able to reveal the SNI during an active attack. I'm certain that a
proposal by you of how to do this would be highly appreciated and
educational to the readers.

regards,

ralf

On Tue, Nov 12, 2013 at 6:50 PM, Martin Rex <mrex@sap.com> wrote:

> Daniel Kahn Gillmor wrote:
>
> Checking application/pgp-signature: FAILURE
> -- Start of PGP signed section.
> [ Charset UTF-8 unsupported, converting... ]
> > On 11/12/2013 09:13 AM, Phillip Hallam-Baker wrote:
> > > What am I missing here, how do you turn on encryption before the client
> > > sees the encryption credential.
> >
> > e.g. using a PFS key exchange, you could include the SNI data after the
> > key negotiation, but before the server certificate. (i think this
> > introduces an extra round trip)
> >
> > > Sure you could soft encrypt under a non authenticated key, but that
> does
> > > not provide a lot of security.
> >
> > it provides confidentiality in the face of a passive attacker, which is
> > specifically what is being asked for.  I think it's clear that this
> > information is not possible to hide from an active attacker who is
> > willing to cause connection failures to find out the name of the server
> > the client is trying to reach.
>
> 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.
>
> A single connection failure per client&server pair per day would be
> sufficient to elicit cleartext SNIs from clients & cleartext certificates
> from servers.
>
> 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.
>
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>