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 _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
