On 10/14/2013 03:43 PM, Stephen Kent wrote: > Avri, >> ... ... >> So while I can see problems with MTU, I think genuine MTI (and perhaps >> some MTU) is needed for privacy enhancements at a level that matches >> the MTIs and MTUs for security. I technical neutrality requires it. > To first order, we're in agreement, i.e., MTI provides a reasonable > basis for deploying privacy > measures when users and service providers choose to make use of them. If > we fail to provide > MTI options, we deprive users and providers of the ability to engage in > interoperable > security/privacy measures. > > The question Stephen raised is whether that's enough. For me, the answer > is yes, and going > beyond MTI to MTU is pursuing an "evangelical" path that we ought to avoid.
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. > Since you alluded to "some MTU" above, the obvious question is what are > examples of > MTU mechanisms that you support? 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 > > 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
