Subject: RE: [Sip] sips: upgrading allowed or not

From: "Elwell, John" <[email-masked]>
Date: Wed, 28 Mar 2007 07:42:04 +0100

I agree with Jonathan's statements here and I would very much like to have
the simplification and security property that this would give. However, a
UAC or UAS may trust proxies to do everything correctly if indeed they
conform to the proposed RFC 3261 update that fixes sips, but how can a UAC
or UAS know whether all proxies support this update?

John

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 27 March 2007 14:40
> To: IETF SIP List
> Subject: [Sip] sips: upgrading allowed or not
> 
> During the Prague IETF, I shared some opinions on what I thought sips 
> needs to look like and why, and wanted to take these to the list.
> 
> Firstly, what is the point of sips? What does it bring a 
> network that it 
> can't get with TLS on some hops, as needed? The answer is 
> that certain 
> security benefits are afforded if we can assure that every single hop 
> from UAC to UAS was TLS protected, and that furthermore, this 
> fact can 
> be definitively known by the UAC, UAS, and all proxies along 
> the way. If 
> we make the assumption that the UA's trust their proxies 
> (please don't 
> question the assumption in this thread), then SIPS provides you some 
> very nice security properties - confidentiality and integrity 
> from all 
> non-trusted entities. We use this property all over our specs 
> to secure 
> various extensions.
> 
> Given that, sips is broken if it doesn't provide that service (tls on 
> each hop with knowledge of such by all entities). FOr this reason, I 
> think we need to eliminate the last hop exception (uncontroversial I 
> think), but furthermore, I believe this extends to 
> retargeting as well. 
> I think we clearly need to disallow retargeting or downgrading from a 
> sips URI to a sip URI. I think that was also largely 
> non-controversial. 
> However, I also want to disallow upgrading or retargeting from sip to 
> sips. On this, there was some disagreement.
> 
> The challenge Jon gave me at the mike was this. As long as a 
> UAC inserts 
> a sips URI into the To field and R-URI field when it emits a sips 
> request, does not the presence of a sips URI in the TO field, and 
> receipt over a TLS connection, assure that the request was delivered 
> over TLS at each hop? Had the request been sent originally to 
> a sip URI 
> and then upgraded, the TO field would not have been sips, but 
> rather sip.
> 
> I believe Jon is correct, however I still think it is not a 
> good idea. 
> My rationale is:
> 
> 1. if upgrades are disallowed, redirecting from sip to sips 
> works much 
> better. Such a redirection would necesarily have to go all the way to 
> the UAC. If we allow upgrades, a proxy in the middle could 
> recurse and 
> upgrade. In that case, if the reason for the redirection was that the 
> UAS *wanted* TLS on each hop, recursing in the middle would 
> destroy that 
> possibility.
> 
> 2. The architectural principle behind the first issue, more 
> generally, 
> is that the meaning of sips is *SECURE ON EACH HOP FROM UAC 
> TO UAS*. To 
> me, this is fundamentally at odds with any notion of upgrade 
> or downgrade.
> 
> 3. Things become simpler if we forbid upgrades. We can eliminate the 
> text on double-record routing sinec a proxy would never be sip/sips 
> converting. I think it also just generally makes overall processing 
> easier. SIPS means one thing and one thing only and its 
> terribly clear 
> what it means.
> 
> As such, I stand by my argument that we should forbid upgrades.
> 
> -JOnathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 
> _______________________________________________
> 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
> 

_______________________________________________
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