An active attacker could very well DoS the SIPS attempt making it look like "reciever was down". Hence downgrade must never bet attempted under such condition. There must be some explict indication, like the one discussed here, to indicate that contact does not accept SIPS.
-Anupam > -----Original Message----- > From: Michael Thomas [mailto:[EMAIL PROTECTED] > Sent: Monday, July 30, 2007 1:55 PM > To: Eric Rescorla > Cc: IETF SIP List; Rohan Mahy; Francois Audet; Paul Kyzivat; > [EMAIL PROTECTED] > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > Eric Rescorla wrote: > > At Mon, 30 Jul 2007 09:19:04 -0700, > > Michael Thomas wrote: > > > >> Eric Rescorla wrote: > >> > >>> At Fri, 27 Jul 2007 09:39:06 -0700, > >>> Michael Thomas wrote: > >>> > >>> > >>>> Rohan Mahy wrote: > >>>> > >>>> > >>>>> Michael, > >>>>> > >>>>> At issue here is what the default implementor is likely to do. > >>>>> With a new 4xx, the misguided but well-meaning implementor is > >>>>> likely to try to "helpfully" "repair" the error without > thinking > >>>>> about or understanding the security context. > >>>>> > >>>>> Using a Warning code raises the bar significantly, but still > >>>>> allows automata to at least log what happened. > >>>>> > >>>>> > >>>> As I said, a receiver is completely at liberty to prevent the > >>>> downgrade by not accepting the downgraded request. > >>>> > >>>> > >>> Unless, of course, someone is impersonating the receiver. > >>> > >>> > >> Given how tangled up SIPS is, I really no idea what you're talking > >> about, or whether it's even responsive to my suggestion. Last I > >> heard, the entire raison d'etre of SIPS was that the next hop is > >> cryptographically identified via TLS. I'm guessing that you're not > >> suggesting that TLS is useless against impersonation attacks. > >> > > > > Of course not. > > > > The point here is that if a caller automatically downgrades > to SIP, an > > active attacker can then intercept the request and accept it, > > regardless of the receiver's preferences. > > > > Um, so? That's the risk that the sender takes by sending > stuff in the clear. And where's the problem here anyway? The > steps are: try SIPS, then try SIP. > If the > first succeeds, there's no attack. So it's only in some slim > window of when the receiver was down, or something like that. > Doesn't seem to me to be something to get all exercised > about, especially when you factor in all of the other > insecurities associated with SIPS. > > Mike > > > _______________________________________________ > Sip mailing list https://www1.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 > _______________________________________________ Sip mailing list https://www1.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
