Subject: [Sip] sip-connect-reuse-04

From: "Cullen Jennings" <[email-masked]>
Date: Fri, 29 Jul 2005 12:29:06 -0400

I'm pretty sure I have said all the things below on prevision version but
I'm sorry I forget the answers - might be nice if draft gave a hint to them.

Should be clear that this can only be used on mutual TLS connections that
are both originated from and sent to proxies with globally routable
addresses that are in DNS.

I'm not sure the alias tag buys much, perhaps you should just always do
this. In what cases would a proxy not want to insert the alias tag?

I'm not sure I see the point of the DNS verification step. It is going to be
significantly harder for an attacker to prove they have possession of the
private key for the domain than spoofing DNS. Agree doing both is harder
than just one but not really sure I see the value. Perhaps I am missing the
real purpose of the DNS verification. I also wonder about this facilitating
DDOS attacks on DNS servers but given that the attacker had to do a TLS
connection first I don't think this is a problem. That type of attack is
going to get much more interesting if DKIM happens.

Consider just a proxy making TLS connection *to* example.com. It does not
make a new session for every transaction. It does this by having a chance
and any time it tries to route to example.com, it looks in the cache to see
if it has a connection to example.com then uses it. Yes this breaks load
balancing across farms but the alternative of a connection per transaction
is way worse than breaking load balancing. So if you buys this so far, why
not when you receive a connection with a cert that says it is from
example.com, just insert this connection into the cache - regardless of
anything in the SIP messages. This has the advantage that it can all be
handled at the transport layer, you don't have to do  complex DNS queries to
authorize it.

Ignoring all that, I am worried that implementers will all just put alias in
stuff they send, no reason not to. Then when receiving alias, just blindly
add whatever is the advertised address with no verification. This will
result in trivial highjack of whole domains and the draft needs to make it
really clear how broken it will be if the verification is skipped.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip