Re: [Sip] media-security-requirements and lawful intercept

[Dean Willis <dean.willis at softarmor.com>]

On Nov 12, 2007, at 6:38 AM, Eric Rescorla wrote:

> My point was not that one ought to pursue mechanisms allowed key
> disclosure without modifying the client but that one could design
> mechanisms that could be implemented solely in the client software
> without explicitly modifying the wire protocol. This means that
> clients (or, rather vendors) wish wish to enable key disclosure can do
> so without any new protocol design work from IETF.

That's true, unless they wish to do so using protocols that are  
controlled by the IETF.

For example, let's say we're talking about SIP phones. It's quite  
reasonable to consider using some part of SIP for the key disclosure,  
since SIP has already solved the how-to-find-the-endpoint-across-a- 
NAT problem, and since SIP already has lots of data-transport  
capabilities. One might be tempted to use a SIP EVENT package (under  
RFC 3325) to do this. But according to IETF procedure (RFC 3427),  
defining a SIP EVENT package requires an informational or standards  
track RFC.

So, the regulated operators now have to decide -- do they make their  
own fully-proprietary SIP extension in violation of the agreements we  
have with them about collaboration?

Or do they reinvent a large part of the SIP infrastructure as a new  
protocol in order to meet their requirements?

Once they've gone down either path, what's to keep them from going  
further down that path, resulting in protocol fragmentation and  
lesser value from the Internet?

We can't stop them from doing lawful intercept. We can help them do  
it in the least dangerous way possible. And we can stop (or at least  
delay) fragmentation of the protocol suite. But doing so requires  
some level of compromise of values many of us hold dear.

Personally, I'd be fairly by a show-of-unity that causes the IETF to  
conclude that LI via key disclosure is such a dangerous idea that we  
will neither help the other SDOs do it now allow them to document the  
so-doing using our protocols and extension registration facilities.

But before we make that decision, we need to understand the  
implications and impact of what we're deciding. This is non-trivial,  
and the repercussions will reach the furthest ends of the Internet,  
in both space and time.

--
Dean




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip