>
>The wider consequence, however, is not increased "epic invasion of
>privacy", as you state.
This isn't actually what I said; I said we currently see an epic invasion
of privacy and key compromise supports that. The meat of that section
of my email is probably:
"Hobbling a mechanism which can maintain privacy in such an
environment is irresponsible."
I agree with you that failing to provide any mechanism that maintains
privacy is not only worse than hobbling the available mechanism
but equally irresponsible. If that wasn't clear before, I'm sorry, and
thanks for giving me the chance to make it clear now.
><snip>
>The choice, as IETF has always seen it, is to stick with IETF's first
>principles [RFC1984, RFC2804] which is end-to-end crypto is best (4) and
>market and legal requirements are not relevant to IETF's standards. I agree
>it is a laudable and worthy goal.
I don't think it is quite as bad as "market and legal requirements are
not relevant to IETF's standards". I think it is closer to those requirements
being balanced against the usefulness of the network to its actual users.
By insisting that what we specify is actually able to meet the security
needs of the users, we make sure that there is at least one option on the
table that does. Folks can implement and deploy that solution, possibly
without the carrier supported infrastructure of other solutions, and get
a clear expectation of the security available.
> I could even agree that we should leave it
>to other SDOs, who deal more closely with LI requirements, to determine how
>those LI requirements can be met.
>
>Yet, IETF has also said that IETF owns the SIP standards (and related
>standards).
Yes, it has. It has said that in the context of RFC 1984, though, which was
written with lawful intercept clearly in view. As I said before to Paul,
a considered review of whether this problem is sufficient to warrant revisiting
that may be in order; a part of that review would certainly be a review of
the hierarchy of issues such as you put forward. I'm glad we agree that such
a discussion would involve the wider community.
>Taking your suggestion would mean we do (4) and have other SDOs decide if and
>how to accomplish a weaker, LI-friendly solution (1, 2, or 3), and IETF should
>not provide guidance for the most secure (3) of those remaining LI-friendly
>approaches. The result is undesirable: millions of users will be unprotected
>because they will only have plain RTP (1) or they will be vulnerable to every
>SIP proxy on their path (2); (3) is difficult, and (4) will be undeployable by
>licensed providers in many countries around the world.
One consequence of specifying (4), at least in my mind, is that some deployments
actually use (4) as specified. If we don't do what we can to keep that level of
security on the table, who will?
That does have to be balanced against the possibility that the situation will
remain dire for an even larger number than if we specified 3; the
"mental model" problem there is how we express 3. It's a little be compromised,
and that's like a little be pregnant.
Thanks very much for message and considered response. As before,
this represents my personal opinion,
regards,
Ted Hardie
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
