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. 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.
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"
Steve
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
