Hiya, On 10/10/2013 07:49 PM, Stephen Kent wrote: > Stephen, >> Well, MTU vs MTI is not quite what the subject line says, but is >> clearly one of the options worth discussing. > I thought that was the focus, based on the subject line. Sorry.
Partly my fault, but I reckon there should be more options than just an MTI->MTU transition. For example, requiring BCPs as you suggested, or maybe requiring (some) security be on-by-default in some cases or lots of other things. I'm hoping to get folks suggestions and opinions (so please send yours!) >>> 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. > In my experience, enterprise IT folks want to deploy a "solution" > that has low capital cost and low cost to maintain, and that is > perceived as 'best practice" relative to their industry. This is > consistent with some of Dean's observations. Being truly effective > against legitimate threats often is not on their checklist :-) . Yup. Veniality does win sometimes;-) >> 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.) > I don 't think we're doing anything wrong; we're makers of standards, > not enforcers of good security practices for every business, academic > institution, service provider, and individual user of the Internet. I disagree. IMO all the snowdonia stuff is very good evidence that we need to do better. And "enforcer" is not at issue. >> 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. > Sorry, but I don't see the analogy. These are MTI examples, and the first > is a technical compatibility issue, right? And the 2nd. But the 2nd is a case where there's a teeny bit of crypto baked into websockets so that websockets just doesn't work without it. But not one to rathole on. >> 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;-) > By "single set" I mean MTUs that apply to a standard irrespective > of its use context. Ack. >>> 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. > Fair point; tradeoffs are part of every protocol design, not just > security vs. X tradeoffs. I think that we usually have adequate IETF > participation by folks who are well-positioned to analyze _most_ > protocol design > tradeoffs. However, we have some significant examples where that has not > been true. > The first DNSSEC design, approved as a set of RFCs, was not workable. We > had to > try again, and that cost us several years of effort. I am not convinced > that we > have the right set of folks participating to design sweeping changes > that _mandate _ > use of security mechanisms that are good enough to deal with nation > state surveillance. Going back to a mail from Yoav a few weeks ago - we're not trying to prevent state surveillance, but we would like to make it more expensive so Yoav isn't on the list of folks that they can afford to surveil. Assuming we share that description as a goal, (do we?) what other kind of folks do you think we might need to make progress on that? >> Equally, if we ignored pervasive monitoring, we'd actaully be out of >> touch with reality. > For a long time the IETF has offered security mechanisms that can be > used to protect a wide range of users against a broad spectrum of attacks. > We know that use of many of these mechanisms is very minimal in many > (most?) contexts. > How does that experience justify mandating _use_ of additional, new > mechanisms? > Let's not assume that the concern over pervasive monitoring that is > triggering our discussions, and which is well-represented on this list, is > necessarily representative of the concerns (priorities) of most users. When > folks stop posting TMI info on Facebook, updating their locations via > social media, and give up many, many other privacy-undermining habits, > then I'll > be ready to believe that their priorities have shifted. There is a fair point there but dealing with what people do on FB is not really within the IETF's scope I think. Making it harder for a few hacked nodes to record everything everyone does is though. (And if we can do that well, I suspect we'll get a bunch of other security benefits too.) And there's also the user-consent issue - regardless of what one thinks about web site T&C, it is absolutely the case that users have not given permission for the pervasive monitoring that's been reported. Cheers, S. > > Steve > _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass
