Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 25 May 2006 09:59:08 -0400

Maybe put the lock in a bunny's mouth to show that it is only
hop-by-hop.

The "lock icon" to be meaningful should be consistent.  
HTTPS has already set the standard for what this means.

Mike

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: Wednesday, May 24, 2006 9:05 PM
> To: Vijay K. Gurbani; Paul Kyzivat (pkyzivat)
> Cc: Sip
> Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips
> 
> I agree with what Vijay is saying.
> 
> Deprecating sips will do no good.
> 
> We just need to explain what sips means (and doesn't mean).
> 
> And, yes, it does NOT mean a reliable lock icon. If we need a 
> lock icon, that's something different.
> 
> 
> > -----Original Message-----
> > From: Vijay K. Gurbani [mailto:[email-masked]]
> > Sent: Wednesday, May 24, 2006 15:56
> > To: Paul Kyzivat
> > Cc: Sip
> > Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips
> > 
> > 
> > Paul Kyzivat wrote:
> > > Yeah, maybe it will be possible to get to the point where,
> > if none of
> > > the hops is lying, then it is known that all hops use TLS. 
> > And maybe
> > > that means you know with some certainty that you are connected to 
> > > something that elements you (transitively) trust claim is
> > authorized to
> > > act on behalf of the address you called.
> > [...]
> > > *If* that is the case, then maybe it is worth doing and worthy of 
> > > bestowing that lock icon. If that isn't the case, then I
> > fail to see the
> > > point of doing it at all.
> > 
> > We should not claim that sips is capable of locking the icon. 
> >  We should not claim that sips is capable of solving the prisoner's 
> > dilemma problem; it is not.  It is not capable of an end-to-end 
> > security model.  It will not work in an adverserial network 
> where no 
> > one trusts anyone else.
> > 
> > Correct me if I am wrong, but we did not design SIP to work in a 
> > completely adverserial network.  We trust our proxies to 
> "do the right 
> > thing"  -- be that forking to multiple endpoints or doing a 
> transport 
> > conversion, or interfacing to the right location server, or simply 
> > proxying our requests in a sane manner.
> > 
> > But, assuming that we get beyond this blocking point, much as we 
> > bestow trust in our proxies to do the right thing, I don't see the 
> > harm in using sips in a hop-by-hop security model *as long as we 
> > enunciate what the drawbacks are*.  What has been missing 
> thus far has 
> > been the notion of where does sips and TLS help and where 
> they don't.  
> > The last set of drafts coming out on this subject has, at the very 
> > least, shed some light on this.
> > 
> > - vijay
> > --
> > Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
> > Bell Laboratories, Lucent Technologies, Inc.
> > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
> > 
> 
> _______________________________________________
> 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: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 25 May 2006 09:43:33 -0500

> Maybe put the lock in a bunny's mouth to show that it is only

I like that!  It's very descriptive and intuitive.  Maybe we
can use the Energizer bunny ;-)

> HTTPS has already set the standard for what this means.

Agreed, but then SIP is not HTTP.  The way we use proxies
in SIP and the nature of services they provide is different --
but you already know that.

Maybe we ought to have a new scheme, sipss (for strong security)
that will have the same semantics as https does across a chain
of proxies; namely once the destination is reached, the transport
is upgraded and certs/keys/ciphers are exchanged/negotiated
end to end.

That way, sips suffices for h-b-h security, and those requiring
e2e security can use the sipss scheme.

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 May 2006 11:54:58 -0400

I don't care what the indicator is. But it needs to be some indicator 
that is clear.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 May 2006 14:50:03 -0500

> can use the Energizer bunny ;-)

Yes, like this thread. It just keeps on going!

>
>> The "lock icon" to be meaningful should be consistent.  HTTPS has  
>> already set the standard for what this means.
>

I kind of like this. SIPSS: should either use a pass-through-TLS (ala  
HTTP) or redirect-only model, require media encryption, two-way  
certification, and a few other things. How about an ID proposing the  
requirements and the "what the user gets out of a lock icon" discussion?

--
Dean

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 25 May 2006 16:02:36 -0500

> requirements and the "what the user gets out of a lock icon" discussion?

OK.  I will get one out before Montreal.

Thanks,

- vijay

---

From: [email-masked]
Date: Thu, 25 May 2006 23:14:48 +0200

Better to use a different name, e.g. SIPSEC 

SIPSS looks like SIPS misspelled. That´s a bad start for something intended to be secure : too easy for a user 
to make a typo

Regards,

jeroen

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 May 2006 18:46:11 -0400

> SIPSS looks like SIPS misspelled. That´s a bad start for something intended to be secure : too easy for a user 

While I agree in part, I don't think it is likely that many people will 
be making secure phone calls by typing in SIPSS or SIPSEC URIs. Most 
people don't type in HTTPS URIs either. Most of those are the result of 
link following. I imagine secure phoning will be the same, or via some 
sort of "secure" option button on a phone.

In my practical experience, a web "session" is usually started using 
HTTP, and then transitions to HTTPS later. I suppose something similar 
might be possible with SIP: you could start a call with SIP and exchange 
indications that SIPS is supported. Then one side could REFER/Replaces 
the other side to a SIPS/SIPSS/SIPSEC URI that allows a secure session.

I think we are badly in need of the use cases, so we can ensure that we 
have a mechanism that supports them, rather than inventing a mechanism 
that supports nothing useful.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 25 May 2006 22:42:08 -0500

Paul Kyzivat wrote:
> link following.

I think your mileage may vary.  I think what you say would
have been true a year or so ago.  However, given that the media
has scared the public crazy about Internet security, chances are
fairly good that the average person not associated with the
IETF knows the difference between a http and a https URI.  They
may not know what goes underneath the hood when they specify a https
URI, but they have come to associate https with trust that
they bestow when commencing on e-commerce and banking and
travel reservations, and getting their yearly credit report
free online, and what have you.

Thanks,

- vijay

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 26 May 2006 08:26:59 -0400

My use case is real simple:

A subscriber to a VoIP services is calling a subscriber at another VoIP
service.  The originating subscriber trusts his VoIP service proxies, and is
willing to trust the proxies in the terminating service.  The reverse is
true.  The VoIP services peer.  There may be a peering point proxy, but if
there is, the VoIP services trust it.

There is very simple transitive trust all along the path.  MITM is a
possibility.  Exchange between the peers may happen on the open Internet.

I think this is the kind of case we can construct a sips or sips-like 
"TLS was used all the way" path.

Brian

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 6:46 PM
To: [email-masked]
Cc: Sip; Vijay K. Gurbani; Dean Willis
Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips

[email-masked] wrote:
> SIPSS looks like SIPS misspelled. That´s a bad start for something
intended to be secure : too easy for a user 

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 26 May 2006 15:37:48 +0300

> "TLS was used all the way" path.

yes, if TLS is really used also between the last proxy and the called
UAS, which is NOT currently mandated by rfc3261 and which jonathan
suggested to be done.

-- juha

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 26 May 2006 08:44:19 -0400

Agree.  If it's "TLS all along the path" then it includes the last hop.

Brian

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: Friday, May 26, 2006 8:38 AM
To: Brian Rosen
Cc: 'Paul Kyzivat'; [email-masked]; 'Sip'; 'Vijay K. Gurbani'; 'Dean
Willis'

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 May 2006 10:28:01 -0400

> "TLS was used all the way" path.

If we trust the proxies, then why don't we also trust them to make 
reliable connections for each hop? If a hop must go over the open 
internet then TLS is one way to ensure that it gets to the right place. 
If a hop takes place in some other environment there may be other ways 
to achieve the same guarantee. Its all based on trust in the proxies 
anyway, so why should we insist on TLS for *every* hop?

And further, what was the point of going to this trouble if the media 
stream can't, or just isn't, secured?

It seems like you end up with three degrees of security/privacy:

1) no confidence that you are connected to the intended party,
    and no confidence that your media stream is secure from snooping

2) confidence that you are connected to the intended party,
    but no confidence that your media stream is secure from snooping

3) confidence that you are connected to the intended party,
    and confidence that your media stream is secure from snooping

How should an operator portray this to the user?

a) tell the user nothing. let the user think that all calls are
    equally secure or insecure

b) indicate which of the three cases applies to each call

c) allow all three cases, but only use a binary security indicator:
    insecure for (1), secure for (2) and (3)

d) allow all three cases, but only use a binary security indicator:
    insecure for (1) and (2), secure for (3)

e) restrict the possibilities to no more than two, and then
    provide a binary indicator for which of the two cases applies.
    (E.g. don't permit (1), and provide a security indicator for (3))

f) restrict the possibilities to one, and provide no indicator

Not all of these make sense. Any claim the operator makes had better be 
true, or it will be subject to lawsuits. If no indicator is given, then 
the operator had better only promise the worst case of what it supports. 
In that case, the operator has no incentive to provide more than what it 
claims to provide. (Why bother to provide security part of the time if 
you can't get any credit for it?)

If a security indicator is given in some cases, then again it had better 
not over-promise. So all that can be promised is the worst case security 
that may be provided with that indicator. And there is again no 
incentive for the operator to provide more security than is promised.

So ultimately it comes down to how many security variants it is possible 
to indicate, that users will understand. I think users can understand 
(1) and (3), but I am not at all sure users will be able to understand (2).

I think the only way (2) makes sense is (e) where you don't permit any 
calls of type (1). There may be cases (e.g. military) where that is a 
viable option. But for general deployment in the next few years I 
question its viability. In the long run I think we should be aiming for 
all calls to be of type (3).

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 26 May 2006 19:49:25 +0300

Paul Kyzivat writes:

 > Its all based on trust in the proxies 

i remember reading just last week than NSA is splitting fibers between
providers and capturing everything.  sips MUST indicate to the end user
that TLS is used on EVERY hop.

 > stream can't, or just isn't, secured?

have you checked this:

http://www.philzimmermann.com/EN/zfone/index.html

end users can do it without any participation of proxies.

- juha

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 26 May 2006 11:51:05 -0500

> anyway, so why should we insist on TLS for *every* hop?

This is essentially Dean's argument for leaving things alone at
the last hop.  The counter argument is that even the last hop
must be protected by TLS.  Some consensus would need to be reached.

> stream can't, or just isn't, secured?

Is a session less secure if h-b-h TLS is used for signaling and
ZRTP, EKT, RTP/DTLS for media?  Based on Dan Wing's analysis
at the last raiarea meeting, I think the current thinking is to
do key exchange for media in the media plane.  Doing it in the
signaling plane does not work well with services such as forking,
or scenarios such as arrival of media before the SDP answer
arrives in signaling.

Furthermore, there will be services that are signaling only.
The one that comes to mind is disseminating presence information.
That does not require any media, but does require signaling
confidentiality.  It's probably best if e2e confidentiality is
used, but I beleive h-b-h confidentiality across a trusted
proxy chain would be adequate in a lot of cases.

Thanks,

- vijay

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 26 May 2006 12:59:33 -0400

Maybe I am missing something in this discussion.
I have recently made changes so that I can use StartTLS for reading 
some of my email, and secure submission.
I am not under any illusion that this protects my email 
end-to-end.  But it is useful.
SIPS gives me at least that much protection, and asks the proxies to 
attempt to provide more protection.

This seems distinctly useful.

Whether the icon should be a bunny carrying a lock, or some other 
icon, is really not a question for this group (I think.)

Yours,
Joel M. Halpern

---

From: Michael Thomas <[email-masked]>
Date: Fri, 26 May 2006 13:10:01 -0700

>that TLS is used on EVERY hop.

For some value of EVERY. Namely, one.

       Mike

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 May 2006 19:04:03 -0400

> end users can do it without any participation of proxies.

I guess it depends on what your goals are.

That approach is probably good in the case where you actually have keys 
for the people you call. And I don't think it depends on having SIPS 
either. If you used SIP, and got somebody different than you thought, 
then you wouldn't have the right keys to talk to them.

But ZRTP is no good for having a secure conversation with somebody you 
don't have keys for, such as your bank, or anybody you are giving a 
credit card number to.

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 27 May 2006 09:23:34 +0300

> don't have keys for, such as your bank, or anybody you are giving a 

bank or shop can very publish their key on their web site which i can
add to my ssh known_hosts style list.

-- juha

---

From: "Frank W. Miller" <[email-masked]>
Date: Sat, 27 May 2006 19:36:48 -0400

I don't think this is right.  If I read the ZRTP draft correctly (and
thats not a certainty), it generates keys dynamically, each side
essentially creating a public key for the other end on demand.  No key
administration is required.

FM

---

From: Dean Willis <[email-masked]>
Date: Sat, 27 May 2006 21:58:13 -0500

> that TLS is used on EVERY hop.

Sine the proxies can tap the signal, what difference does it make? I 
don't trust the proxies. NSA will just "split" them too. We need 
something that's like TLS, end-to-end, or we don't have much of 
anything. And using that level of protection needs to be the norm, not 
the exception.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 27 May 2006 22:08:52 -0500

> administration is required.

The session key is constructed based on an exchange of public-key parts 
from each end. In that exchange, you get to see the "fingerprint" of 
your partner's key. You can validate this against a published 
fingerprint, if you have such available.

If you don't, it works if you know the other party well enough to verify 
to your satisfaction that you have reached the correct party, and then 
go through the verbal fingerprint verification process.

If you connect to a party you don't know well enough to identify, and 
you don't have a key for them, you can still do a verbal verification of 
the fingerprint to at least know that there's not a MITM. Of course, you 
still won't know who you're talking to. But at least next time, you'll 
know your talking to them again.

--
dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 27 May 2006 21:53:17 -0500

Vijay K. Gurbani wrote:
> Paul Kyzivat wrote:
> 
>> While I agree in part, I don't think it is likely that many people 
>> will be making secure phone calls by typing in SIPSS or SIPSEC URIs. 
>> Most people don't type in HTTPS URIs either. Most of those are the 
>> result of link following.
> 
> 

I dunno. I just spent two weeks with my parents (they have DSL now, 85 
miles from town in the middle of the desert) and upgraded my father's 
computer while I was there.

They don't know the differentce between a URL and a search string (and 
frequently type the wrong one into the wrong entry field), never typed 
httpannything in their lives, and wouldn't know a lock icon if it bit 
them (and my father used to write 6803 machine code in his head -- 
without an assembler).

A week after I had networked his shiny new PC, during which he had been 
using his browser nonstop, my father asked how to connect to the 
Internet from his new PC. He was shocked and dismayed to learn that he 
had been on the Internet all week.

My mother, who has had a laptop with WiFi for two years and a dialup 
connection for five or six, still believes she is only connected "to the 
  Internet" when she runs her Juno email client -- it is an abomination 
that runs IE "in a frame".

At the other extreme, I almost always type https:, and if it doesn't 
work, I curse a few times, and then decide whether I'm going to risk http.

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Sun, 28 May 2006 08:59:32 +0300

> administration is required.

the page says somewhere that it operates similarly to ssh.  ssh also
generates keys dynamically and no admin is needed, but when you connect
to a new party, ssh client asks if you want to trust the key of the
other party and if so it adds it to your known_hosts file.  if you
already have key of the other party in your known_hosts file, ssh client
warns you if the key of the other party does not match the one you have
in file.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Sun, 28 May 2006 09:02:50 +0300

Dean Willis writes:

 > Sine the proxies can tap the signal, what difference does it make? 

i don't disagree with you that end-to-end TLS would be a good thing.
but it does make a difference if NSA needs to get to operators computer,
because then they need physical access to operators computer room, which
is difficult to do unnoticed.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Mon, 29 May 2006 03:22:39 -0500

> is difficult to do unnoticed.

Nah, they  just tell the operator to give them root access on all proxies, 
then make their tap. What operator (besides maybe Qwest, of whom I am 
currently very proud) would say no?

Or more likely, they tell the proxy makers to leave them a back door, so they 
can tap the proxies without even asking permission. I'm sure stuff like this 
happens, if not with the NSA, then with some other agency in some country or 
another.

--
Dean

---

From: "Dale R. Worley" <[email-masked]>
Date: Mon, 29 May 2006 15:07:52 -0400

> > is difficult to do unnoticed.

If the NSA needs to be *let into* the computer rooms of network
operators, it's not doing its job.  They've got submarines for tapping
trans-oceanic fiber cables...

But I'm hoping we can make the job hard enough that not every private
investigator with $1,000 can get anything he wants.

Dale

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 29 May 2006 21:27:49 -0700

On May 27, 2006, at 8:08 PM, Dean Willis wrote:

> The session key is constructed based on an exchange of public-key  
> parts from each end. In that exchange, you get to see the  
> "fingerprint" of your partner's key. You can validate this against  
> a published fingerprint, if you have such available.
>
> If you don't, it works if you know the other party well enough to  
> verify to your satisfaction that you have reached the correct  
> party, and then go through the verbal fingerprint verification  
> process.
>
> If you connect to a party you don't know well enough to identify,  
> and you don't have a key for them, you can still do a verbal  
> verification of the fingerprint to at least know that there's not a  
> MITM. Of course, you still won't know who you're talking to. But at  
> least next time, you'll know your talking to them again.

Unless or course the are using a different phone this time in which  
case you will come to the conclusion that this is not the same  
person. Of course no one has more than one phone. Of course there are  
solutions to this - I think ZRTP might want to include one of them as  
most people seem to have more than one phone.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 29 May 2006 22:02:51 -0700

I plan to very seldom sends emails with my AD hat on but I think I  
will make an exception for this one. This may be a learning  
experience for me in trying to provide some of that "Steering" part  
of the IESG role.

sips is not analogous to https or the lock icon on a browser. When  
firefox puts up the lock icon, some of the things it tries to mean is  
that you are connected to the website you think you are connected and  
your data in encrypted.

sips was never meant to imply that you were talking to the person in  
your To header field value or that your RTP is somehow encrypted. It  
does not solve either of those problems. We have several working  
groups in the RAI  and Security area that are working to provide  
solutions to these two security issues and others. That sips does not  
provide these does not in any way mean that sips should be  
deprecated. In many situations, sips provides a very powerful  
security primitive that protects against several things. Many of  
these were brought up on this thread.

I would like to point at one in particular. Imagine the hypothetical  
case where Brian has a phone at Neustar and trusts Neustar, and I  
have a phone at Cisco  and trust Cisco. Using sips for a call that  
goes from Brains phone to the Neustar proxy to the Cisco proxy and to  
my phone provides a surprisingly strong system for many attacks. Note  
that Brian's proxy found no need to route the call through an AT&T  
proxy in the middle. Now Brian and I might not want to use this  
signaling channel for things that we did not want Cisco or Neustar to  
know about but this channel could help secure many things that were  
reasonable business items between Cisco and Neustar. In this case,  
sips can help be a tool that can be used to achieve the desired  
security. For communications where I would not trust Cisco or  
Nuestar, we will might use AOR at domains we trust for that purpose -  
like our own domains.

I think that at the high level, the semantics of sips are simple. We  
want it to mean that every hop from the UAC to the UAS was integrity  
and confidentiality protected at a reasonable level assuming  
transitive trust. This can be very useful. At the more fine details  
level, we have some parts that are unclear in how to implement it, we  
probably have some bugs in the spec, and perhaps we even one place  
where we made a bad choice that we may correct. I'm very keen on this  
draft - I want it to try and sort out the details that are missing or  
wrong.

sips is not the answer to every problem. Note even 3261 had S/MIME  
and we have done Identity, SRTP, and many more. However SIPS is a  
useful tool for creating security solutions and we should sort out  
any missing details.

Cullen <with my AD hat on>

Now bring on the rotten vegetables.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 30 May 2006 06:17:42 -0700

Cullen Jennings wrote:

> sips is not the answer to every problem. 

My question is whether it's answer to _any_ problem. My last attempt at
getting and answer was fruitless. What attacks do SIPS thwart in real life
that honest operators and transport=tls doesn't? Real life good guy, bad guy
situations would be helpful.

       Mike

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 30 May 2006 09:11:32 -0500

Michael Thomas wrote:
> that honest operators and transport=tls doesn't? Real life good guy, bad 
> guy situations would be helpful.

Sorry -- catching up after a forced, and not entirely un-welcome,
lull introduced by the weekend.

Dean has pointed out one answer to this; namely, "reduces the
probability of an accidental downgrade by intermediate proxies
between the UAC and the proxy responsible for the AOR, if those
proxies bother to honor it."

A couple more: sips provides confidentiality of traffic
and authentication of a proxy and registrar to a UAC.  Admittedly,
one could do this with transport=tls, but this particular
construct is deprecated in rfc3261.  Currently, there is no means
for a UAC to authenticate a registrar or a proxy; sips at the
very least, allows for the signaling between the UAC and a
registrar to be on an confidential and authenticated channel.

To other services such as transporting presence, sips provides
confidentiality.  The semantics of transport=tls, if un-deprecated
would be limited to next hop only; the semantics of sips -- if we
tighten the spec up appropriately -- are confidentiality across
all participating hops.  To me, this sort of a construct is well
worth it if it provides confidentiality for my presence information.

Thanks,

- vijay

---

From: Dean Willis <[email-masked]>
Date: Tue, 30 May 2006 16:35:17 -0500

On May 30, 2006, at 12:02 AM, Cullen Jennings wrote:
>
> I think that at the high level, the semantics of sips are simple.  
> We want it to mean that every hop from the UAC to the UAS was  
> integrity and confidentiality protected at a reasonable level  
> assuming transitive trust. This can be very useful. At the more  
> fine details level, we have some parts that are unclear in how to  
> implement it, we probably have some bugs in the spec, and perhaps  
> we even one place where we made a bad choice that we may correct.  
> I'm very keen on this draft - I want it to try and sort out the  
> details that are missing or wrong.
>

"Correcting" the "bad choice" in the proposed way would be counter to  
the semantics you give above.

It's been proposed that we should change RFC 3261 to require that, if  
sips: is used, then TLS MUST be used on all hops. This runs afoul of  
architectures where some other mechanism, notably IPSEC, is used on  
some hops.

If we make this proposal a requirement, we end up in in a situation  
where we frequently cannot use sips: on the UAC to serving-proxy hops  
because some other security mechanism is used on the back side of the  
serving proxy. And since sips: is the only "please secure me"  
indicator we have, this means that we have no way to request any  
security treatment at all in this situation -- in short, that we're  
requiring people to NOT secure some links.

This doesn't sound particularly rational.

Perhaps what you really want is a rule more like "Proxies MUST NOT  
forward requests with a sips: URI onto links lacking reasonable  
integrity or confidentiality mechanisms. An example of a reasonable  
mechanism would be TLSThis would be roughly equivalent to a "Proxy- 
Require: link-security" option mechanism that I recall someone else  
proposing.

This would actually benefit deployability, since it would also allow  
using sips: on calls from UACs that are using non-TLS (but secure)  
links to their proxies, whereas RFC 3261 as-is allows it only in the  
other direction.

Now, let's consider retargeting -- the thing that serving proxies do  
when they replace a request-URI with a URI that was registered as a  
contact.  It has been proposed that we adopt the rule "Proxies that  
retarget (change the request-URI) MUST NOT retarget a request that  
was originally targeted to a sips: URI to any other URI type." Well,  
that sort of does in forwarding your calls to a tel: URI while still  
getting the exposed SIP links protected. We could perhaps live with  
that, but it does seem to be a waste. Here at least we could get more  
mileage out of a proxy-require option tag that requires the resulting  
tel: request to traverse only secure links.

But in any case, sips: remains only a marginal indicator of security.  
It's kind of like a note by the door of the office that says "Last  
one out, please lock the door". If somebody forgets, or choses not  
to, the door isn't locked, and nobody else knows. It's not the lack  
of security that gets me -- it's the lack of KNOWING that there is no  
security. Our current usage of sips: is no more secure and generally  
applicable to the Internet than the trust-domain protections around  
the privacy of P-Asserted-Identity are, and we made that a P-header.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 30 May 2006 17:32:26 -0500

OK guys,

It's good that I actually enjoyed my long week-end instead of diving
into this thread.

What I plan to do is update the draft before Montreal with some of the
"open issues" that were flagged on this list. Or maybe I'll just write a
bunch of slides on them. I will request some time for the topic...

To summarize where I think we are, without diving into 
endless pointless circular arguments:

- OPEN ISSUE: Should we mandate TLS for all the hops when SIPS is used?
	- We have people on both sides of the arguement.

- Everybody seem to agree that sips is NOT an indicator that end-to-end
  security will be used (or has been used). 

- OPEN ISSUE: Should we deprecate completely sips, or should we clarify 
  what it means?
	- While we have people on both sides,  I personally think that 
        deprecating it not a good idea at all, and am strongly in the
        "explain what it means" camp. We could even restrict where it
        can be used (e.g., in a Request-URI). Furthermore, we have
        a clear statement of direction from our AD along those lines.

- There seem to be some broad agreement from the list that transport=tls
  shouldn't really be deprecated (as it is today in RFC 3261), but
rather be used 
  to describe explicitely tls usage on a specific hop. This is different
from 
  my current draft where I use sips in contacts for example, for that
purpose. 
  I'm OK with the idea, and I think we have somewhat of a consensus (I
haven't 
  seen anybody liking my attempt to use sips for that purpose in the
draft).
  I can work this change into a new version of the draft.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 30 May 2006 15:44:26 -0700

Vijay K. Gurbani wrote:

>> that honest operators and transport=tls doesn't? Real life good guy, 
>> bad guy situations would be helpful.
>
>

How does it do that? Why does this sort of behavior require an ill
conceived protocol element when it is really a BCP in disguise?

> registrar to be on an confidential and authenticated channel.

So SIPS is overloaded with transport=tls; Bletch.

> all participating hops.

No. That is simply incorrect, and why this is so deeply problematic.
And it leaves people with the mistaken impression that there is
https style security when there is absolutely no way to test or
count on that.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 30 May 2006 15:46:39 -0700

I think that the first and foremost thing to do here is determine what 
threats you
are actually trying to prevent. The reason we are where we are now is 
because
we "solved" the problem without knowing what the problem was.

       Mike

---

From: Dean Willis <[email-masked]>
Date: Tue, 30 May 2006 20:33:48 -0500

> conceived protocol element when it is really a BCP in disguise?

Because we operate with the presumptions that 1 ) most people don't  
want security, and 2) proxies will be extremely careless with our  
data unless we politely ask them not to. Further, we want to tell the  
proxies that if they aren't willing to be careful with our data, we'd  
rather they tell us up front so we can take our data elsewhere.

Therefore, we need a protocol element to be able to ask the proxy to  
do what was probably "the right thing" all along.

> https style security when there is absolutely no way to test or

Well, it sort of provides confidentiality, except to the proxies, as  
long as the proxies really are as careful with our data as we asked  
them to be which they may or may not be and we have no way of  
verifying. Sometimes, as Cullen has pointed out, this is good enough,  
or at least enough better than nothing that it is worth having.

Ok, I am failing to reassure myself here.

I'm detecting five different use cases that people are asking for:

1) I don't care about security, just make it work.

2) Use as much security as you can, but I'm willing to accept  
downgrades without being informed if you must.

3) I want hop-by-hop security that provides protections roughly  
equivalent to TLS if it were used on a hop-by-hop basis, and I want  
my request aborted and to be informed on it if you can't make that  
happen.

4) I want hop-by-hop protection using TLS, and I want my request  
aborted and to be informed on it if you can't make that happen.

5) I want my signaling locked-down end-to-end, and insist on being  
able to verify that this is the case. And if we exchange media, I  
want that locked-down too, and I want to be able to verify that too.

Right now, I think we're arguing about a) whether sips: means case 2,  
3, or 4. b) If sips: doesn't include case 2, do we need another  
mechanism for that, and 3) whether any of case 2, 3, or 4 are really  
useful.

Personally I see some value in cases 2 and 3, none in case 4 that  
isn't achieved by 3, and a whole lot more in the currently  
unobtainable case 5, for which Vijay has proposed the new URI class  
"sipsec:"

3261, oddly enough, doesn't address any of these use cases. Rather,  
it says "I want hop-by-hop protection using TLS as far as the proxy  
corresponding to the request-URI, and and I want my request aborted  
and to be informed on it if you can't make that happen. After the  
request has reached the node corresponding to the request-URI, I want  
as much security as possible, but leave the selection and application  
of that security in the hands of the callee and its supporting nodes.  
If the callee didn't register with a sips: contact or happens to be a  
PSTN gateway, I still want the call to go through, and I don't need  
to be notified about the change in the security envelope.

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 30 May 2006 23:07:43 +0300

Vijay K. Gurbani writes:

 > construct is deprecated in rfc3261. 

transport=tls is used in practise, because no other ways exist to tell
that tls is to be used on the next hop.  there is thus still need for it
and sips is not a replacement due to its end-to-end nature.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 31 May 2006 15:16:08 +0300

Francois Audet writes:

 >         "explain what it means" camp. 

i proposed that we deprecate SIPS UNTIL it's meaning is well defined
(which according to SIP WG current practise may take MANY years).  it

-- juha

---

From: Robert Sparks <[email-masked]>
Date: Wed, 31 May 2006 09:35:23 -0500

Just to be precise -

There _is_ a way to tell the next hop to use TLS (or whatever protocol)
using 3263, so "next hop" probably isn't the real motivation for the  
continued
existence of transport=tls in the wild.

I see four possible motivations for its continued presence:

1) The people using it are just testing things point-to-point in labs  
and don't
      want to take on the pain of setting up DNS. (We should  
recognize this group
      exists, collectively sigh, then move on).

2) The elements using it are endpoints with ephemeral addresses, but  
want
      incoming connections to come over TLS. They have certificates  
such that
      an incoming TLS connection makes sense, and no NAT/FW policies  
that
      prevent a TCP connection attempt from reaching them in the  
first place,
      but they have no name in DNS that they can add RRs for.
      (Some have argued that this is fringe, and an unrealistic case  
to design around.
       The P2P folks, for example, probably disagree).

3) The designers of the application using it do not agree with the  
assumptions and
      constraints placed on transport selection in 3263. The model in  
that document
      assumes that the preference for transport coming into an  
element is constant across
      all resources. It does not allow us, for example, to indicate  
preference for TLS for
      one set of usernames but UDP for another.

4) The designers of the network using it refuse to use DNS in that  
network at all
      (but still want TLS...)

Are there other motivations that I've missed?

RjS

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 31 May 2006 10:42:08 -0400

Dean,

I really like your characterization of the alternatives here!

More below.

	Paul

Dean Willis wrote:
> Because we operate with the presumptions that 1 ) most people don't want 
> security, and 2) proxies will be extremely careless with our data unless 
> we politely ask them not to. Further, we want to tell the proxies that 
> if they aren't willing to be careful with our data, we'd rather they 
> tell us up front so we can take our data elsewhere.
> 
> Therefore, we need a protocol element to be able to ask the proxy to do 
> what was probably "the right thing" all along.
> 
> long as the proxies really are as careful with our data as we asked them 
> to be which they may or may not be and we have no way of verifying. 
> Sometimes, as Cullen has pointed out, this is good enough, or at least 
> enough better than nothing that it is worth having.
> 
> 2) Use as much security as you can, but I'm willing to accept downgrades 
> without being informed if you must.
> 
> equivalent to TLS if it were used on a hop-by-hop basis, and I want my 
> request aborted and to be informed on it if you can't make that happen.
> 
> 4) I want hop-by-hop protection using TLS, and I want my request aborted 
> and to be informed on it if you can't make that happen.
> 
> 5) I want my signaling locked-down end-to-end, and insist on being able 
> to verify that this is the case. And if we exchange media, I want that 
> locked-down too, and I want to be able to verify that too.
> 
> 
> Right now, I think we're arguing about a) whether sips: means case 2, 3, 
> or 4. b) If sips: doesn't include case 2, do we need another mechanism 
> for that, and 3) whether any of case 2, 3, or 4 are really useful.
> 
> Personally I see some value in cases 2 and 3, none in case 4 that isn't 
> achieved by 3, and a whole lot more in the currently unobtainable case 
> 5, for which Vijay has proposed the new URI class "sipsec:"

Of these, I find only 1,3,5 to be at all interesting.

Of those, I think 3 falls in the same pot as all the transitive trust 
"features" such as P-Asserted-ID, and probably makes sense in those 
environments. Its better than nothing if you have a service provider you 
are willing to trust, and it is probably the best we are going to get 
from a lot of service providers.

I would much rather have 5 than 3, but:
- its not at all clear to me that we know how to provide it in a
   practical way
- I think a lot of major operators would not wish to provide this
   unless forced. (either by laws or competitive pressures.)
- if there is any law on this subject, it would probably be to
   ban 5 rather than to require it. :-(

> 3261, oddly enough, doesn't address any of these use cases. Rather, it 
> says "I want hop-by-hop protection using TLS as far as the proxy 
> corresponding to the request-URI, and and I want my request aborted and 
> to be informed on it if you can't make that happen. After the request 
> has reached the node corresponding to the request-URI, I want as much 
> security as possible, but leave the selection and application of that 
> security in the hands of the callee and its supporting nodes. If the 
> callee didn't register with a sips: contact or happens to be a PSTN 
> gateway, I still want the call to go through, and I don't need to be 
> notified about the change in the security envelope.
> 
> -- 
> Dean
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 31 May 2006 10:49:23 -0400

Dean - you were on a roll yesterday. Again I violently agree.

Perhaps we need both SIPS and Proxy-Require:link-security. Then the 
meaning of sips could be simplified. The sips is an indication of the 
target's expectation, while the Proxy-Require is the caller's 
expectation. The first node to place a sips URI into the R-URI would 
also add the Proxy-Require, in order to honor the target's desires. 
Proxies otherwise would simply honor the Proxy-Require. But the 
Proxy-Require could also be used with tel or sip if that is what the 
caller desires.

	Paul

Dean Willis wrote:
> architectures where some other mechanism, notably IPSEC, is used on some 
> hops.
> 
> serving proxy. And since sips: is the only "please secure me" indicator 
> we have, this means that we have no way to request any security 
> treatment at all in this situation -- in short, that we're requiring 
> people to NOT secure some links.
> 
> mechanism would be TLSThis would be roughly equivalent to a 
> "Proxy-Require: link-security" option mechanism that I recall someone 
> else proposing.
> 
> using sips: on calls from UACs that are using non-TLS (but secure) links 
> to their proxies, whereas RFC 3261 as-is allows it only in the other 
> direction.
> 
> retarget (change the request-URI) MUST NOT retarget a request that was 
> originally targeted to a sips: URI to any other URI type." Well, that 
> sort of does in forwarding your calls to a tel: URI while still getting 
> the exposed SIP links protected. We could perhaps live with that, but it 
> does seem to be a waste. Here at least we could get more mileage out of 
> a proxy-require option tag that requires the resulting tel: request to 
> traverse only secure links.
> 
> 
> It's kind of like a note by the door of the office that says "Last one 
> out, please lock the door". If somebody forgets, or choses not to, the 
> door isn't locked, and nobody else knows. It's not the lack of security 
> that gets me -- it's the lack of KNOWING that there is no security. Our 
> current usage of sips: is no more secure and generally applicable to the 
> Internet than the trust-domain protections around the privacy of 
> P-Asserted-Identity are, and we made that a P-header.
> 
> 
> -- 
> Dean
>

---

From: "Charles Abondo" <[email-masked]>
Date: Wed, 31 May 2006 11:14:58 -0400

Hi,

I need help on those topics:

1. May I support Options method without supporting any Invite? This means
answering Options request with 200 OK even if I am a Registrar for example.

2. May I have received as a UAS (last hop on a path) a Request with several
Authorisation fields (there is no Sip capable entity after the UAS? If yes,
how do I select one (realm ....)? 

Any help will be appreciated,

Regards,

Charles Abondo

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 31 May 2006 16:14:19 -0700

Michael,

You seem to have a mistaken impression that transport=tls means
something it does not/is actually useful.  Unfortunately,
transport=tls only affects the next hop, it interferes with NAPTR
selection of the actual underlying transport (TCP, UDP, SCTP, DCCP),
it looks really ugly in URIs, and it is a pain in the arse to enter on
a phone keypad.

I don't really believe the last two are a big deal, but the important
thing here is that sips: has the semantics that most folks think
transport=tls should have, but transport=tls actually does not have.

thanks,
-rohan

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 31 May 2006 16:16:03 -0700

On the contrary Juha, the SIP server role can indicate it wants to the
client to use TLS by including the appropriate NATPR and/or SRV
records.

thanks,
-rohan

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 31 May 2006 18:27:24 -0500

I like it too, but I prefer 4 to 3, because 3 is too fuzzy to me, and it
has
been a source of confusion to many.

> Sent: Wednesday, May 31, 2006 07:42
> To: Dean Willis
> Cc: Sip; Michael Thomas; Vijay K. Gurbani
> Subject: Re: Wacky thead of the month award goes to ... 
> Re:[Sip] draft-audet-sip-sips-guidelines: Meaning of sips
> 
> 
> Dean,
> 
> > do
> >>> tighten the spec up appropriately -- are confidentiality 
> across all 
> >>> participating hops.
> >>
> >>
> >> And it leaves people with the mistaken impression that 
> there is https 
> >> style security when there is absolutely no way to test or count on 
> >> that.
> > 
> > aborted
> > able
> > 3,
> > isn't
> > Use [email-masked] for questions on 
> current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 31 May 2006 18:28:11 -0500

Yes, that does make a lot of sense to me.

> Sent: Wednesday, May 31, 2006 07:49
> To: Dean Willis
> Cc: Cullen Jennings; Sip

---

From: Michael Thomas <[email-masked]>
Date: Wed, 31 May 2006 16:38:16 -0700

You're undoubtably right -- I've been wondering about this -- so let me 
say that
my problem is with anything that supposedly dictates security beyond 
what the
next hop is but cannot be verified by the would be dictator.

Barring end to end security of some form, anything that purports to 
elevate the
authenticity and/or confidentiality of the signaling is bound to be 
misinterpretred,
and that's what sips real sin is. If this is really a BCP -- which I'm 
becoming
convinced is the only way to reasonably sell -- not oversell -- this 
desire, then
we should work in that direction. Signaling for security that one has no 
means
of verifying is just plain dumb.

       Mike