Dan, Well, yes, if the intermediary changes the From URI and resigns, at least you know that you have security only as far as that intermediary. If the originating URI is carried elsewhere in the header, intermediaries might be less likely to change it, but if they do the same consideration applies. Unfortunately, as noted on another thread, there is the difficulty of bringing this fact (that security is only as far as the intermediary) to the attention of the user.
John > -----Original Message----- > From: Dan Wing [mailto:[EMAIL PROTECTED] > Sent: 20 February 2008 18:05 > To: Elwell, John; 'Jonathan Rosenberg'; 'IETF SIP List' > Subject: RE: [Sip] New I-D on RFC4474 and phone numbers > > > > 3. "Thus, DTLS-SRTP still provides better security than > Sdescriptions. > > However, when used with phone numbers, it is by no means > > ideal. Most > > importantly, it does NOT provide guarantees that > > intermediaries have > > not been able to intercept and decrypt the media." > > > > Not true. If you use DTLS-SRTP with RFC 4474 and an E.164 > > number in the > > SIP URI, it DOES provide a guarantee that intermediaries between the > > domain in the SIP URI and the UAS are unable to intercept > and decrypt > > media. This seems to be of value in some situations. > > If the intermediary created the RFC4474 signature itself -- which > is necessary if the intermediary changed the SDP -- the intermediary > could have also changed the a=fingerprint. Changing the a=fingerprint > allows the intermediary to perform the DTLS-SRTP handshake itself and > thus decrypt the SRTP packets to/from both callers. > > draft-kaplan-sip-uris-change-00.txt describes reasons why an > intermediary might want or need to change the SDP and the From URI. > > Most intermediaries are service providers. Most service providers > operate SBCs. All SBCs change the SDP (otherwise, they would merely > be B2BUAs). > > -d > > > _______________________________________________ Sip mailing list http://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
