On Sep 9, 2013, at 1:48 PM, Stephen Kent <[email protected]> wrote: > 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.
Too bad. We can try to minimize the impact, but a net that gets you killed because the wrong person heard you say the wrong thing is worse than one with slightly less bandwidth or temporal QoS. >>> 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. Perhaps. But unless one accepts it as a principle, one is doomed to build surveillance-friendly networks. >>> 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. I've been enterprise IT. And enterprise security. Most of their security problems come form their own people abusing the loopholes. Sure, the IT department is lazy. But once the "generally accepted best practices" require e2e, they'll play along. remember, corporate policies are driven by generally accepted best practices such as GAAP for accounting. Note that, at least under US law, the management of a corporation is subject to legal attacks from shareholders for losses related to the failure to deploy generally accepted best practices for information security. A listing of best practies is here: http://www.wpi.edu/academics/CCC/Policies/bestpractices.html Note that they're written by people like CDT (an officer of which edited our privacy RFC), NIST, and other bodies that we influence. An Internet BCP can go a long way in addressing these things. >>> 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. Everybody wants something for nothing. See Best Current Practices. >>> 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. Should it? Who funds BBN, anyhow? What's your motivation for making choices that increase surveillance? Yeah, that's an ad hominem attack . But we're going to get a lot of those, and need to have a great deal of confidence in our answers. "Nobody wants security" is probably not a good enough answer … Nor is "Security costs too much", especially until the costs have been more completely quantified -- including the costs of making systems that nobody will buy because they don't want to spill their guts to our friends at Meade. Even the least suspicion of pro-surveillance bias needs to be avoided for the results to be credible. >>> 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. Admittedly, the definition here is tricky. Plausible deniability only works for guilty-beyond-a-reasonable-doubt, which is missing in a number of domains. But there's a lot here we can do that we don't. >>> 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. Ah yes, the old "if we build E2E, nobody will use it" argument. I find that to be an extremely suspicious argument, but recognize it and its kin have, for many years, led us down a rabbit-warren of bad choices, resulting in the problem we have today. Get over it. >>> 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. respectfully, either you're playing for the other team, your value-system is inconsistent with mine (and consistent with that of a surveillance state), or both. If surveillance resistance weren't more important than security, we wouldn't have TOR. >>> 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. But the concepts of peer-validation, explicit (rather than hidden) intermediaries, >>> 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. Regrettably, and as a former Cisco employee, I can tell you that folks there also face certain pressures from state actors. I'm sure this is true of most folks. David may be a saint. He might be a devil. But as an external party lacking the expertise, I have no way of telling if his position is biased against my objectives. So unless we have widespread review, from people likely to be in the influence of multiple and conflicting actors, we really haven't had a review. How widespread? I'm not exactly sure -- but it means more than one review, from more than one company, from more than one sector, and from more than one nation-state at a minimum. Trust is really hard; our best substitute is a very widespread consensus. Arguably, the mode that we've operated in for many years has given us a rather bad current situation. Perhaps we should reassess "good enough". -- Dean
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
