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:As I said, a receiver is completely at liberty to prevent the downgrade by notMichael,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.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
