Ted,
> ...
> Speaking for me, personally, the costs are too high. If the
> working group does decide to move forward here, I will strongly
> urge early review by the broader IETF community, as the consequences
> of this decision are not light.
> ...
Thanks for your email. I agree this needs wider discussion and the
WG (and probably RAI as a whole) needs to decide what it wants to do.
The wider consequence, however, is not increased "epic invasion of
privacy", as you state. The wider consequence is that, without a
suitable mechanism that meets the needs of LI for SRTP, networks
subject to LI will only ever be able to do RTP. The choices, as I
see them, are (in order of least secure to most secure):
1. everyone can listen to the call. This is what we have today
with RTP. This allows 'epic invasion of privacy' by all
parties (governments, criminals, and anyone who is able to
receive your RTP)
2. every SIP entity learns the SRTP keys. This is what would
happen with Security Descriptions. This allows 'epic
invasion of privacy' by any party that has control of any
SIP entity your Invite (or its response) traversed. That
control could be legitimate or could be illegitimate
(government or criminal hacked into the SIP proxy).
3. only a specific SIP entity learns the SRTP key. This is
what would happen in the two techniques I proposed at the
beginning of this thread. This allows 'epic invasion of
privacy' by any party that has control of that specific
SIP entity. That control could be legitimate or could be
illegitimate (government or criminal hacked into that
specific SIP proxy).
4. IETF sticks with only doing DTLS-SRTP and provides no
guidance for how to meet LI requirements.
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 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).
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.
-d
_______________________________________________
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
