Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Aaron Zauner <[e-mail]>]

Hi *,

Jacob Appelbaum wrote:
> I'm sorry but that analysis is just not a serious and rigorous analysis.

No it's not. It's a very short presentation from a TLS-WG interim
meeting. The threat-model concerns Akamai's (and other's) current and -
possibly - future use of TLS. We're not trying to build an Onion routing
protocol. Given the FUD on the Tor dev list, this is a good thing. While
the presentation might have flaws from the perspective of an Onion
routing protocol developer, it reflects the point of view of a lot of
people/companies on this list, I assume.

> 
>> It's not just a collective action problem because DNS isn't encrypted too.
> 
> The conclusion summary is that because there are many problems, we
> won't address our part of the problems. The conclusion is that SNI
> privacy isn't worth it because those who live in liberal democracies
> with poor traffic analysis, well they just don't matter much. Which
> is... just... well, as I said above, I just don't take this seriously.

See above, different point of views on the same problem. I agree here
and think we should continue to find a proper solution for encrypted-SNI
for TLS 1.3 - if at all possible. What we currently have on our hands is
not very convincing to me.

> 
>> Their analysis also looks at what you get when both are encrypted. And
>> regardless of DNS being encrypted, rainbow-table style reverse lookups of
>> IP to DNS name are always possible. That doesn't mean encrypted SNI isn't
>> worth it -- it clearly provides a security attribute (confidentiality) to
>> an important piece of information.
> 
> You're now suggesting an attacker that computes rainbow-tables to
> arrive a possibility which in itself sounds like a massive improvement
> over what was an absolute certainty.

+1.

> 
>> I'm not advocating a strong stance on whether encrypted SNI is worth
>> pursuing, or whether TLS record headers should be encrypted in TLS 1.3. But
>> it's useful to keep the debate framed in its full context, rather than
>> narrowing it to a black-and-white discussion over whether a generally good
>> attribute is good or not.
> 
> Sure and that full context includes RFC 7258: "Pervasive Monitoring Is
> an Attack" - something that defines reasonably clearly many of the
> concerns I've stated.
> 

While kind of a political/policy document I agree that IETF WG's should
follow (and participants read) it. I remember the STRINT meeting in 2014
where a lot of people were very pissed about NSA activity and we decided
we want to do something about it. If it takes a standard a few months
longer to be finished, please give it the proper amount of time for
enough people to put their ideas into it. Most people do not come up
with solid engineering solutions over night. And crypto is hard as we
all know. We should not forget that TLS has a very different
threat-model and performance assumptions than Tor though.

Thanks,
Aaron