Hello,
...
This may be where we have a significant disagreement.
Note that I've no espoused any particular more-than-MTI
position so its not yet clear how you and I disagree
(on this one:-)
I must have misunderstood your comments (on this one :-) )
...
I get that argument. But what's the difference between that
and saying "don't use MD5" really? We're comfortable with
the latter since MD5 is just broken for collisions. I don't
see why we shouldn't be equally comfortable in saying "don't
send cleartext" - *if* that's an IETF consensus position - as
we have seen sending cleartext is also just broken when one
consideres pervasive monitoring.
Saying don't use a specific alg, because it's defective, is a mandate
within a context where users/providers have already decided to employ
a security mechanism. Saying"no cleartext" is a statement without that
context, and thus not analogous. Or, in a lighter analogy, in the first
case we know what kind of people we're talking about, and we're just
haggling over the algorithm ;-) .
In fact I don't really believe there's a crystal clear line
between protocol and policy in many cases, I think its blurrier
than is claimed by those who argue against more-than-MTI as
being beyond our remit, as you do.
There may some gray areas; when I asked Avri about this she demurred,
so we'll have to examine specific examples to make progress.
That doesn't by itself invalidate your basic position that MTI
is good enough of course, but personally I do think it means
that a more-than-MTI position could exist that is equally
as defensible as the status quo.
Again, we'll have to see what more-that-MIT positions are put
forth before we'll be able to resolve this speculation on both
of our parts.
...
Its not like 4301 and that draft is I think nearing LC and code
that does this (again I think) has been deployed, possibly widely,
though I think I do recall some part where one of the popular
browsers doesn't do the DTLS thing for data channels or some
such, so I'm not claiming its a perfect example, but it is a
real one. Again I'd be interested in hearing from folks who
were involved in that discussion or who know more about the
reality of rtcweb code and deployments.
In the RTCWEB case is the difference that "a major browser vendor" has
decided its good, so it's a done deal? Frankly I've become concerned,
recently,
that one major browser vendor has become very pushy about its ideas of
what is
best for everyone. Because that vendor also is an OS vendor, it's
influence seems outsized, to me. But that's a different rant.
But this is a real example where we are specifying more-than-MTI
for one important protocol already, I think that's unquestionable
frankly.
OK, and frankly, I think this is a questionable idea.
I just skimmed the I-D in question. It has over 80 MUSTs. Given the
rather poor
track record of browsers wrt security,I am amazed to see the following
text, in Section 3:
The basic assumption of this architecture is that network resources
exist in a hierarchy of trust, rooted in the browser, which serves as
the user's TRUSTED COMPUTING BASE (TCB).
I suspect that most IETF participants are not familiar with the term TCB
(and
there is no cite in the I-D), so they do not realize how odd this
statement seems
to those of who are familiar with the term.
I have a lot of respect for Eric, but ...
Steve
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
