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

From: "Elwell, John" <[email-masked]>
Date: Tue, 31 Oct 2006 09:21:01 +0000

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]] 
> Sent: 30 October 2006 21:55
> To: 'IETF SIP List'
> Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: 
> TLS meaning)
> 
> The question is what "some other ... mechanisms are 
> appropriate" means.
> Presumably, if SIPS means something useful (either TLS end to almost 
> end, or some other definition) our hope would be to teach users that 
> if they want security they should use SIPS.
> If we are going to teach them that, and we are going to restrict SIPS 
> to TLS, then what does it mean to say that "some other hop by hop 
> security mechanisms are appropriate?"  Does it mean that other 
> measures are appropriate if the user didn't ask for security?  Does 
> it mean that we should make up another hop-wise secure URI 
> schema (I hope not.)
> 
> The users don't care about what actual protocol is used to provide 
> the security.
> And if they understand at all what a proxy is, and that there can be 
> intermediate proxies, then they presumably don't care which 
> intermediate proxies are in the path.
> They presumably care that proxies do their job right, but that seems 
> to me to be a proxy issue, not an end user issue.
> And proving that the "right" thing happened is clearly a very 
> different problem, with its own complications.
[JRE] Apart from not understanding what a proxy is, users might not even
understand what signalling is. They do understand the concept of
eavesdropping on their speech or whatever.

> 
> 
> Let me turn this around and ask the opposite stupid question.
> What breaks if we say
> 1) Every UAC and every proxy SHOULD utilize security on its requests 
> to the next hop for all requests.
> 2) Every proxy must support TLS.  Every UAC must be able to invoke 
> TLS.  (Already required I believe.)
> 3) Other mechanisms with equivalent security properties may be used 
> instead of TLS to meet (1).
> 
> Then you don;t need SIPS.  And there is no downgrade attack.  I will 
> acknowledge that
> a) this is not what 3261 says
> b) that the equivalence in 3 is complex, and may open the door to 
> some folks making bad choices.  But we already leave that door open 
> in other regards.  The best solution is to be clear about what the 
> security properties are.
[JRE] I guess this is at the back of my mind when I question the usefulness
of SIPS. If a pair of proxies support TLS, why would they not always use TLS
for exchanging requests? With connection re-use, proxies might set up a TLS
connection and keep it. So any request, whether SIP or SIPS, will get routed
over TLS. Routing a request over TCP or UDP in such cases would mean that
TLS is not available. So a SIPS request would get rejected. Now this is fine
if the caller is interested in making the call only if it can be a secure
call (whatever that means), but in many cases the caller would want to
accept an insecure call and the UAC would have to try again with SIP. So in
this case, just doing best effort and notifying the UAC (and perhaps also
the UAS) would be sufficient. The point is, how often does a UAC require TLS
or nothing, as opposed to best effort TLS? And how often do proxies route
SIP requests over TCP or UDP even though TLS would be available to SIPS
requests?

John

> 
> Probably there is some obvious and simple reason the above is 
> a bad idea.
> But this way it is no longer hammering at my skull for release.
> 
> Yours,
> Joel M. Halpern
> 
> At 02:26 PM 10/30/2006, Brian Rosen wrote:
> >I think the distinction some of us are making is that while 
> we agree that
> >some other hop by hop security mechanisms are appropriate, and those
> >mechanisms would use different mechanisms than all-TLS, sips 
> meaning all TLS
> >is useful, and deployable, and we should clarify 3261 to 
> achieve that.
> 
> 
> _______________________________________________
> 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: [email-masked] (Juha Heinanen)
Date: Tue, 31 Oct 2006 11:30:13 +0200

Elwell, John writes:

 > accept an insecure call and the UAC would have to try again with
 > SIP. 

i don't think that signaling security alone without media security means
anything to common users.  this is further justification of dropping
sips.

 > So in

it would make sense to always use tls out as long as the next hop
supports it.  there is no need for sips to tell that to the proxy.

-- juha

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Oct 2006 06:47:00 -0800

So from where I'm sitting there seems to be a lot of people who are regular
contributors to this list who either have doubts, or plain don't think 
SIPS is
a good idea at all. In my experience, that is not rough consensus and 
usually
means that the problem is not baked enough to get to rough consensus. That
pretty much jibes with the current situation because there seems to be very
little agreement as to what the problems that need to be solved are, let 
alone
what the right solution is. Given how SIPS was rushed in at the last 
possible
moment with a working group chomping at the bit to get a new RFC out, it's
not clear to me that there was ever rough consensus on SIPS itself. The 
resulting
years of disagreement pretty much bear out that lack of consensus.

My advise to the working group is to just start over from first 
principles as if
SIPS didn't even exist -- which in reality it doesn't. We need to be 
thinking
about these things for the long term, and if it's not baked it's not 
baked. There
have been many drafts that have lingered on and completely overhauled over
the years. Why SIPS is treated so differently in that respect is somewhat
mystifying because dealing with security for SIP is a genuinely hard 
problem.
It shouldn't be rushed, and it deserves better than a kludgey security 
patina
airbrushed in to get past the IESG.

       Mike

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 31 Oct 2006 10:24:20 -0600

> [JRE] Apart from not understanding what a proxy is, users 
> might not even understand what signalling is. They do 
> understand the concept of eavesdropping on their speech or whatever.

If we had a way to do media security in the media channel, as we are
investigating in RTPSEC, then that issue would be solve. To me, that
would
be a good "padlock icon".

In conjunction with sip-identity, we'd have a pretty good solution. 
To me, that "verified User" padlock would also be useful.

> [JRE] I guess this is at the back of my mind when I question 
> the usefulness of SIPS. If a pair of proxies support TLS, why 
> would they not always use TLS for exchanging requests? With 
> connection re-use, proxies might set up a TLS connection and 
> keep it. So any request, whether SIP or SIPS, will get routed 
> over TLS. Routing a request over TCP or UDP in such cases 
> would mean that TLS is not available. So a SIPS request would 
> get rejected. Now this is fine if the caller is interested in 
> making the call only if it can be a secure call (whatever 
> that means), but in many cases the caller would want to 
> accept an insecure call and the UAC would have to try again 
> with SIP. So in this case, just doing best effort and 
> notifying the UAC (and perhaps also the UAS) would be 
> sufficient. The point is, how often does a UAC require TLS or 
> nothing, as opposed to best effort TLS? And how often do 
> proxies route SIP requests over TCP or UDP even though TLS 
> would be available to SIPS requests?

SIPS is useful when you are prepared to have a session fail if
it is not made securily. It's as simple as that.

So yes, it is useful. Is it a panacea? Absolutely not.

Is TLS without SIPS useful (i.e., for a best-effort like service)?
Absolutely. Is it more useful than SIPS? Probably (at least, I think
so).
I would certainly implement SIP over TLS (with SIP scheme) before
implementing
sips if I couldn't do both. That does not mean that sips is NOT useful.

>From the REAL requirements that I have seen, there is definitively a
need for
the following:

1) No TLS
2) Best-effort TLS (do it if you can)
3) Always TLS (i.e., fail the request if it cannot be on all hops).
  3a) This can be on a per-request session basis.
  3b) This can be for a specific address (e.g.,
sips:[email-masked])

Could we have implemented the functionality of sips without a new URI
scheme?
Yes, we could have used a Proxy-Require for example. Would it have been
better?
Probably. But, it's too late for that. There are many other examples of 
sub-optional design in RFC 3261...

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 31 Oct 2006 10:47:32 -0600

> From: Juha Heinanen [mailto:[email-masked]] 
> Sent: Tuesday, October 31, 2006 1:30 AM
> To: Elwell, John
> Cc: Joel M. Halpern; 'IETF SIP List'
>  > TLS is not available. So a SIPS request would get 
> rejected. Now this is fine  > if the caller is interested in 
> making the call only if it can be a secure  > call (whatever 
> that means), but in many cases the caller would want to  > 
> with  > SIP. 
> i don't think that signaling security alone without media 
> security means anything to common users.  this is further 
> justification of dropping sips.

That is absolute rubish.

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.

>  > So in
>  > this case, just doing best effort and notifying the UAC 
> (and perhaps also  > the UAS) would be sufficient. The point 
> is, how often does a UAC require TLS  > or nothing, as 
> opposed to best effort TLS? And how often do proxies route  > 
> SIP requests over TCP or UDP even though TLS would be 
> available to SIPS  > requests?
> 
> it would make sense to always use tls out as long as the next 
> hop supports it.  there is no need for sips to tell that to the proxy.

And how do you tell it "do not complete the session if the next hop
doesn't
support TLS"?

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Oct 2006 10:51:07 -0600

On Oct 31, 2006, at 8:47 AM, Michael Thomas wrote:

> SIPS didn't even exist -- which in reality it doesn't. We need to  
> be thinking
> about these things for the long term, and if it's not baked it's  
> not baked. There
> mystifying because dealing with security for SIP is a genuinely  
> hard problem.
> It shouldn't be rushed, and it deserves better than a kludgey  
> security patina

I'm very tempted to endorse this, but I think you're missing one thing.

Flimsy as it is, I believe that sips: is as strong as the rest of the  
current SIP security model since it depends on the same trust  
assumptions.

We can't just restart on sips: without restarting from those  
fundamental trust assumptions.

This is not trivial. Many people would argue that it would turn SIP  
into a fundamentally different protocol. I think it needs to be done,  
but I also think we need to clearly document how the current trust  
model (including sips:) works, because that's what's going to be  
deployed in the real world for a relatively long time.

The P2PSIP work is having to re-examine those fundamental trust  
assumptions. My current hope is we can do some work there that can be  
"ported back" into SIP.

--
Dean

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Oct 2006 09:15:59 -0800

> current SIP security model since it depends on the same trust  

I would say that just allowing hopwise TLS is as good as the current SIP
security model. SIPS tries to *extend* the current SIP security model into
something that it is not. Where SIPoTLS is overall neutral to good for the
long term, SIPS actively goes in the wrong direction, and promises something
that it cannot deliver. And thus we're getting all kinds of bizarre 
interpretations
of what SIPS is, one a little more whacky than the next.

And who can argue? I find Brian's interpretation aesthetically unappealing
and unlikely to be of any practical use, but it's at least got internal 
consistency.
Which rather begs the question of what exactly we're trying to 
accomplish here.

       Mike

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 31 Oct 2006 11:48:32 -0600

> I would say that just allowing hopwise TLS is as good as the 
> current SIP security model. SIPS tries to *extend* the 
> current SIP security model into something that it is not. 
> Where SIPoTLS is overall neutral to good for the long term, 
> SIPS actively goes in the wrong direction, and promises 
> something that it cannot deliver. And thus we're getting all 
> kinds of bizarre interpretations of what SIPS is, one a 
> little more whacky than the next.

This is I believe why we are having such a hard time with sips.

The problem is that you (and others) are giving to sips more
ambition than it actually should have.

- SIPS is NOT and indication end-to-end "security" (whatever that
means).
  SIPS does NOT imply a padlock icon.

- Using SIPS in a request URI does NOT imply that all the hops will
  be actually end-up being secure.

- SIPS does NOT say anything about cyphersuites.

The only thing that sips does is allow for extending the SIPoverTLS
hop-by-hop (without sips) like this:

- Allows for dynamically requesting that a request be sent over TLS
  on all hops (except the last one unfortunately) and FAIL that request 
  if not possible. (i.e., it is the equivalent to a Proxy-Require:
SIP/TLS
  if that existed).

That's it. 

> And who can argue? I find Brian's interpretation 
> aesthetically unappealing and unlikely to be of any practical 
> use, but it's at least got internal consistency.
> Which rather begs the question of what exactly we're trying 
> to accomplish here.

We are trying to accomplish 2 things, one short term, and one
long term.

SHORT TERM:

- We need to put a lid on inflated expectations of what SIPS really
means.
  I favor a minimalistic interpretation of what SIPS means.  The sooner
we 
  close that lid, the sooner we can move on to the LONG TERM.

- This interpretation is in line with the spirit of RFC 3261. We are
  trying first to "explain" RFC 3261, with it's limitations, in order to

  move on to something more comprehensive. 

- If SIPS is useful or not in a specific deployment depends on many
factors, 
  depending if its a controlled environment, what security properties
you are 
  looking for, etc. I don't think it is very productive to second-guess
what 
  other people's requirements are. We all have our own specialities,
market, etc.

- I believe we should follow the directives on that front that came from
the chair.

LONG TERM:

- We need to look at end-to-end security. I completely agree that it
probably 
  makes sense to start fresh on this (i.e., to NOT base it on SIPS).

- I believe it is very likely that at some point, this will make sips
obsolete or
  or at least quaint and primitive.  That's OK too.

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Oct 2006 14:56:10 -0600

On Oct 31, 2006, at 11:48 AM, Francois Audet wrote:

> . . .

But for sips: to live up to the promise you just made, it needs more  
restrictions specifically relating to gateway and B2BUA operations.

This puts us in a weird place. Some of us don't want sips: to mean  
what it says. Others of us don't want it to say what it means.

Either it means "MUST use some specific level of protection (easily  
said as TLS)", or it just means "Protection would be nice if you can  
do it", which we already get from the sip: URI scheme.

--
Dean

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 Oct 2006 17:04:02 -0500

Just to be clear, for the work item which says "document 3261 SIPS as defined,
I believe Francois is correct, and I believe (if I have understood 
everything I have read properly) that his description is 
accurate.  The fact that many people don't like it is irrelevant to 
that question.  It is what it is.

My concern is that the chartered work also includes making 
recommendations for where we should go.
That is what I have been arguing on.

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 31 Oct 2006 16:29:35 -0600

I don't want to keep interworking with the broken stuff with the new
Elegant or workable solution. Are we keep forgetting the nuisance of
NAT interworking etc ? That will make the things more complex. 

SIP itself is too complex. IMHO, the more complexities you add to the
protocol, the less users you will get. See what major search engine
chose ?
People already started talking about mistakes of the SIP and paving the
way for new protocol.

Sometimes early adapters get the lead, and sometimes they are at the
risk of implementing broken stuff. So it's that way only.

Why IP surviving so long and being utilized for other purposes too?
Because the founders had the UNWAVERING commitment to RUNNING CODE and
they used to look for SIMPLICITY etc.. I don't want to go more details
here.

Talk to some of the providers and IT enterprise departments do they want
to deploy SIPS in its current with patched form ?

BTW what is the vote count? 

Thx
Samir

> Sent: Tuesday, October 31, 2006 2:04 PM
> To: IETF SIP List
> Subject: RE: [Sip] Re: What consensus?
>