Re: [TLS] Encrypted SNI

[Brian Sniffen <[e-mail]>]

Hanno Böck <[e-mail]> writes:

> So-called "Enterprise" infrastructure has delayed the work of this group
> for at least a year. Noone of the people creating that mess has reached
> out to this group to explain why they constantly break TLS - let alone
> apologize for it.
>
> I believe there's a large overlap of the actors breaking TLS with the
> actors who are worried about things like SNI encryption. I'm not sure I
> see any reason not to consider these actors as anything but opposed to
> the work of this group.

Whoah!  I've been involved for years specifically to ask for care about
encrypted SNI.  I don't know whether I break TLS; maybe opinions vary.
But my concerns have been specific:

First, at the engineering level, a requirement that servers do expensive
cryptographic work in response to a first packet *and* an inability to
charge that work to a user or application is a big problem.  It makes it
too hard for users or applications to share a server, or leads to levels
of address waste expensive even with IPv6.

If we're going to have 0RTT and 1RTT and TCP Fast Open and ECDHE... then
Encrypted SNI is a hard engineering problem! 

Second, at the architectural level, a serious question about whether
this actually helps anybody, and if so whom?  I think the case of the
Amnesty International worker in an oppressive dictatorship is almost
certainly *not* helped by this work---see my questions about how many
bits of security this provides against an adaptive adversary from this
morning---and would like some clarity that this is about inhibiting the
ISPs, from cafes through enterprises up to Comcast-TWC, from monkeying
with user sessions.  


My concerns at the engineering level have been welcomed, recognized,
validated, and addressed.  Not always exactly the way I'd like, but
absolutely addressed in a way that's appropriate and sincere.  I saw the
same with requests to re-insert RSA Kx late last year.  The PATIENT
folks have gotten a fair hearing.

My architectural concerns have been heard, somewhat less eagerly.  Some
participants, including our colleagues who are vendors to enterprises
and folks like Ben Schwartz, have been clear that they will not bring
all their motivations and evidence to the table.  I significantly
discount their arguments and expect others to do the same---but not to
zero.  It means we need to check their work as we go, or actually trust
them as people, but it *can't* be harder than keeping NSA/IA people on
CFRG!

Anyway, I think the PATIENT folks concerns about the engineering of TLS
1.3 have been heard, have been taken seriously, and have been
addressed---same as mine or yours.  What I've seen of the architectural
concerns leading to network-centric management and "tap" devices come
down to claims about changes in architecture being too expensive,
middleboxes being too expensive, changes to applications being too
expensive, and general citation of an architecture only a few years old
as immutable tradition.  Those claims have also been heard, plenty of
folks have respectfully and diligently combed through them for evidence,
and we've moved on.

I bet that's frustrating and frightening for the folks writing from a
world where those claims aren't faith-based---they're obvious.  They
don't need citation any more than "China is a country"[1] needs
citation.  Nonetheless, engineering conversations based on
data-supported arguments continue to be welcome.

-Brian


Footnotes: 
[1]  https://www.cia.gov/library/publications/the-world-factbook/geos/ch.html
     but see also https://www.cia.gov/library/publications/the-world-factbook/geos/tw.html

-- 
Brian Sniffen