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.
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 :-) .
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.
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?
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.
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.
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.
Steve
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass
