Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)

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

Francois,

Well, maybe, but to the extent that I should be denied communication if TLS
on all hops cannot be achieved? I think there is an equal case for allowing
the request to succeed and reporting the lack of security.

John 

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: 01 November 2006 21:05
> To: Elwell, John; Juha Heinanen
> Cc: Joel M. Halpern; IETF SIP List
> Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: 
> TLS meaning)
> 
> You mean doing IP address spoofing?
> 
> If you don't like impersonation, take theft of service then.
> 
> My point is that I have seen places where signalling security was a
> requirement
> but not media security. 
> 
> It does exist in real life. 
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:[email-masked]] 
> > Sent: Wednesday, November 01, 2006 12:18 PM
> > To: Audet, Francois (SC100:3055); Juha Heinanen
> > Cc: Joel M. Halpern; IETF SIP List
> > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: 
> > TLS meaning)
> > 
> > Francois,
> > 
> > I disagree. Just securing the signalling is not sufficient to 
> > prevent impersonation, for example, unless the media is also 
> > authenticated and integrity protected. As a user, what good 
> > is it to me if secure signalling tells me that the caller is 
> > Francois, yet somebody is sending me unsecured media from a 
> > different source?
> > 
> > I agree that SIPS != padlock. Therefore I am still trying to 
> > discover real use cases for SIPS.
> > 
> > John 
> > 
> > > -----Original Message-----
> > > From: Francois Audet [mailto:[email-masked]]
> > > Sent: 01 November 2006 17:12
> > > To: Elwell, John; Juha Heinanen
> > > Cc: Joel M. Halpern; IETF SIP List
> > > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: 
> > > TLS meaning)
> > > 
> > >  
> > > > > There are cases where you want signalling to be secure (for 
> > > > > authentication, impersonation, theft of service, etc.), but
> > > > you don't
> > > > > need, or want, or even can have encrypted media.
> > > > [JRE] No, but you might want authenticated media. It is 
> all very 
> > > > well saying that the signalling comes from the person you 
> > think it 
> > > > comes from, but if the media is coming from somewhere 
> else, that 
> > > > doesn't help the average user.
> > > 
> > > Sure, but it's a different problem.
> > > 
> > > Media security and Signalling security are two different things.
> > > 
> > > SIPS is strictly about hop-by-hop signalling security with TLS. 
> > > 
> > > That's why sips != padlock item, otherwise, you'll give a 
> > false sense 
> > > of security to the "average user".
> > > 
> > 
> > _______________________________________________
> > 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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 01 Nov 2006 13:40:34 -0800

>the request to succeed and reporting the lack of security.
Right. What's being lost in all of this is that receiver's ought to have 
some say in
all of this too. SIP is a rendezvous protocol, after all. To the extent 
that SIP can
affect that rendezvous and let the participants make an informed 
decision, that seems
like the right direction.

       Mike

PS: is there any sort of notion of adding the transport protection 
information in Via's
       like, oh say, sendmail does with Received headers with TLS?

---

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

>       like, oh say, sendmail does with Received headers with TLS?

yep, that's one way to get the "What happened downstream" info back  
so the nodes can operate under "informed consent".

Of course, the SBCs that we're worried about breaking sips: also tend  
to hide the Via header fields, so it might not be all that useful.

--
Dean

---

From: Michael Thomas <[email-masked]>
Date: Wed, 01 Nov 2006 13:51:42 -0800

> so the nodes can operate under "informed consent".

Ok. Is it possible to put Via's in the reverse direction? Or some other 
way to inform
the originator of  the forward/backward transport path's protection 
characteristics?
If so, wouldn't that do pretty much everything you want SIPS to do 
without the
unappealing all-or-nothing problems of SIPS?

       Mike

---

From: Dean Willis <[email-masked]>
Date: Wed, 1 Nov 2006 16:41:50 -0600

On Nov 1, 2006, at 3:51 PM, Michael Thomas wrote:

>>> PS: is there any sort of notion of adding the transport  
>>> protection  information in Via's
>> yep, that's one way to get the "What happened downstream" info  
>> back  so the nodes can operate under "informed consent".
>
>
> Ok. Is it possible to put Via's in the reverse direction? Or some  
> other way to inform

History-Info, RFC 4244 is something like this. We're a little short  
on implementations so far, but I think it could be reasonably adapted  
to provide change-of-crypto "retargeting" info.

> unappealing all-or-nothing problems of SIPS?

With the exception that you'd get an established dialog (or a MESSAGE  
request delivered) that has an unsecured connection in it, then say  
"oops".

Here's a legit use case for sips:

I want to send you a text message with moderately sensitive info. So  
I send it using your sips: request URI. If it turns out that a proxy  
out there can't honor that request for transitive protection, it  
rejects the request rather than exposing my sensitive text-bits to  
the harsh climes of an unencrypted channel.

So I still need that "I want it" part of sips. With just a post-facto  
diagnostic (like History-Info) I'd have to first establish a dialog,  
then look and see if I liked the security, then send a MESSAGE over  
that dialog (considered to be abusing the dialog by the MESSAGE RFC),  
then tear the dialog down.

But your proposal works great for the use case John and others have  
come up with -- "Ok, I've got a dialog. Now how am I going to use it?"

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 1 Nov 2006 17:14:05 -0600

> Well, maybe, but to the extent that I should be denied 
> communication if TLS on all hops cannot be achieved? 

Yes. I will argue that some may want to do that. Correct.

> I think 
> there is an equal case for allowing the request to succeed 
> and reporting the lack of security.

I agree that some may want to do that as well.

That's my whole point: sips means what it means. It doesn't mean
media security, it doesn't mean "Security-with-a-capital-S", it 
doesn't mean some icon to be displayed to the user.

It just means the hop-by-hop TLS thing that we talked about. If that is
useful for your application, use it. If it is not, then don't use it.
If it is useful only in conjunction with other security mechanism (e.g.,
media security), then do that to.

We are not doing product design here. We are doing bits on the wire.

---

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

Hi Mike,

   My cipher-suite draft proposes the reverse channel for this purpose.

http://www.ietf.org/internet-drafts/draft-srivastava-sip-e2e-ciphersuite
s-00.txt

   The proposal in 3.D is sending back the least valued used
cipher-suite, but the group including EKR, agreed to send back the
complete via header.

Thx
Samir

       Mike

 1.0
Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)
Date: Thu, 2 Nov 2006 01:26:41 -0600
From: "Samir Srivastava" <[email-masked]>
To: "Michael Thomas" <[email-masked]>, "Dean Willis" <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>, IETF SIP List <[email-masked]>,
	Francois Audet <[email-masked]>, "Elwell,
	John" <[email-masked]>, Juha Heinanen <[email-masked]>

Hi Mike,

   My cipher-suite draft proposes the reverse channel for this purpose.

http://www.ietf.org/internet-drafts/draft-srivastava-sip-e2e-ciphersuite
s-00.txt

   The proposal in 3.D is sending back the least valued used
cipher-suite, but the group including EKR, agreed to send back the
complete via header.

Thx
Samir

       Mike

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 2 Nov 2006 02:31:35 -0600

Great attempt to keep SIPS. Looks like you love complex solutions
only...

Thx
Samir 

>From: Dean Willis [mailto:[email-masked]] 
>Sent: Wednesday, November 01, 2006 2:42 PM
>To: Michael Thomas
>Cc: Joel M. Halpern; IETF SIP List; Audet, Francois 
>(SC100:3055); Elwell, John; Juha Heinanen
>Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: 
>TLS meaning)
>
>
>> other way to inform the originator of  the forward/backward 
>transport 
>> path's protection characteristics?
>>
>
>History-Info, RFC 4244 is something like this. We're a little 
>short on implementations so far, but I think it could be 
>reasonably adapted to provide change-of-crypto "retargeting" info.
>
>> without the unappealing all-or-nothing problems of SIPS?
>
>With the exception that you'd get an established dialog (or a 
>MESSAGE request delivered) that has an unsecured connection in 
>it, then say "oops".
>
>I want to send you a text message with moderately sensitive 
>info. So I send it using your sips: request URI. If it turns 
>out that a proxy out there can't honor that request for 
>transitive protection, it rejects the request rather than 
>exposing my sensitive text-bits to the harsh climes of an 
>unencrypted channel.
>
>So I still need that "I want it" part of sips. With just a 
>post-facto diagnostic (like History-Info) I'd have to first 
>establish a dialog, then look and see if I liked the security, 
>then send a MESSAGE over that dialog (considered to be abusing 
>the dialog by the MESSAGE RFC), then tear the dialog down.
>
>But your proposal works great for the use case John and others 
>have come up with -- "Ok, I've got a dialog. Now how am I 
>going to use it?"
>
>--
>Dean
>
>

---

From: Michael Thomas <[email-masked]>
Date: Thu, 02 Nov 2006 08:00:58 -0800

> request delivered) that has an unsecured connection in it, then say  

Surely you could send some sort of NOP first? I guess that one of the my 
perhaps
not hidden assumptions here is that you are amortizing the connection 
for more
than one method being shoved down the piecewise pipe.

> then tear the dialog down.

I guess this all gets down to whether stateless SIP is useful at all, 
which is a superset
of the "is udp useful at all" argument. I'd say that establishing a 
bunch of TCP and/or
TLS sessions is more "abusive" then just one extra e2e round trip after 
the dialog is
established -- consider the zillions of round trips just to get things 
going on a fairly
standard SIP trapezoid. If we *really* wanted statelessness, the 
messages ought to be
self-contained, which while feasible for authentication is pretty 
problematic for
confidentiality. So statelessness in combination with security seems 
unlikely to be
sucessesful to me at least. So let's just not keep investing time on it? 
I've become
pretty sympathetic to the idea of deprecating UDP over the years given 
these
realities.

Part of this for me is that SIP is just too damn complicated, and it's 
painfully
obvious that it keeps getting itself wrapped around the axle because of some
fairly high level decisions which at a high level seemed unrelated but have
proven to be vexingly difficult to unify. It would be really nice to 
just chuck
some of the decisions made mostly in a different time (cf Aki's note), and
move on given the current reality. SIPS is one of these, UDP is probably
another, and my sense is there are a whole host of things that I don't pay
much attention to that qualify too.

So I'll try to put this into a more constructive light rather than the 
whine above:
why not make a BCP which discourages the use of things known to be 
problematic
aiming at while not exactly deprecating, but end-of-life'ing those 
things so that
we have a more manageable SIP going forward? Leave the problematic things
alone for closed systems where they might be feasible, but stop 
developing for
them for open internet standards where those assumptions can't be made.

       Mike

---

From: Dean Willis <[email-masked]>
Date: Thu, 2 Nov 2006 11:57:31 -0600

On Nov 2, 2006, at 10:00 AM, Michael Thomas wrote:

>
> Surely you could send some sort of NOP first? I guess that one of  
> the my perhaps
> not hidden assumptions here is that you are amortizing the  
> connection for more

Sure you could. However, unless you bound the operation with a dialog  
(INVITE transaction, usually) there's no assurance that subsequent  
requests will follow the same path. So you might send a sip: NOP that  
would report "secure", then follow it with a sip: MESSAGE that would  
not be secured.

>> I want to send you a text message with moderately sensitive info.  
>> So  I send it using your sips: request URI. If it turns out that a  
>> proxy  out there can't honor that request for transitive  
>> protection, it  rejects the request rather than exposing my  
>> sensitive text-bits to  the harsh climes of an unencrypted channel.
>>
>> So I still need that "I want it" part of sips. With just a post- 
>> facto  diagnostic (like History-Info) I'd have to first establish  
>> a dialog,  then look and see if I liked the security, then send a  
>> MESSAGE over  that dialog (considered to be abusing the dialog by  
>> the MESSAGE RFC),  then tear the dialog down.
>
>
> I guess this all gets down to whether stateless SIP is useful at  
> all, which is a superset
> TLS sessions is more "abusive" then just one extra e2e round trip  
> after the dialog is
> established -- consider the zillions of round trips just to get  
> things going on a fairly
> self-contained, which while feasible for authentFrom [email-masked] Thu Nov 02 13:03:03 2006
From: Dean Willis <[email-masked]>
Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)
Date: Thu, 2 Nov 2006 11:57:31 -0600
To: Michael Thomas <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>, IETF SIP List <[email-masked]>,
	Francois Audet <[email-masked]>, "Elwell,
	John" <[email-masked]>, Juha Heinanen <[email-masked]>

On Nov 2, 2006, at 10:00 AM, Michael Thomas wrote:

>
> Surely you could send some sort of NOP first? I guess that one of  
> the my perhaps
> not hidden assumptions here is that you are amortizing the  
> connection for more

Sure you could. However, unless you bound the operation with a dialog  
(INVITE transaction, usually) there's no assurance that subsequent  
requests will follow the same path. So you might send a sip: NOP that  
would report "secure", then follow it with a sip: MESSAGE that would  
not be secured.

>> I want to send you a text message with moderately sensitive info.  
>> So  I send it using your sips: request URI. If it turns out that a  
>> proxy  out there can't honor that request for transitive  
>> protection, it  rejects the request rather than exposing my  
>> sensitive text-bits to  the harsh climes of an unencrypted channel.
>>
>> So I still need that "I want it" part of sips. With just a post- 
>> facto  diagnostic (like History-Info) I'd have to first establish  
>> a dialog,  then look and see if I liked the security, then send a  
>> MESSAGE over  that dialog (considered to be abusing the dialog by  
>> the MESSAGE RFC),  then tear the dialog down.
>
>
> I guess this all gets down to whether stateless SIP is useful at  
> all, which is a superset
> TLS sessions is more "abusive" then just one extra e2e round trip  
> after the dialog is
> established -- consider the zillions of round trips just to get  
> things going on a fairly
> confidentiality. So statelessness in combination with security  
> seems unlikely to be
> sucessesful to me at least. So let's just not keep investing time  
> on it? I've become
> pretty sympathetic to the idea of deprecating UDP over the years  
> given these
> realities.

I don't disagree, but that sort of change requires normative change  
to standards-track RFCs, not usage guidlines.

>
> Part of this for me is that SIP is just too damn complicated, and  
> it's painfully
> proven to be vexingly difficult to unify. It would be really nice  
> to just chuck

Choir preaching!

> So I'll try to put this into a more constructive light rather than  
> the whine above:

Might be reasonable. There are limits, of course, to what one can  
change in a BCP. For example, one can say "The RFCs allow options A  
and B. A has been proven not to work, so we suggest you use B". One  
can't add a new option with a BCP. And unfortunately, we may need a  
new option in order not to run afoul of the current RFC-tangle.

--
Dean