Hi Dean, My bet would be that some some but not all of those might fly.
Others opinions? S. On 09/06/2013 02:23 AM, Dean Willis wrote: > > On Sep 2, 2013, at 1:55 PM, Stephen Farrell <[email protected]> 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 > > > > > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
