At Tue, 05 Aug 2008 10:01:16 +0100, Elwell, John wrote: > > Eric, > > > -----Original Message----- > > From: Eric Rescorla [mailto:[EMAIL PROTECTED] > > Sent: 01 August 2008 14:46 > > To: Dan Wing > > Cc: 'Eric Rescorla'; 'Hadriel Kaplan'; 'Jonathan Rosenberg'; > > Elwell, John; 'Cullen Jennings'; 'SIP IETF'; 'Uzelac, Adam' > > Subject: Re: [Sip] Thoughts on SIP Identity issues > > > > At Fri, 1 Aug 2008 09:36:36 +0100, > > Dan Wing wrote: > > > > > > > At Thu, 31 Jul 2008 20:54:43 -0400, > > > > Hadriel Kaplan wrote: > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Eric Rescorla [mailto:[EMAIL PROTECTED] > > > > > > > > > > > > Funny you should mention that. > > > > > > > > > > > > It's becoming increasingly clear that VBR codecs leak a fair > > > > > > amount of information, even when they are encrypted [WBC+08]. > > > > > > So, if, for instance, you were planning to use a fixed-rate > > > > > > codec and an attacker could force you into a VBR codec, that > > > > > > might leak information. > > > > > > > > > > Fascinating paper. (truly) But it sounds more like just > > a reason to > > > > > fix SRTP for VBR, through random padding or whatever. > > > > > > > > I haven't studied the problem, but I suspect random padding > > > > is of limited use because it averages out. Probably better > > > > to use a fixed length codec. > > > > > > > > However, I think focusing on that misses the larger > > point: the UAC and > > > > UAS have certain desires as expressed in the messages/SDP > > > > To the extent to which we allow the intermediaries to change > > > > those messages, we need to carefully analyze each instance, > > > > and this analysis may actually depend on facts yet to be > > > > discovered. > > > > > > 4474 allows intermediaries to change SDP, and re-create a new > > > >From and a new signature. > > > > Well, it allows it in the sense that there's no known > > cryptographic way to stop it in any system, then sure. > > > > > > > This (a) destroys end-to-end identity > > > (which is the subject of this thread) *and* (b) allows > > > intermediaries to perform the very downgrade attack you > > > cited ([WBC+08]). > > > > > > This is why I want to improve upon 4474. > > > > I don't agree with this analysis. > > > > Let's say that [EMAIL PROTECTED] sends [EMAIL PROTECTED] an INVITE. > > It's 4474 signed by atlanta.com. Now, some SBC in the middle > > edits the SDP. This breaks the signature. > > > > At this point, when Bob gets the message, he knows: > > > > (1) This message claims to be from Alice. > > (2) The signature was broken. > > > > He therefore has no knowledge of what happen. He can choose to > > accept or reject the call, but can't reasonably infer that > > the call came from Alice or anything else about Alice's > > intentions. > > > > > > Now, if the SBC resigns, then Bob gets a valid message > > from somebody else other than Alice. Effectively, the > > SBC. Now, the SBC claims that it is connecting Bob to > > Alice, but it could be lying. If Bob trusts the SBC, > > he can accept the call, but he's trusting the SBC. > > Sure, the SBC can edit the SDP to replace codecs, but > > it can do *anything*. It could, for instance, replace > > the DTLS-SRTP fingerprint. This isn't surprising, since > > the SBC is really a B2BUA and this is a call from it. > [JRE] I agree so far, but what I really would like to see is some > mechanism by which atlanta.com can sign the request from Alice and that > signature stands a fairly good chance of surviving harmless SBCs in > intermediate domains. We can't do anything about an intermediate domain > that insists on re-signing for the sake of it, or performs some action > that involves decryption of the media (e.g., transcoding, mixing). At > least in such cases Bob will see that the call is secured only as far as > the intermediate domain. But in cases where the intermediate domain is > performing less invasive actions such simple media steering, it should > have some way of doing so without breaking atlanta.com's signature. Then > Bob will not be misled into thinking the call is insecure (i.e., secured > only as far as the intermediate domain) when really it is secured all > the way to Alice's domain and he can indeed talk without fear of an > intermediary eavesdropping or injecting information.
Sure, but again, that requires examining every single piece of the message which you wish to exampt from the signature and determine whether there is some important attack that can be mounted by modifying that section. As I noted above, those questions are not necessarily immediately apparent. -Ekr _______________________________________________ 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
