Hi Steve, On 10/14/2013 06:39 PM, Stephen Kent wrote: > Stephen, > ... >> That's not an unreasonable answer. However, we do have to >> face the fact that a lot of times MTI stuff is just not >> used when you and I would probably argue that it really >> ought be used. It also not unreasonable to say that doing >> more-than-MTI won't fix that, but that's what I'd like >> to explore here. > 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 am comfortable > developing security/privacy mechanisms that users and providers may > choose to employ, because compliant implementations will make it > available in an > interoperable fashion. Insisting that a set of such mechanisms be employed, > seems beyond our remit. 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. 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. 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. >> Good question. Without saying I "support" it, rtcweb does mandate more >> than MTI for e.g. DTLS-SRTP - the current draft [1] says it MUST be >> offered as the default. I think I'd maybe "support" it more if I >> understood better what kind of key management will be behind that, >> which I don't yet, but its a data point for what a lot of folks think >> will be an important protocol that does take a more-than-MTI approach. >> Maybe someone who knows more about that can explain the reasoning >> behind that decision and whether they think it could or should be >> generalised? Other examples could be good too, esp if they're actually >> used and not just RFC 6919 text;-) S. [1] >> http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07#section-5.5 > > 6919's "MUST (but we know you won't) was motivated by security MUSTs in > a wide range of > docs. the RTCWEB doc isn't an RFC yet, so we'll have to see what > happens. Also, this is > an arch doc. As the author of 4301, the IPsec arch doc, I can attest > that very, very few > implementation are compliant with all of it's MUSTs. Implementors tend > to focus more on > bits on the wire than on other protocol "features" 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. But this is a real example where we are specifying more-than-MTI for one important protocol already, I think that's unquestionable frankly. S. > > Steve > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass
