Re: [perpass] Howdy!

[Jacob Appelbaum <[e-mail]>]

Theodore Ts'o:
> On Tue, Sep 10, 2013 at 09:43:39PM +0300, Hannes Tschofenig wrote:
>>
>>> 1) Everything SHOULD be encrypted, unless there is an absolute
>> operational requirement not to. This means "encryption by default"
>> in new protocols, and not even specifying unencrypted operations
>> modes unless necessary....
>>
>> I guess there are two issues here, namely:
>>
>>  * End-to-end vs. Hop-by-hop (or stuff in between)
>>
>>  * Encryption itself is often not the problem but rather the key management
> 
> Also, perfect forward secrecy (PFS) versus non-PFS.  If we are going
> to make encryption a SHOULD or a MUST, so should be PFS.  Even if the
> key management is a problem, or worse, let's suppose the NSA has the
> private keys for a number of the major CA's, if everything is using
> PFS, then an attacker who is interested in doing bulk surveillance
> will have to MITM all of the traffic.  That will take a large amount
> of power and cooling, so it becomes a lot more expensive to do bulk
> surveillance, and it will also be much, MUCH harder to do it covertly
> (you can't just hide a box in a telephone closet somewhere; but rather
> racks and racks of servers at Tier 1 NAP's will be required).
> 

I completely agree. I think that MUST is a reasonable requirement for
core internet protocols.

> OF course, there will be some things where encryption is simply not
> needed, and but data integrity is is needed.  Example: time (NTP) and
> routing protocols.   So we need to be careful how we specify MUST.  :-)
> 

I think this is a reasonable read but I'd like to encourage dissent
here. Time is a very important part of almost all cryptographic
protocols - if an attacker is able to distinguish queries about time
from other queries, it allows the attacker to discriminate and thus to
tamper with time related protocols. This is especially true when the
system in question may not have a properly sync'ed clock.

I hacked together a solution for network time that gives most of these
properties - tlsdate ( https://github.com/ioerror/tlsdate/ ) - and it is
used by ChromeOS rather than using the traditional NTP protocol. It has
some downsides (32bit time rather than 64bit time resolution) but
overall, it allows for all of the properties of TLS without any of the
weird downsides of the ancient NTP protocol, of which there are many...

As an example - DNSSEC requires a sync'ed clock and in theory, one
argument goes: no one needs query privacy in DNSSEC, after all, one just
connects directly so an attacker will learn what you learned anyway,
right? However, one needs query privacy to ensure that an attacker
cannot tell that your DNSSEC client is currently trying to learn the
time, thus all other queries are vulnerable to a replay attack or worse.
So really, query privacy, even for data that appears to only need
integrity is really essential. Give the attackers nothing for free -
make them tamper to get even a single bit of information more. This
gives us agency to detect and to take counter actions.

All the best,
Jacob