Re: [perpass] Howdy!

[Stephen Kent <[e-mail]>]

Stephen,

Since you solicited feedback ...

We have had considerable, recent, experience with the need to avoid 
adding delay to a user's web experience (e.g., "Happy Eyeballs") in the 
v4/v6 transition context. Suggestions that we increase delay in favor of 
security are not likely to be well received by users or service providers.
>> 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.
given the quantity of meta-data (and personal data) collected by Google, 
Facebook,
and many other commercial entities, and the willingness of users to 
supply such data, it's hard to believe that most users would agree with 
this statement.
>> 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.
One of the reasons many enterprises decline to employ e-t-e encryption 
within their
nets is because it interferes with debugging and scanning of traffic for 
malware. While
I am in favor of mandatory to implement encryption for our protocols, 
mandatory to use
is not a good idea in all cases.
>> 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.
others have already noted that this is a bad idea from a protocol 
perspective. in an era when many folks try to minimize the number of 
round trips needed to provide a service to a user, this add to the 
total. again, while security folks might see this as attractive, I
doubt that many users and service providers wold agree.
>> 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.
we have long understood what it takes to provide TFS, and nobody has 
wanted to waste the bandwidth to do it properly. I doubt that this view 
has changed.
>> 4) Every protocol spec needs to include a pseudonymous usage model, and most should include an anonymous usage model.
Use of pseudonyms is applicable to very few of our protocols, and most 
of the ones where it
is applicable, it is already satisfied. Anonymous use, depending on the 
definition one
uses, may be easy or nearly impossible.
>> 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.
see comments above re #1.
>> 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.
not, it's not worth it. see comment above re #3.
>> 7) Peer-to-peer, DTN, and peer-relay (TURN, for example) all have lessons we should learn. So does TOR.
DTN is great for the interplanetary Internet. I prefer realtime 
performance for almost all of my Earth-bound Internet apps. I suspect 
other users fell the same way. P2P is fine
for some apps, but not all, maybe not even many.
>> 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).
I think we have generally good review for the algs we choose; we 
periodically review algs and key sizes and make revisions as deemed 
necessary. We have folks like David McGrew (Cisco) providing much of 
this expert review. I think we have operated in this mode for many years.

Steve