Hi Steve, On 10/09/2013 06:22 PM, Stephen Kent wrote: > Stephen, > > Thanks for creating a new thread to discuss this topic. It's a good > starting point for > > an important discussion.
I agree its important. > I think MTU (vs. MTI) is a very hard argument to make, for several reasons, > some of which I noted in my response to Dean. Well, MTU vs MTI is not quite what the subject line says, but is clearly one of the options worth discussing. > Internet protocols are used in a very, very wide range of contexts, > e.g., enterprises of various sorts, the IoT, and public environments. In > principle one ought to make decisions about what security measures to > deploy and enable based on a perception of threat. Threats differ in > different contexts. Our current, MTI-based approach to security enables > responsible parties in each environment to make decisions about what > security to offer based on perceived threats and tradeoffs, e.g., > performance, processing overhead, user experience, etc. All good. > I admit that, in my experience, very few parties appear to make such > decisions in a well thought-out fashion, but they could. That's the catch though isn't it? They don't, for whatever reason(s) as seems to be shown by the SIP discussion. I conclude that that means we're doing something wrong. (Maybe we're not the only ones doing something wrong, but I do think we contribute to the problem.) > Suggesting that > we can make such decisions for the folks who are ultimately responsible > for the operation of services in a wide range of contexts strikes me > hubristic. Hmm. But we're happy enough to suggest that URI scheme names can't contain a ":" and as a more relevant example, we don't have a problem that web sockets requires a Sec-WebSocket-Key header. So I don't buy the "we can't do that" argument to be honest. > We've already made concessions for the Smart Grid context in the case of > IPsec as MTI for IPv6. To me this suggests that we were persuaded that > even MTI can be a barrier to adoption and deployment in some contexts. But on the other hand maybe we were wrong there. Not sure myself. > Pursuing a single set of MTUstandards for a wide range of contexts seems > doomed to failure. Perhaps. But I'm not sure what a "single set of MTUstandards" means to be honest. If we did have consensus for more than MTI then we could clearly mess up in loads of ways;-) > Generating MTU RFCs for various contexts might be an > alternative. That would imply MTI protocol standards, augmented with > BCPs. Is that what you envision? Could be. Defo worth thinking about. Be great if folks had some suggestions for situations where that might produce a better outcome than we have today. > Evaluating tradeoffs of security and privacy vs. other factors is hard > when one deals with a wide range of contexts. For example, end user > devices range from big servers to laptops, to tablets, to smart phones. > Battery use if a big issue for some of these devices, as is bandwidth. > Some of the more extreme TFS mechanisms discussed would have adverse > implications for both. That's an example of why MTU, at the protocol > spec levelk, > strikes me as a bad idea. Hm. I don't see why that applies to just this aspect of protocol development. Sure, crypto involves some more CPU but that's not that big a deal (far less than having the radio on in a challenged device) and some round-trips which turns out to be a problem in unchallenged-envirionments. > There are a lot of middleboxes in the Internet. I am no fan of them; I'm > a true believer in the e-t-e model for everything, not just security. > But middleboxes are a fact of life and they exist because the folks who > purchase equipment and offer services have found them to be operational > necessities. Middleboxes provide ways to deal with backward > compatibility and migration issues, broken implementations from vendors, > security services for enterprises, network traffic engineering, etc. I'm surprised that you're convinced by the existence of bad practice:-) But yes, middleboxes are there and we can't ignore that. > If > we argue that security against widespread nation-state surveillance is > more important than all of these other considerations, I think we risk > having the IETF be described as out of touch with reality. Equally, if we ignored pervasive monitoring, we'd actaully be out of touch with reality. But there are definite trade-offs here. Its entirely true that we can't improve privacy without affecting other things. One of my conclusions from recent revelations is that we've not done a good enough job on privacy so fixing that will involve such trade-offs if we're serious about it and not just pretending. S. > > Steve > > > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
