On Jul 2, 2008, at 2:29 PM, Jonathan Rosenberg wrote:
Its not just a UI problem - the problem is that the identity really IS just +17005551008 - without the domain. I don't need the domain to dial it from a phone. So even if the UI could render a domain, I don't think it makes sense to do so.
The domain of the E.164 is unimportant (or arguably non-existent). What are important are: 1) the identity of the SIGNER of the Identity header field, and 2) What kind of claims they are making about the strength of their identity assertion. RFC 4474 provides for #1, but allows for no differentiation in #2. So what I was hoping the disclaimer in DTLS-SRTP would do is provide that disclaimer, something like "Authentication servers may not be able to verify the orignator of a call received from the PSTN, but need to add an Identity header for DTLS-SRTP. Therefore, recipients of requests having RFC 4474 Identity header fields used with DTLS-SRTP MUST NOT presume that the Identity header asserts anything about the originator of the call."
If we extended RFC 4474 to have "strength of assertion" indicators, then we wouldn't have to have this warning.
That said, another possible approach here is to more loosely couple DTLS-SRTP to 4474. It is my understanding that what DTLS-SRTP needs is integrity of the signaling to protect the fingerprint from modification. Any mechanism which provides message integrity would do. RFC4474 is one way, but there are others. HBH TLS, for example, would also provide integrity services, though not against rogue servers. Of course, we don't have protection against rogue servers with 4474 either in cases where phone numbers are used...
True. Dan and others have proposed alternative integrity techniques derived from RFC 4474.
So my suggestion is to have DTLS-SRTP just state that it requires some form of integrity services from signaling, to list some choices in what that can be. I think its also really important to point out that, even in the absence of any message integrity mechanisms at all, it requires an ACTIVE attack in order for a third party to eavesdrop or modify media. Whereas with sdescriptions, passive attacks can be launched if an attacker can observe the keying material at some point along the signaling path. That alone is a big improvement IMHO.
It also requires that the integrity function be testably present by the UA. We don't want another "last hop exception", where the proxy in front of the UA provides the integrity check.
-- 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
