> -----Original Message----- > From: Eric Rescorla [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 05, 2008 8:14 AM > To: Dan Wing > Cc: 'Eric Rescorla'; 'Elwell, John'; 'Hadriel Kaplan'; > 'Jonathan Rosenberg'; 'Cullen Jennings'; 'SIP IETF'; 'Uzelac, Adam' > Subject: Re: [Sip] Thoughts on SIP Identity issues > > At Tue, 5 Aug 2008 07:56:12 -0700, > Dan Wing wrote: > > > > ... > > > 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. > > > > Implicit in that argument is that 4474 got it right. > > No, I don't think that's true. 4474 did the conservative thing: it > signed everything. > > > > We know it already isn't done correctly with RFC4474 for > > unidirectional media > > (draft-kaplan-sip-baiting-attack). To get bi-directional > > media, an attacker > > would need to share a NAT or a TURN server with the > > identity they want to > > spoof (e.g., a bank, a pizza restaurant, a political > > organization), and the > > attacker would need to obtain the same UDP port from the > > NAT or TURN server > > within RFC4474's replay window (which is recommended to be > > 10 minutes). > > I haven't spent a long time examining draft-kaplan-sip-baiting, but as > I recall, it's not the fault of 4474 failing to sign something that > it should have but rather that it's inherent in the message-oriented > nature of SIP.
That distinction is not relevant to the victim. > With that said, ISTM that this cuts against your argument > that we should > be signing less of the message, since the failure of RFC 4474 (to the > extent there is one) in this case is that it doesn't protect > *enough* information. Neither draft-fischer-sip-e2e-sec-media and draft-wing-sip-identity-media simply "sign less" -- please do not mis-characterize the proposals. Both proposals require a public key exchange with the remote party -- which is far stronger than just using the IP address of the remote party as is done by RFC4474. -d _______________________________________________ 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
