Subject: [Sip] Comment on sip-tls-use draft

From: [email-masked]
Date: Mon, 20 Mar 2006 12:02:16 -0500 (EST)

I've given this a fairly detailed read.  Its good that the issue of more
explicit rules on certificate name matching is (finally) being addressed. 
It will be really nice to nail down what the certificate for a server farm
looks like.

A few Comments:

* In the introduction, why would Alice's possession of a certificate
determine whether sip or sips is used in the registration? If Alice pins a
TLS connection to a server(Alice might implement sip-outbound, but pinned
TLS w/ server certs only is already deployed) a sips uri would be
appropriate.

* In section 4, there is an assertion that:

    When endpoints use TLS, there aren't any checks at the SIP layer
    correlating the contents of the TLS certificate with the SIP headers.

AFAIK, there is a requirement that endpoints match the request URI against
the certificate name.

Also in section 4 there is an DNS poisoning attack where example.net
hijacks example.com.  This is not an effective attack unless a cert. has
been compromised as the name presented in the certificate will not match
the request uri.

* using the via trail to see if a message has been compromised does not
seem worthwhile, as there is nothing preventing the attacker from
inserting a valid-looking via trail.

* promoting a SIP URI to a SIPS uri seems like a nice thing for registrars
to do as clients will not have to have knowledge of whether the
registrar/proxy has correctly implemented sips.  Admittedly, this is only
an issue w/ bad registrar/proxy implementations.

Thanks,

Derek

_______________________________________________
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

---

From: Thejeswara Reddy <[email-masked]>
Date: Mon, 20 Mar 2006 19:38:38 +0000 (GMT)

HI,
  
           Is it possible to  convert  sips (tls) to TCP (as proxy does from UDP to TCP), if the  UAS wont support TLS, and the call is emrgency............ (dont want  drop the call because of sips uri)
  
  Thanks.
  theja

[email-masked] wrote:  
I've given this a fairly detailed read.  Its good that the issue of more
explicit rules on certificate name matching is (finally) being addressed. 
It will be really nice to nail down what the certificate for a server farm
looks like.

A few Comments:

Thanks,

Derek

				
---------------------------------
 Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 20 Mar 2006 18:48:47 -0600

Thejeswara Reddy wrote:
> HI,
> 
>          Is it possible to convert  sips (tls) to TCP (as proxy does 
> from UDP to TCP), if the UAS wont support TLS, and the call is 
> emrgency............ (dont want drop the call because of sips uri)

Generally speaking, downgrading security in this manner is not
recommended.  The reasons we switch transports from UDP to
TCP -- namely, congestion control, fragmentation, etc. -- are
much different from downgrading sips to sip.

I dare say proxies and user agent servers will have procedures
and policies in place to handle SOS calls, regardless of transport.
The ecrit WG discusses some of these issues.

Thanks.

- vijay

---

From: Dean Willis <[email-masked]>
Date: Tue, 21 Mar 2006 10:48:45 -0600

On Mar 20, 2006, at 1:38 PM, Thejeswara Reddy wrote:

> HI,
>
>          Is it possible to convert  sips (tls) to TCP (as proxy  
> does from UDP to TCP), if the UAS wont support TLS, and the call is  

Yes, RFC 3261 specifically allows for the UAC to AOR-PROXY link to be  
SIPS, and the AOR-PROXY to UAS link to be SIP. You've just described  
one of the motivating use cases.

This is controversial. Some people think that it should be changed so  
that TLS MUST be used all the way through. The problem with this  
suggestion (in addition to breaking your use case) is that, with the  
current protocol design, this requirement is "toothless"./ There's no  
way for the UAC to know whether or not the TLS requirement was  
honored. Therefore, we must assume it wasn't.

Proposals for fixing this are circulating.

--
Dean