Re: [perpass] Howdy!

[Dean Willis <[e-mail]>]

On Sep 2, 2013, at 1:55 PM, Stephen Farrell <[e-mail]> wrote:

> 
> So, given you've been thinking about this for maybe longer than most
> I'm wondering if you have any specific protocol changes or additions
> you'd suggest, or descriptions of new threat models that could be useful
> to WGs developing or maintaining protocols? IMO, things like that would
> be most useful for now.
> 

I think there are a couple of principles that we need to adopt IETF-wide.

Part of the definition of "good Internet citizen" for a protocol or application is that not only does that protocol/application include anti-surveillance principles for itself, but that it helps OTHER protocols avoid surveillance. Surveillance-resistance is MORE IMPORTANT than optimizing transport efficiency.

So, a couple of rules, probably badly organized:

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. Older protocol specs still in use should be revised to require encryption. Deprecate the non "s" versions of protocols.

2) Well-known ports should be avoided. Or overloaded to the point where the port number is no longer a significant indicator to the application. This gives rise to the "everything over 443" mentality, which we need to find a way to handle gracefully. Demuxing the service within the channel is a better idea than I used to think.

3) Packet sizes should be variable, preferably random. This is the opposite of the "discover the MTU and fill every packet" model of efficiency. Or, we could make all packets the same fixed size by padding small ones. I like random better, but there might well be some hardware optimizations around fixed packet sizes.

4) Every protocol spec needs to include a pseudonymous usage model, and most should include an anonymous usage model.

5) New protocols should be built around end-to-end crypto rather than relying on transport-level wrappers for everything. It's too easy to use a compromised CA-cert to dynamically build a TLS proxy cert. Some level of key delivery out-of-band, coupled to in-band footprint verification, is probably needed. zRTP is a good model.

6) Randomizing interpacket timing is useful. This does all sorts of horrible things to both TCP optimization and the jitter buffers in real-time communications. But it's worth it. Remember, surveillance-resistance is MORE IMPORTANT than efficiency.

7) Peer-to-peer, DTN, and peer-relay (TURN, for example) all have lessons we should learn. So does TOR.

8) Every piece of crypto-advice needs serious, multiparty, international, and aggressive review. No more documents authored by NSA shills (which Schneier says we seem to have).

--
Dean