Subject: RE: [Sip] A sips: trial balloon for you to shoot down

From: "Elwell, John" <[email-masked]>
Date: Wed, 01 Nov 2006 21:03:40 +0000

Dean,

Not quite. See below.

John 

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: 01 November 2006 20:32
> To: Elwell, John
> Cc: IETF SIP List
> Subject: Re: [Sip] A sips: trial balloon for you to shoot down
> 
> 
> On Nov 1, 2006, at 2:28 AM, Elwell, John wrote:
> 
> > Dean,
> >
> > I think your proposal is moving in the right direction, but I have  
> > a couple
> > of concerns. See below.
> 
> In summarization, I think your concerns all involve some 
> variation of  
> knowing "what happened downstream". Specifically, you want to know if:
> 
> 1) A sip: URI scheme actually produced a dialog with encryption on  
> all hops. You may want to know more about it than "encryption", for  
> example you may want to know what sort of encryption, or what  
> mechanism was used to authenticate the intermediary or terminus. By  
> knowing you had succeeded in getting a secure channel, you could  
> decide to engage other mechanisms (like key exchange) or activities  
> dependent on that security.
[JRE] If we have a sips scheme that mandates TLS on all hops (whatever TLS
might mean) and fails if it can't achieve it, I think there is an equal
argument for a mechanism that requests TLS on all hops but still succeeds
and tells me if any hop does not meet this requirement. So if we recommend
the sip scheme for achieving best effort, it still doesn't tell me if it
succeeded. Yes, what I want would be a new mechanism, but it would not be
substantially more difficult to define than the SIPS mechanism. I am having
a hard time rationalising why we should specify an all-or-nothing mechanism
(sips) but not a best effort mechanism. In other words I am having a hard
time understanding the use cases for sips. Maybe the lack of plausible use
cases is part of the reason it hasn't been deployed much.

> 
> 2) The security of a sip: or sips: request is degraded (or  
> potentially degraded) by a gateway threshold, beyond which the  
> reporting mechanism has no visibility and which we would generally  
> assume has fully denigrated our cryptographic protections. By 
> knowing  
> the security of sips: is not really end-to-end, you could moderate  
> the invocation of other mechanisms or activities as appropriate for  
> an unsecured channel.
> 
> I think these are great things to know. I think they go 
> substantially  
> beyond anything we can describe as a BCP for using sip: and sips:. I  
> think this requires new mechanism, perhaps From [email-masked] Wed Nov 01 16:05:41 2006
From: Dean Willis <[email-masked]>
Subject: Re: [Sip] A sips: trial balloon for you to shoot down
Date: Wed, 1 Nov 2006 15:03:53 -0600
To: Francois Audet <[email-masked]>
Cc: "Sanjay Sinha \(\(sanjsinh\)\)" <[email-masked]>,
	IETF SIP List <[email-masked]>, Paul Kyzivat <[email-masked]>

On Nov 1, 2006, at 11:23 AM, Francois Audet wrote:
> The difference is that there is a level of "security" on PSTN. You  
> can't
> do IP address spoofing for example. You can't tap into a hub.
>
> (Yes, I know: there are ways to tap into analog lines too).
>
> The point is that for many people, they are happy with the security
> level provided by the PSTN, but not with the one provided by IP
> telephony
> or SIP when there is no TLS/SRTP/whatever.
>
> That's my point.
>
> So, I can see that, as Michael Thomas said, putting all the  
> "attributes
> of security" into the letter "s" is not terribly useful.
>
> On the specific issue of "is sips allowed" when you leave the  
> "network",
> I am a bit
> ambivalent.
>
> I think if you are Leaving SIP and going to another IP protocol (say
> H.323) then we
> shouldn't allow SIPs.
>
> However, for the PSTN case, I'm not sure. I think I'm ok either way. I
> think arguments
> on both sides are valid.

Since the PSTN call could (and very well may) turn back into a sip:  
session, and we have no way to send the "please make this back into a  
secure session when you go back to IP" request over PSTN, then I  
don't think you can claim to have met the intent of sips:.

That's not to say a gateway couldn't use SIP security techniques --  
for example, it could (and should) use TLS. It just can't claim to  
have met the requirements of sips:.

--
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: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 1 Nov 2006 16:23:09 -0500

> Sent: Wednesday, November 01, 2006 4:07 PM
> 
> Right. And all of the signaling from SIP is being mapped into some
> other signaling protocol and sent beyond a transitive trust boundary.
> The gateway simply doesn't know where its goingor what is going to
> happen "out there". Consequently, the gateway knows that it cannot
> assure transitive trust with respect to signaling integraity, and
> since it cannot insure transitive trust, it cannot use sips:.

I'm curious: what is it specifically you think you're protecting by using
sips, that DOES cross the pstn boundary, and thus would be "leaked"?  I mean
most of any info that crosses into the pstn is either deducible in sips in
some cases too, or doesn't cross, so I'm really curious what it is you think
you'd be losing.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Wed, 1 Nov 2006 15:23:26 -0600

On Nov 1, 2006, at 3:03 PM, Elwell, John wrote:

> ...

> cases is part of the reason it hasn't been deployed much.

So sip: gives us a best effort connection without a reporting  
mechanism. You want a best-effort connection with a new reporting  
mechanism. I think that's useful. I also didn't say it was a hard new  
mechanism to define, just that it's beyond the scope of a BCP to  
describe.

The use case for sips: hasn't changed (except a recommendation for  
outbound-with-TLS instead of last-hop-excepting ) , and its obvious.  
One uses sips: only when one is absolutely insistent that each SIP  
hop be protected by TLS. This is very useful for MESSAGE requests,  
registrations, presence publications, subscriptions, notifications,  
and other usages where the SIP payload is the actual communication  
being protected. It enables key-exchange within SIP for resulting  
media sessions (although DH is still a better approach). And it helps  
to obscure the media descriptions, which doesn't protect the media  
channel directly but does complicate the task of an eavesdropper.

There's clearly enough "use case" here for people to be deploying  
sips: today. Just not enough specification for making those  
deployments as meaningful as they could be.

--
dean

ext/plain; charset=US-ASCII; delsp=yes; format=flowed
From: Dean Willis <[email-masked]>
Subject: Re: [Sip] A sips: trial balloon for you to shoot down
Date: Wed, 1 Nov 2006 15:23:26 -0600
To: "Elwell, John" <[email-masked]>
Cc: IETF SIP List <[email-masked]>

On Nov 1, 2006, at 3:03 PM, Elwell, John wrote:

> ...

> cases is part of the reason it hasn't been deployed much.

So sip: gives us a best effort connection without a reporting  
mechanism. You want a best-effort connection with a new reporting  
mechanism. I think that's useful. I also didn't say it was a hard new  
mechanism to define, just that it's beyond the scope of a BCP to  
describe.

The use case for sips: hasn't changed (except a recommendation for  
outbound-with-TLS instead of last-hop-excepting ) , and its obvious.  
One uses sips: only when one is absolutely insistent that each SIP  
hop be protected by TLS. This is very useful for MESSAGE requests,  
registrations, presence publications, subscriptions, notifications,  
and other usages where the SIP payload is the actual communication  
being protected. It enables key-exchange within SIP for resulting  
media sessions (although DH is still a better approach). And it helps  
to obscure the media descriptions, which doesn't protect the media  
channel directly but does complicate the task of an eavesdropper.

There's clearly enough "use case" here for people to be deploying  
sips: today. Just not enough specification for making those  
deployments as meaningful as they could be.

--
dean

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 2 Nov 2006 01:55:34 -0600

Do you want to say that your call to SIPS URI will be only secured. If I
dial 411 etc, then we don't know. Can we convince our users with some
calls are secured, others are not.

With another wacky thread, I am still not getting convinced what we are
achieving..
In your presence publications, and registration example .. My presence,
registration can be leaked too, as there is No REQUIRE flag for not
distributing my presence,reg info to watchers on the UNSECURE channel.

Thx
Samir

>mechanism. You want a best-effort connection with a new 
>reporting mechanism. I think that's useful. I also didn't say 
>it was a hard new mechanism to define, just that it's beyond 
>the scope of a BCP to describe.
>
>The use case for sips: hasn't changed (except a recommendation 
>for outbound-with-TLS instead of last-hop-excepting ) , and 
>its obvious.  
>One uses sips: only when one is absolutely insistent that each 
>SIP hop be protected by TLS. This is very useful for MESSAGE 
>requests, registrations, presence publications, subscription
>notifications, and other usages where the SIP payload is the 
>actual communication being protected. It enables key-exchange 
>within SIP for resulting media sessions (although DH is still 
>a better approach). And it helps to obscure the media 
>descriptions, which doesn't protect the media channel directly 
>but does complicate the task of an eavesdropper.
>