Subject: [Sip] Fwd: TLS meaning (was Re: [Sipping] WGLC: draft-ietf-sipping-dialogusage-03.txt)

From: Dean Willis <[email-masked]>
Date: Tue, 24 Oct 2006 14:51:43 -0500

Moving to SIP list with a new subject, lest I derail the important  
WGLC of dialogusage.

On Oct 24, 2006, at 1:19 PM, Francois Audet wrote:

>
>
> Dean said:
>> This is simply incorrect (as per RFC 3261), and insisting on
>> it going
>> forward will only preclude the use of sips: in environments offering
>> equally strong hop-by-hop protections such as SIP/UDP over IPSEC,
>> which could of course be keyed using the same certs and the same
>> cipher-suite as TLS might use. And if you've got the same crypto, do
>> you really care which encapsulation is used? The "s" at the end of
>> "sips" means "secured", not "specified by RFC 2246".
>
>
> Actually, you are more incorrect. SIPS specifically means TLS for all
> the hops up until you reach the target domain. In is only inside the
> target domain that alternative to TLS can be used. That's the infamous
> "last hop exception" rule.
>

Yep, that rule was my mistake in 3261, because I could not more  
effectively ellucidate the point at that time.

We have several possible fixes on the table for fixing the broken  
"last hop" rule:

Alternative 1) Keep the usage as is, remembering that the reason it's  
there is that UAs might well not support TLS server capabilities, and  
if they're not using something like Outbound, they won't have an  
existing TLS connection to reuse. In short, this relies on Outbound  
usage to fix the problem, since it provides a reusable TLS connection  
that is initiated by the UA as a TLS client.

Note that this prevents clients that have some other crypto-protected  
outbound hop, like IPSEC, from ever using sips: to request that other  
downstream hops also be protected. These hops might by sheer good  
fortune be protected, but the requestor neither knows they are nor  
has a way of expressing this preference.

TLS does not have any magic security properties that make it  
fundamentally more secure than IPSEC or DTLS with the same  
cyphersuite and key, so why would we want to shoot ourslves in the  
feet like this? All it accomplishes, AFAIK, is the prevention of  
secure deployments using UDP. Of course, if we could all agree to  
deprecate UDP and make TCP/TLS the single mandatory transport, I'd be  
willing to go along with that.

Alternative 2) I believe that sips really should (and was intended  
to) mean "is cryptographically secured", not "is TLS". We could agree  
on a similar definition.

Given that the current TLS usage doesn't actually assure anything  
about the cyphersuite and authentication mechanism employed at each  
hop other than the presumption that the proxies involved are going to  
try and make good decisions (which is not completely unreasonable,  
according to our security advisor), why can't we also presume that  
those same proxies can make equally good decisions about alternative  
transport encapsulations, such as IPSEC?

--
Dean

_______________________________________________
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: "Samir Srivastava" <[email-masked]>
Date: Thu, 26 Oct 2006 15:03:28 -0500

.
> transport encapsulations, such as IPSEC?

I am in *complete disagreement* with the security advisor here. I have
presented more than enough evidence to have the cipher-suite and secure
protocol being exposed to the SIP. This is in accordance with the purist
view of internet.

Believe it or not, I am sick so my cipher-suite draft is not submitted
and still recovering.

I will be commenting on the deprecation  / surgery stuff in the separate
thread.

Dean, you yourself argued long time back even before the Dave Oran's
comment on the cipher-suite etc in the last hop in IMS where users are
open to MITM 

http://www1.ietf.org/mail-archive/web/sip/current/msg13337.html 

BTW, I like sometimes (without the *big* hat) purists Deanism views ..

Thx
Samir

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Oct 2006 15:10:22 -0700

"Samir Srivastava" <[email-masked]> writes:

> protocol being exposed to the SIP.

It would probably be useful here if you were more concrete about what
"cipher suite and secure protocol being exposed to the SIP" means.

I don't have a problem with including the information about what
cipher suite was used in headers the same way it is in RFC822 Received
lines.

I don't, however, agree that you've presented a good argument that the
client's *preferences* should be carried in some header. 

-Ekr

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Oct 2006 17:51:15 -0500

> I don't have a problem with including the information about 
> what cipher suite was used in headers the same way it is in 
> RFC822 Received lines.
> 
> I don't, however, agree that you've presented a good argument 
> that the client's *preferences* should be carried in some header. 
> 
> -Ekr

Bingo. Fully agree on both points.