> -----Original Message-----
> From: Elwell, John [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 08, 2007 1:30 PM
> To: Dan Wing; Ted Hardie; Paul Kyzivat; Dean Willis
> Cc: IETF SIP List
> Subject: RE: [Sip] media-security-requirements and lawful intercept
>
> Dan,
>
> Thanks for classifying the options. I just wonder whether there is a
> subdivision of 3. With 3, I could negotiate keys with a decrypting
> relay, but I really have no idea what happens beyond that relay. Or I
> can negotiate keys end-to-end where media is sent via a non-decrypting
> relay, which copies the encrypted media to a decrypting entity (not
> necessarily a SIP entity) to which I have disclosed the key. That
> decrypting entity could be in even be in the domain of the law
> enforcement authorities rather than a SIP service provider. Of course,
> verification that the key is correct then has to be done by the
> decrypting entity more or less in real time, with feedback to the SIP
> service provider if it believes the key to be incorrect, so that the
> call can be stopped. Did you have one of both of these in mind for
> option 3?
Yes, for (3) I am considering the two cases which you are describing
above. I believe those are the same two cases I had mentioned at the
beginning of this thread:
a. provide a network element on every SRTP call which relays
media, performs a DTLS handshake, and decrypts and re-encrypts
SRTP, or;
(this is the decrypting relay you describe above.)
b. have endpoints perform key disclosure for every call (using a
technique similar to draft-wing-sipping-srtp-key), and perform
validation of that disclosed key on every call.
(this is where you disclose SRTP keys and something validates them.)
-d
> John
>
> > -----Original Message-----
> > From: Dan Wing [mailto:[EMAIL PROTECTED]
> > Sent: 08 November 2007 18:33
> > To: 'Ted Hardie'; 'Paul Kyzivat'; 'Dean Willis'
> > Cc: 'IETF SIP List'; Elwell, John
> > Subject: RE: [Sip] media-security-requirements and lawful intercept
> >
> > 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
