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