At Sat, 07 Apr 2007 00:25:20 -0500, Dean Willis wrote: > > Eric Rescorla wrote: > > > The only real defense against this sort of downgrade is to only > > give people URLs that start with https: and assume that they will > > do the right thing. > > > . . . > > > As with https: the fix is that your AOR has to somehow signal > > to everyone that you expect to be contacted over TLS. This is > > what sips: does (though of course it's not the only way to do > > it). > > But the current draft doesn't. It implies that if you have a SIPS: AOR > and a SIPS: contact registered to that AOR, that is still OK to send > SIP: traffic. I requote: > > Because registering with a SIPS contact header field implies a > binding to both a SIPS Contact and a corresponding SIP Contact . . . > > So this is the equivalent of only giving people https:, and assuming > that they will do the WRONG thing.
I don't understand the argument you're making here, probably because "OK" isn't any kind of normative term. There are three relevant actors here: 1. The registering user. 2. The proxy. 3. The caller. You give the caller the sips: URI and I think the draft makes clear that if you have a sips: URI you MUST NOT use SIP w/o TLS. The question is what a proxy should do if a request comes in without TLS. If you give people HTTPS and they try to contact the server over HTTP (recall that the servers need to support both TLS and non-TLS) the server can do one of three things: - Respond to the request anyway. - Redirect the request - Throw an error. The damage of the data being sent over the net to the server is already done. Going back to the SIP case, the proxy has three options: - Forward the request to the client anyway. - Redirect to the SIPS AOR - Throw an error. Again, the damage of the data being sent in the clear over the net to the proxy is already done. The text you quote above implies the first choice, but it's not clear there's anything wrong with that, especially as you can ensure that the connection from the registering user to the proxy is secure. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
