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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
