On Apr 5, 2008, at 2:23 PM, Elwell, John wrote: >> >> On Apr 5, 2008, at 12:08 PM, Dean Willis posited: >>> >> Or we could fix it by either fundamentally changing RFC 4474, or by >> providing a different fingerprint integrity mechanism for DTLS-SRTP >> framework and thereby breaking the dependency cycle. > [JRE] But isn't this effectively what the Wing and Fischer drafts are > doing, i.e., providing a different fingerprint integrity mechanism? > They > would probably still need something like a PSTN disclaimer solution > too.
It's a different thing to assert "this media goes with this INVITE" (when you sent both) than it is to assert "The identity we have authenticated as the source of this call is +19725199190" (when you don't really know). The gateway service provider sending the INVITE is certainly responsible for the INVITE, so if they want to cryptographically assert that the RTP they're also responsible for is related to that INVITE, then I don't see that as a liability. Of course if they get it wrong they might have a problem, but that's just a cost of doing business -- and it's a lot easier to make assertions about something you control (the INVITE and the RTP) than about something you don't (the Caller-ID information). In other words, if you're not asserting something as true that you reasonably have cause to expect may not be true, then you probably have no negligence, at least not of that type I've been talking about. Do we need a special disclaimer for populating a From header field with a phone number? As this is the Best Current Practice, and since we've gone to some pains in the industry to say that an unauthenticated From: is pretty much meaningless (see all the 3GPP sample calls from AlienBlaster), my opinion is no, we wouldn't need a disclaimer. As for what the drafts actually do (do either Wing or Fischer completely eliminate a dependency on RFC 4474?), I'll leave that to the working group to figure out. Although it sure looks to me like that's what they're trying to do. :-). -- Dean _______________________________________________ Sip mailing list https://www.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
