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

From: Dean Willis <[email-masked]>
Date: Wed, 25 Oct 2006 00:01:27 -0500

On Oct 24, 2006, at 3:59 PM, Francois Audet wrote:
> I really tought that we had already decided in Montreal that it was
> Alternative 1.
>

That is the plan of record. Of course, the more I think about it, the  
more convinced I am that the plan is wrong, at least IF we are going  
to continue to use UDP.

> Alternative 2 doens't make sense. If I use https: it means TLS: it
> doesn't
> mean http over IPsec. It also doesn't mean that you can't use http  
> over
> IPsec. Furthermore, I don't think it would even be possible to  
> retrofit
> this rule into RFC 3261.
>

Actually, HTTPS means you have TLS all the way to the far end, with  
no "proxy MITM" weakness. SIPS doesn't mean that.

And IMAPS and POPS both mean SSL, not TLS, in common practice.

But SMTP, which uses a hop-by-hop relayance model much more similar  
to SIP than HTTP is, doesn't have an SMPTS to insist on hop-by-hop  
security, because that would just be silly for email (as it is silly  
for SIP, from a security perspective).

But if you ask somebody (outside this small group) what the trailing  
"S" on all those protocols means, they'll probably say it means  
"secure".

So I'd have to say that your argument here, while well-intentioned,  
is fallacious. As for retrofiting a new rule into RFC 3261 being  
impossible, I'd argue that it is no more impossible than making sense  
of the current morass. They're both hard, but not impossible.

> In fact, my recollection is that we agreed on Alternative 1 for
> starters,
> and that we are leaving the issue of the 'last hop exception' to be
> decided
> later.

My worry is that any reasonable resolution of the the last hop  
exception (which might also need to be a first hop exception, for UDP- 
only nodes) ends us up right back in the quandary we're currently in  
-- with no deployable security model short of ignoring half the  
specification.

I'll agree that path #1 is clearly the right way for "explaining what  
RFC 3261 says". It is not, however, the right way to get to "what RFC  
3261 should have said".

I can see arguments for saying that an end-to-end TLS, aka SIPSEC:,  
is what "3261 should have said", and I can see arguments for saying  
that "reasonably secured on each hop" is what "3261 should have  
said". I don't find the argument that 3261 should have just said  
"Just use TLS and ignore the weaknesses" compelling.

What we agreed in Montreal was (in the draft you're working on) to  
complete the task of "explaining what RFC 321 says". But I find the  
problem of "what it SHOULD have said" far more interesting, because I  
believe what it currently says is (even if correctly explained) to be  
badly designed and of limited utility in implementation.

--
dean, wearing his paranoid I-told-you-so-and-I'm-not-acing-like-a- 
chair hat.

_______________________________________________
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: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Oct 2006 07:03:18 -0400

I have tried to say this before.
SIPS is frequently (I was going to say normally, but I don't think 
anything in this situation is normal) understood to mean "SIP with 
Security".  And because SIP is much like Email, I tend to think of it 
as very parallel to the use of iMAPS / POPS on the first leg, and 
then whatever happens to get used thereafter.
I like the fact that as distinct from email SIPS does actually 
request that later hops provide security.

Yours,
Joel M. Halpern

PS: Sorry, I don't know why there is such a duplicated list of 
people, so I am not trimming the dups.

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 25 Oct 2006 14:08:49 -0500

So, to summarize, you are NOT happy with the current consensus, and you 
are proposing something completely different, i.e., that instead of just
the current cludgy "last-hop exception rule", we also add a new
"first-hop 
exception" (and I would imagine a new "any hop exception" rule)?

Unlike the current "last hop exception rule" which imposes absolutely
no security requirements, your "any hop exception rule" would change
this
it to a "decent security equivalent to TLS" rule.

This would entail finding all the instances of "TLS" in RFC 3261 and
make the
according changes.

This is a gigantic change from RFC 2961. I don't think it is reasonable.

It is orders of magnitude bigger than what is discussed in 
draft-audet-sip-sips-guidelines which does NOT attempt to redefine
the meaning of sips, and does NOT invalidate RFC 3261.

My take is that using other protocols than TLS is perfectly fine.
However,
it does not mean that we should be using sips in that case. I'd argue
that
using sip is perfectly fine in those cases.

If a network for example relies on IPsec, maybe there is no need to use
sips at all.

I think we need to be pragmatic here. We can not invalidate huge chunks
of 
RFC 3261 in the way you are proposing.

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Tuesday, October 24, 2006 10:01 PM
> To: Audet, Francois (SC100:3055)
> Cc: Adam Roach; Paul Kyzivat; Robert Sparks; Barnes, Mary 
> (RICH2:AR00); Gonzalo Camarillo; IETF SIP List
> Subject: Re: TLS meaning (was Re: [Sipping] WGLC: 
> draft-ietf-sipping-dialogusage-03.txt)
> 
> 
> That is the plan of record. Of course, the more I think about 
> it, the more convinced I am that the plan is wrong, at least 
> IF we are going to continue to use UDP.
> 
> > doesn't mean http over IPsec. It also doesn't mean that you 
> can't use 
> > http over IPsec. Furthermore, I don't think it would even 
> be possible 
> > to retrofit this rule into RFC 3261.
> >
> 
> 
> Actually, HTTPS means you have TLS all the way to the far 
> end, with no "proxy MITM" weakness. SIPS doesn't mean that.
> 
> But SMTP, which uses a hop-by-hop relayance model much more 
> similar to SIP than HTTP is, doesn't have an SMPTS to insist 
> on hop-by-hop security, because that would just be silly for 
> email (as it is silly for SIP, from a security perspective).
> 
> But if you ask somebody (outside this small group) what the 
> trailing "S" on all those protocols means, they'll probably 
> say it means "secure".
> 
> So I'd have to say that your argument here, while 
> well-intentioned, is fallacious. As for retrofiting a new 
> rule into RFC 3261 being impossible, I'd argue that it is no 
> more impossible than making sense of the current morass. 
> They're both hard, but not impossible.
> 
> 
> > starters, and that we are leaving the issue of the 'last hop 
> > exception' to be decided later.
> 
> My worry is that any reasonable resolution of the the last 
> hop exception (which might also need to be a first hop 
> exception, for UDP- only nodes) ends us up right back in the 
> quandary we're currently in
> -- with no deployable security model short of ignoring half 
> the specification.
> 
> I'll agree that path #1 is clearly the right way for 
> "explaining what RFC 3261 says". It is not, however, the 
> right way to get to "what RFC
> 3261 should have said".
> 
> I can see arguments for saying that an end-to-end TLS, aka 
> SIPSEC:, is what "3261 should have said", and I can see 
> arguments for saying that "reasonably secured on each hop" is 
> what "3261 should have said". I don't find the argument that 
> 3261 should have just said "Just use TLS and ignore the 
> weaknesses" compelling.
> 
> What we agreed in Montreal was (in the draft you're working 
> on) to complete the task of "explaining what RFC 321 says". 
> But I find the problem of "what it SHOULD have said" far more 
> interesting, because I believe what it currently says is 
> (even if correctly explained) to be badly designed and of 
> limited utility in implementation.
> 
> --

---

From: Aki Niemi <[email-masked]>
Date: Wed, 25 Oct 2006 22:46:12 +0300

> exception" (and I would imagine a new "any hop exception" rule)?

My recollection of at least the bar bof in Montreal was that we forget
Contact altogether. That's what most registrars already do, because of
all the crap (stunned addresses, private IPs, public IPs with
restrictive FWs and so on) that UAs put there making it simply not
reliable enough to be useful for anything.

Therefore, I'd say if you want to receive requests securely, register
via TLS and use sip-outbound.

Now I don't know what that means in terms of the "last-hop exception",
but IMHO, sips to me is usable only in terms of pointing me to a host
and port where I can start a TLS session. If we had STARTTLS in SIP, I
would not need sips.

So I guess I agree with what Dean is saying.

Cheers,
Aki

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 25 Oct 2006 15:38:43 -0500

That is certainly not what RFC 3261 says.

What you are describing is more analogous to using TLS on a first hop 
with sip (instead of sips). 

> From: Joel M. Halpern [mailto:[email-masked]] 
> Sent: Wednesday, October 25, 2006 4:03 AM
> To: Dean Willis; Audet, Francois (SC100:3055)
> Cc: Adam Roach; Robert Sparks; Paul Kyzivat; Gonzalo 
> Camarillo; IETF SIP List; Barnes, Mary (RICH2:AR00)
> Subject: Re: [Sip] Re: TLS meaning (was Re: [Sipping] WGLC: 
> SIPS is frequently (I was going to say normally, but I don't 
> think anything in this situation is normal) understood to 
> mean "SIP with Security".  And because SIP is much like 
> Email, I tend to think of it as very parallel to the use of 
> iMAPS / POPS on the first leg, and then whatever happens to 
> get used thereafter.
> I like the fact that as distinct from email SIPS does 
> actually request that later hops provide security.
> 
> Yours,
> Joel M. Halpern
> 
> PS: Sorry, I don't know why there is such a duplicated list 
> of people, so I am not trimming the dups.
> 
> similar to 
> >SIP than HTTP is, doesn't have an SMPTS to insist on hop-by-hop

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 25 Oct 2006 15:53:18 -0500

> From: Aki Niemi [mailto:[email-masked]] 
> Sent: Wednesday, October 25, 2006 12:46 PM
> Cc: Dean Willis; Adam Roach; Robert Sparks; Paul Kyzivat; 
> Gonzalo Camarillo; IETF SIP List; Barnes, Mary (RICH2:AR00)
> Subject: Re: [Sip] RE: TLS meaning
> My recollection of at least the bar bof in Montreal was that 
> we forget Contact altogether. That's what most registrars 
> already do, because of all the crap (stunned addresses, 
> private IPs, public IPs with restrictive FWs and so on) that 
> UAs put there making it simply not reliable enough to be 
> useful for anything.

Agreed.

> Therefore, I'd say if you want to receive requests securely, 
> register via TLS and use sip-outbound.

Agreed again.

> Now I don't know what that means in terms of the "last-hop 
> exception", but IMHO, sips to me is usable only in terms of 
> pointing me to a host and port where I can start a TLS 
> session. If we had STARTTLS in SIP, I would not need sips.

Sure.

> So I guess I agree with what Dean is saying.

You completely lost me here.

Dean is basically saying that sips should be able to mean other
protocols than TLS (e.g., IPsec). So pretty much the opposite of
your points in this email.

---

From: Dean Willis <[email-masked]>
Date: Thu, 26 Oct 2006 13:47:33 -0500

> exception" (and I would imagine a new "any hop exception" rule)?

Good summary.

> it to a "decent security equivalent to TLS" rule.

Yep.

> This would entail finding all the instances of "TLS" in RFC 3261 and

That's one way to approach it. Another way to do it would be another  
RFC that extends 3261 and says basically "Wherever RFC 321 says TLS,  
please substitute . . . "

> This is a gigantic change from RFC 2961. I don't think it is  

Doesn't have to be reasonable if it's necessary.

> the meaning of sips, and does NOT invalidate RFC 3261.

Not saying your draft isn't needed. Just saying it isn't enough to  
really fix the problem.

> If a network for example relies on IPsec, maybe there is no need to  

So how would you propose that a user say "I expect you to ship this  
request and an responses to it over secured links, and if you can't,  
I want you to reject it" without using sips:?

> RFC 3261 in the way you are proposing.

I believe otherwise.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 26 Oct 2006 13:52:53 -0500

> your points in this email.

I'm saying that as long as we have transports other than TCP, and  
with TLS implementations being in the minority, that SIPS should be  
able to use other security encapsulations that provide equivalent  
security, including DTLS and IPSEC.

Of course, I'd also be happy to deprecate UDP and go with TLS only.

--
Dean

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 26 Oct 2006 15:07:25 -0500

What about DCCP in Page mode IM that has the congestion control. You can
run DTLS over that too.

Thx
Samir

> Sent: Thursday, October 26, 2006 11:53 AM
> Cc: IETF SIP List; Aki Niemi

---

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

Hi Dean,

I'm OK with using other protocols (including DTLS and IPsec) to secure
signalling, but I don't see why you'd need to use SIPS for that.

I'd argue that using SIP for that instead of sips is better. Easier to 
implement. No arcane rules as for SIPS. 

If this was to be redone, I wouldn't use SIPS at all. I believe it was a
mistake
in the first place.

But at the last meeting, we decided it was too late to "deprecate it",
and I believe
we also decided that it would mean what was said in RFC 3261. We would
just
clarify the confusion around it.

That doesn't mean that we should INCREASE the role of sips to other
protocols
like DTLS and IPsec (and whatever).

My take is that if you don't use TLS, you wouldn't use SIPS. I'd rather
we
use a Require header for that (for example).

And then eventually, we'd outgrow sips entirely.

To me, a two step approach like this is (a) backward compatible and
doesn't
require an overhaul of RFC 3261, and (b) allows to fix the immediate
problem
of TLS-only SIPS, while giving us more time for a more general solution.

> Sent: Thursday, October 26, 2006 11:48 AM
> Subject: Re: TLS meaning
> > So, to summarize, you are NOT happy with the current consensus, and 
> > you are proposing something completely different, i.e., 
> that instead 
> > of just the current cludgy "last-hop exception rule", we also add a 
> > new "first-hop exception" (and I would imagine a new "any hop 
> > exception" rule)?
> >
> 
> Good summary.
> 
> 
> 
> > this it to a "decent security equivalent to TLS" rule.
> >
> 
> Yep.
> 
> > make the according changes.
> >
> 
> > If a network for example relies on IPsec, maybe there is no 
> need to  
> > use
> > sips at all.
> >
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 26 Oct 2006 16:51:36 -0500

Surgery / Change Criterias 

1. Changing the internet at the core is practically impossible.

2. Changing the internet at the edge is lethargically slow.

3. Interface between the network and the internetwork can be changed.

The above view was shared with Bruce Young (My earlier VP at Level 3)
for working on the congestion (Event based heart beat, IP level
congestion etc I will be reopening), and recently the Phillip Baker also
shared the same views for changing the S/MIME

So now view it within the presepective of the SIP. SIP is nowhere
ubiquitous as compared to IP. 

We have very nice tool available to us Proxy-Require (tcp) to move
gradually to reliable (DCCP open question) transports..... Need of the
hour is to deprecate UDP all-together. Write one RFC which states the
issues with UDP and recommends it is bad for your network health and use
at your own risk. 

SIPS:

Internet is always evoloving. And it should be noted that standards are
called only "REQUEST FOR COMMENTS". Consensus achieved in *A* meeting is
not a complete binding. For the attorney's kind of arguments Refer
following from section 5.2 http://www.ietf.org/tao.html  

"One fact that confuses many novices is that the face-to-face WG
meetings are much less important in the IETF than they are in most other
organizations. Any decision made at a face-to-face meeting must also
gain consensus on the WG mailing list. There are numerous examples of
important decisions made in WG meetings that are later overturned on the
mailing list, often because someone who couldn't attend the meeting
pointed out a serious flaw in the logic used to come to the decision.
FinallyFrom [email-masked] Thu Oct 26 18:07:15 2006
Content-class: urn:content-classes:message
Subject: RE: [Sip] RE: TLS meaning
Date: Thu, 26 Oct 2006 16:51:36 -0500
From: "Samir Srivastava" <[email-masked]>
To: "Dean Willis" <[email-masked]>,
	"Francois Audet" <[email-masked]>
Cc: IETF SIP List <[email-masked]>, Aki Niemi <[email-masked]>

This is a multi-part message in MIME format.
Surgery / Change Criterias 

1. Changing the internet at the core is practically impossible.

2. Changing the internet at the edge is lethargically slow.

3. Interface between the network and the internetwork can be changed.

The above view was shared with Bruce Young (My earlier VP at Level 3)
for working on the congestion (Event based heart beat, IP level
congestion etc I will be reopening), and recently the Phillip Baker also
shared the same views for changing the S/MIME

So now view it within the presepective of the SIP. SIP is nowhere
ubiquitous as compared to IP. 

We have very nice tool available to us Proxy-Require (tcp) to move
gradually to reliable (DCCP open question) transports..... Need of the
hour is to deprecate UDP all-together. Write one RFC which states the
issues with UDP and recommends it is bad for your network health and use
at your own risk. 

SIPS:

Internet is always evoloving. And it should be noted that standards are
called only "REQUEST FOR COMMENTS". Consensus achieved in *A* meeting is
not a complete binding. For the attorney's kind of arguments Refer
following from section 5.2 http://www.ietf.org/tao.html  

"One fact that confuses many novices is that the face-to-face WG
meetings are much less important in the IETF than they are in most other
organizations. Any decision made at a face-to-face meeting must also
gain consensus on the WG mailing list. There are numerous examples of
important decisions made in WG meetings that are later overturned on the
mailing list, often because someone who couldn't attend the meeting
pointed out a serious flaw in the logic used to come to the decision.
Finally, WG meetings aren't "drafting sessions", as they are in some
other standards bodies: in the IETF, drafting is done elsewhere"

SIPS is not *DEPLOYED*. (Pl correct me, if I am wrong). If things are
not deployed then we have a free ride to deprecate it. I will be sending
the occurences of SIPS in the existing RFC in a separate email. Write
one RFC which updates all these existing RFC stating that "It updates
<list of RFC ...> with a generic statements in the contents. And then
have a clean solution.

We need to have a puristic view. We have a mud with us. Whatever
(Diamond etc) you put in the mud, it will be muddy only... We need to
clean up the mud... We have made already so many mistakes on SIPS..(Not
even putting one fact at one place in documenting itself...).

BTW, If you agree on cipher-suites, then Proxy-Require to enforce
cipher-suites makes the SIPS redundant all-together. If anybody has any
ENGINEERING arguments to keep it, I am most willing to hear it. 

Thx

Samir

-----Original Message-----

Sent: Thursday, October 26, 2006 11:53 A

 

On Oct 25, 2006, at 3:53 PM, Francois Audet wrote:

> protocols than TLS (e.g., IPsec). So pretty much the opposite of your 

> points in this email.

I'm saying that as long as we have transports other than TCP, and with
TLS implementations being in the minority, that SIPS should be able to
use other security encapsulations that provide equivalent security,
including DTLS and IPSEC.

--

Dean

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

---

Date: Thu, 26 Oct 2006 14:51:20 -0700

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>I'm saying that as long as we have transports other than TCP, =
and with
TLS implementations being in the minority, that SIPS should be able to =
use
other security encapsulations that provide equivalent security, =
including DTLS
and IPSEC.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Of course, I'd also be happy to deprecate UDP and go with TLS =
only.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>--<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Dean<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>_______________________________________________<o:p></o:p></span>=
</font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Sip mailing list&nbsp; =
https://www1.ietf.org/mailman/listinfo/sip<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>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<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C6F948.E90369B5--

--===============1481303979==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============1481303979==--

---

From: Michael Thomas <[email-masked]>
Date: Thu, 26 Oct 2006 14:51:20 -0700

>clarify the confusion around it.
It's never too late to deprecate something, especially when nobody agrees as
to what it means. In fact, given the confusion and the general lack of 
consensus,
the mosty prudent thing would be *to* excise its use to hopefully force the
cancer into remission.

I mean, what's the real problem here:

  "A sender MUST NOT send a SIPS URI, and a receiver MUST NOT treat a
   SIPS URI any different from a SIP URI"

Doesn't that just about do what you can to cut it out?

       Mike

>>Good s: Michael Thomas <[email-masked]>
To: Francois Audet <[email-masked]>
Subject: Re: [Sip] RE: TLS meaning
Cc: IETF SIP List <[email-masked]>, Dean Willis <[email-masked]>

>clarify the confusion around it.
It's never too late to deprecate something, especially when nobody agrees as
to what it means. In fact, given the confusion and the general lack of 
consensus,
the mosty prudent thing would be *to* excise its use to hopefully force the
cancer into remission.

I mean, what's the real problem here:

  "A sender MUST NOT send a SIPS URI, and a receiver MUST NOT treat a
   SIPS URI any different from a SIP URI"

Doesn't that just about do what you can to cut it out?

       Mike

>>>Unlike the current "last hop exception rule" which imposes 
>>>      
>>>
>>absolutely 
>>    
>>
>>>no security requirements, your "any hop exception rule" 
>>>      
>>>
>>would change 
>>    
>>
>>>This would entail finding all the instances of "TLS" in RFC 
>>>      
>>>
>>3261 and 
>>    
>>
>>>it does not mean that we should be using sips in that case. 
>>>      
>>>
>>I'd argue
>>    
>>
>>>that

ummary.
>>
>>
>>
>>    
>>
>>>Unlike the current "last hop exception rule" which imposes 
>>>      
>>>
>>absolutely 
>>    
>>
>>>no security requirements, your "any hop exception rule" 
>>>      
>>>
>>would change 
>>    
>>
>>>This would entail finding all the instances of "TLS" in RFC 
>>>      
>>>
>>3261 and 
>>    
>>
>>>it does not mean that we should be using sips in that case. 
>>>      
>>>
>>I'd argue
>>    
>>
>>>that

---

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

Mike, that's what we agreed NOT to do at the last meeting.
I'm not inventing this: people did not want to deprecate sips. 

> From: Michael Thomas [mailto:[email-masked]] 
> Sent: Thursday, October 26, 2006 2:51 PM
> Cc: Dean Willis; IETF SIP List
> >If this was to be redone, I wouldn't use SIPS at all. I 
> believe it was 
> >a mistake in the first place.
> >
> >and I believe we also decided that it would mean what was 
> said in RFC 
> >3261. We would just clarify the confusion around it.
> >  
> >
> It's never too late to deprecate something, especially when 
> nobody agrees as to what it means. In fact, given the 
> confusion and the general lack of consensus, the mosty 
> prudent thing would be *to* excise its use to hopefully force 
> the cancer into remission.
> 
> >protocols like DTLS and IPsec (and whatever).
> >
> >we use a Require header for that (for example).
> >
> >doesn't require an overhaul of RFC 3261, and (b) allows to fix the 
> >immediate problem of TLS-only SIPS, while giving us more time for a 
> >more general solution.
> >
> >
> >
> >  
> >
> >>request and an responses to it over secured links, and if 
> you can't, I 
> >>want you to reject it" without using sips:?
> >>
> >>
> >>    
> >>
> >>>I think we need to be pragmatic here. We can not invalidate huge 
> >>>chunks of RFC 3261 in the way you are proposing.
> >>>      
> >>>
> >>I believe otherwise.
> >>
> >>--
> >>Dean
> >>
> >>    
> >>
> >

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 26 Oct 2006 17:29:42 -0500

Fine. I was shot down in the last meeting by Cullen that it is not on
the agenda. So I am not in the agreement. 

Guys voice up, who wants to keep up with the ENGINEERING arguments. BTW
it is I ENGINEERING TF.

Thx
Samir

> From: Audet, Francois (SC100:3055)
> Sent: Thursday, October 26, 2006 3:09 PM
> To: Michael Thomas
> Cc: IETF SIP List; Dean Willis

---

From: Michael Thomas <[email-masked]>
Date: Thu, 26 Oct 2006 16:53:50 -0700

>I'm not inventing this: people did not want to deprecate sips. 

That's nice. Meetings are not definitive, the list is. Until the chairs 
tell us that
this is closed, the consensus at the meeting is not binding.

       Mike

>>>I'm OK with using other protocols (including DTLS and IPsec) 
>>>      
>>>
>>to secure 
>>    
>>
>>>I'd argue that using SIP for that instead of sips is better. 
>>>      
>>>
>>Easier to 
>>    
>>
>>>But at the last meeting, we decided it was too late to 
>>>      
>>>
>>"deprecate it", 
>>    
>>
>>>My take is that if you don't use TLS, you wouldn't use SIPS. 
>>>      
>>>
>>I'd rather 
>>    
>>
>>>>>So, to summarize, you are NOT happy with the current 
>>>>>          
>>>>>
>>consensus, and 
>>    
>>
>>>>>of just the current cludgy "last-hop exception rule", we 
>>>>>          
>>>>>
>>also add a 
>>    
>>
>>>>That's one way to approach it. Another way to do it would 
>>>>        
>>>>
>>be another 
>>    
>>
>>>>RFC that extends 3261 and says basically "Wherever RFC 321 
>>>>        
>>>>
>>says TLS, 
>>    
>>

---

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

Well, go ahead: propose to deprecate SIPS then. (I think it was me
who brought it up in Montreal by the way).

The official meeting minutes said (in bold):

	We have consensus that we will not deprecate SIPS.

I'd like to get some advice from the ADs (again).

I don't find it particularly productive to have random
proposals from the list derail the concensus that we have
painfully established.

> Sent: Thursday, October 26, 2006 4:54 PM
> That's nice. Meetings are not definitive, the list is. Until 
> the chairs tell us that this is closed, the consensus at the 
> meeting is not binding.

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 26 Oct 2006 19:18:31 -0500

Agreed. I too believe in democracy with *WELL INFORMED* voting/hum.

Also I request the guys voting/huming to keep SIPS to let me know the
reasons, if they want to.

Thx
Samir

---

From: Michael Thomas <[email-masked]>
Date: Thu, 26 Oct 2006 17:27:19 -0700

>who brought it up in Montreal by the way).

Sure. Deprecate SIPS. It's always been a bad idea. The fact that
5 or so years out nobody still agrees what if anything it means is
a very strong argument that it's a dead letter.

>proposals from the list derail the concensus that we have

Well, I don't think I've been in any way "random" here since I've been 
saying
that this was a bad idea for going on 5 years now. Nor do I find Dean's
reservations particularly random either. But what I will say is that
the list is where the consensus is gauged, not the meeting. Were I at the
meeting, it would have seemed a lot less consensusful.

       Mike

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 27 Oct 2006 09:14:09 +0300

Michael Thomas writes:

 > >mistake in the first place.

yes, SIPS was a big mistake in the first place.  SIPS was rushed into
RFC3261 drafts at the very last moment without any kind of
implementation nor even emailing list experience.  now it is high time
to admit that it was a big mistake.  my understanding is that rfc3261 is
just a PROPOSED standard, which very well can and should be changed to
correct the SIPS mistake.

 > to what it means. 

yes, as i have proposed earlier, lets deprecate SIPS and introduce
something else later when we know what it should be and have positive
implementation experience.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 27 Oct 2006 09:17:55 +0300

X-Scan-SigFrom [email-masked] Fri Oct 27 02:26:28 2006
Date: Fri, 27 Oct 2006 09:14:09 +0300
To: Michael Thomas <[email-masked]>
Subject: Re: [Sip] RE: TLS meaning
From: [email-masked] (Juha Heinanen)
Cc: IETF SIP List <[email-masked]>, Francois Audet <[email-masked]>,
	Dean Willis <[email-masked]>

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 27 Oct 2006 09:17:55 +0300

> I'm not inventing this: people did not want to deprecate sips. 

in the early days ietf did its decisions on the mailing lists.  not
everybody can afford to attend the meetings.  my customers pay for
working code, not me sitting in meetings.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 27 Oct 2006 09:22:20 +0300

> proposals from the list derail the concensus that we have

your term "random proposal" is quite insulting.  is it so that only
proposals from nortel, cisco, etc big companies are not "random".

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 27 Oct 2006 09:14:09 +0300

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 27 Oct 2006 09:17:55 +0300

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 27 Oct 2006 09:22:20 +0300

-- juha

nature: 7bac9cb154eb5790ae3b2913587a40de
Cc: IETF SIP List <[email-masked]>, Michael Thomas <[email-masked]>,
	Dean Willis <[email-masked]>
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 27 Oct 2006 09:22:20 +0300

-- juha

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Oct 2006 08:36:51 -0400

Okay, I'll take the bait.

I think the problem with sips was the exception for last hop.  Get rid of
that and sips means the UA requests end to end TLS and as far as we know, he
got it.  It's hop by hop, which means a transitive trust model, and
therefore subject to an untrustworthy proxy screwing up.  Even with such
limitations, I think that is valuable.  Needs some clarifications as has
been discussed.

There may be other valuable security mechanisms to be proposed, but TLS end
to end is useful.

I am NOT in favor of deprecating sips.

Brian

> Sent: Thursday, October 26, 2006 8:27 PM
> To: Francois Audet
> Cc: ext Cullen Jennings; IETF SIP List; Peterson, Jon; Dean Willis

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 06:52:03 -0700

> I am NOT in favor of deprecating sips.

I basically agree with Brian here.

In the previous contexts where SSL has been deployed, one of two
things is usually done:

- The reference which the client dereferences explicitly asserts
  that TLS is to be used (e.g., HTTPS)
- The client and server mutually discover that they are to use
  TLS (e.g., STARTTLS for SMTP).

SIPS attempts to import the first model into SIP, but because
SIP, unlike HTTP, doesn't have a direct connection from the client
to the server, it needs to have the proxies transitively enforce
the same security conditions (use TLS) that the client enforces.
As Brian says, this is transitive trust, but it's what we've
got.

At the time it was accepted, the last-hop exception seemed sensible
(by analogy to the last-hop HTTPS accelerators used in many
data centers), but as we've seen that produces problems and
the need for it can be removed with outbound. I haven't
seen any arguments I find convincing that that's not the way
to go.

-Ekr

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 27 Oct 2006 18:22:29 +0300

> seen any arguments I find convincing that that's not the way

there was lots of opposition when someone (i think jonathan) proposed
that SIPS means tls on every hop, i.e., if the route through proxies
cannot implement it, then the request must fail.  i personally would
have been happy with this interpretation.

-- juha

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 27 Oct 2006 11:37:37 -0400

So let me ask a question.  Maybe a stupid question.
You are sending a SIP invite to someone.  You want it secured.  Let's 
suppose you want it secured end to end.  Let's even suppose that if 
it is not secured end to end you want it ti fail.  So you specify 
SIPS in accordance with your definition.

Do you really want that call to fail because two of the proxies in 
the path are using IPSec instead of TLS?

Yours,
Joel M. Halpern

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Oct 2006 08:39:28 -0700

Brian Rosen wrote:

>got it.  
s/as far as we know/mistakenly believe/g

The problem all along is that SIPS oversells itself by a huge and 
misleading amount.
It is *not* like https which is what the uninformed luser is extremely 
likely to believe.
While potentially great for rogue regimes bent on suspending 4th 
amendments, habeus
corpuses and the like, it sucks for just about everybody else.  If we 
have to keep it, at the
very least let's call it something closer to the truth. Like, oh say, 
TURDBLOSSOM:
or SHRUBS:

>It's hop by hop, which means a transitive trust model, and
My sense is there will be between 0 and 1 widely deployed e2e crypto 
mechanmism
for SIP. Choose wisely.

       Mike

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 08:47:30 -0700

"Joel M. Halpern" <[email-masked]> writes:

> suppose you want it secured end to end.  Let's even suppose that if it
> is not secured end to end you want it ti fail.  So you specify SIPS in
> accordance with your definition.
>
> Do you really want that call to fail because two of the proxies in the
> path are using IPSec instead of TLS?

Well, I do. The security (authentication) properties of IPsec are rather
different then those of TLS. And why just say IPsec is OK. What about
WEP? What Once you relax the meaning to "secure" then it's more or 
ess meaningless. 

-Ekr

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Oct 2006 11:05:39 -0500

Exactly.

And what about if the proxy is using my-homegrown-security-mechanism,
which
I unilateraly declare to be secure? 

> From: Eric Rescorla [mailto:[email-masked]] 
> Sent: Friday, October 27, 2006 8:48 AM
> To: Joel M. Halpern
> Cc: 'IETF SIP List'
> Well, I do. The security (authentication) properties of IPsec 
> are rather different then those of TLS. And why just say 
> IPsec is OK. What about WEP? What Once you relax the meaning 
> to "secure" then it's more or ess meaningless. 
> 
> -Ekr
> 
> [email-masked] for questions on current sip

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 09:07:35 -0700

Michael Thomas <[email-masked]> writes:
> Eric Rescorla wrote:
> One could say that when you explictly allow for unexpected MITM attacks, the
> meaning is pretty much useless. Which is SIPS in a nutshell.

One could say it, but of course it would be wrong.

-Ekr

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Oct 2006 11:05:39 -0500

Exactly.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 09:07:35 -0700

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Oct 2006 09:09:16 -0700

Eric Rescorla wrote:

>Well, I have no idea how SIPS sells itself
>
Gosh, maybe the same as, oh say, HTTPS?

>, and I'm certainly
>in favor of of end-to-end security mechanisms. However,
>I don't think that that means that SIP over TLS has minimal
>value
>

This is a strawman. Nobody is objecting to using TLS as a hopwise mechanism.

>, and since it's something that we already know how to do,
>I consider it worth doing while we figure out how to deploy
>the better stuff. 
>  
>
Well, we manifestly do *not* know how to even do SIPS, hence our still 
talking
about it 5 years out. Instead of trying yet again to polish this turd, 
why don't we...
you know... look for some better stuff?

       Mike

---

From: Dean Willis <[email-masked]>
Date: Fri, 27 Oct 2006 11:09:58 -0500

> What about DCCP in Page mode IM that has the congestion control.  

Fair enough. I'd also say that sips: should work with DTLS/DCCP as  
well as DTLS/UDP, if we're going to allow UDP and DCCP transports for  
SIP..

The basic argument is that there are a number (perhaps relatively  
large, perhaps quite limited but possibly extensible) of transport  
alternatives that provide cryptographic functionality and protections  
equivalent to TLS, but may be more or less suitable for different  
deployment scenarios.

The "real world end user" just wants to know "it is secured". But  
real-world environments often mix base deployment scenarios -- for  
example, a user on a mobile phone may be calling one on a wired  
Internet connection. By keeping sips: restricted to basic TLS, we  
essentially preclude users in the mixed scenarios from being able to  
request secure handling.

This is self-defeating, and likely to prevent the widespread  
deployment and usage of sips:, which I think would be a horrible thing.

--
Dean

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 09:03:32 -0700

> very least let's call it something closer to the truth. Like, oh say,

Well, I have no idea how SIPS sells itself, and I'm certainly
in favor of of end-to-end security mechanisms. However,
I don't think that that means that SIP over TLS has minimal
value, and since it's something that we already know how to do,
I consider it worth doing while we figure out how to deploy
the better stuff. 

-Ekr

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Oct 2006 11:12:14 -0500

In case people having noticed, it is looking like we are having a
mailing list 
hum on the following 2 questions:

1 - Do you favour deprecating the sips scheme altogether (yes/no)

2 - Do you favour getting rid of the last-hop-exception rule (yes/no)

Note: Voting Yes on 2 does not necessarily imply you are voting No on 1,
but it will
only make sense if sips is not deprecated.

I'm keeping track of the vote.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 09:13:48 -0700

> Gosh, maybe the same as, oh say, HTTPS?

Gosh, I don't know. I don't go around saying that, and if you
find me someone saying that I'd be happy to correct them.

> This is a strawman. Nobody is objecting to using TLS as a hopwise mechanism.

Which is what SIPS is: a hopwise mechanism with a requirement
that each hop do the same thing.

> about it 5 years out.

No, I don't agree with that. I think we got it wrong the first
time but have a fairly good understanding of how to do it now.

> Instead of trying yet again to polish this turd,
> why don't we...

Go ahead and suggest something. All I see you doing now is complaining.

-Ekr

---

From: Dean Willis <[email-masked]>
Date: Fri, 27 Oct 2006 11:14:21 -0500

> signalling, but I don't see why you'd need to use SIPS for that.

That's a fair question.

I'd argue that the answer is "We would use sips: because that is the  
current mechanism by which and end user requests secure handling of  
signaling, indicating that if the other nodes cannot provide secure  
handling that the call is to fail rather than be handled insecurely"  
and "because it is important that users be able to demand this  
distinct handling model".

I suppose we could replace this with an option-tag in Require and  
Proxy-Require, and that if we did, we could just deprecate sips:  
completely. Now that I think of it this way, this might be a much  
better general mechanism anyhow, much closer to our usual negotiation  
model.

--
Dean

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 09:16:48 -0700

> equivalent to TLS, but may be more or less suitable for different

I think there's a pretty bright line between DTLS, which is primarily
TLS over a different transport and IPsec, SSH, etc. which are
different security protocols with some similarities to TLS and some
not. To consider only one issue, how you identify the peer is rather
different for all these protocols.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Oct 2006 09:05:09 -0700

Mike

---

From: Dan Petrie <[email-masked]>
Date: Fri, 27 Oct 2006 09:20:16 -0700 (PDT)

> 1 - Do you favour deprecating the sips scheme altogether (yes/no)
no

> 2 - Do you favour getting rid of the last-hop-exception rule (yes/no)
yes

SIPez LLC  
SIP VoIP, IM and Presence Consulting  
http:/www.sipez.com  
tel: +1 (617) 273-4000

---

From: "Frank W. Miller" <[email-masked]>
Date: Fri, 27 Oct 2006 10:22:49 -0600

Inline...

FM

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Friday, October 27, 2006 10:12 AM
To: IETF SIP List
Subject: RE: [Sip] RE: TLS meaning

Yes.  The SIPS scheme does not provided end-to-end security and worse, it
can be mistaken by the uneducated as doing that when it doesn't.  SIP needs
a true UA-to-UA security scheme.

N/A

---

From: Dean Willis <[email-masked]>
Date: Fri, 27 Oct 2006 11:35:01 -0500

> have been happy with this interpretation.

As the source of much of the vocalization of that opposition, let me  
see if I can recover the argument.

Requiring TLS end-to-end either means:

1) The UAS have an established TLS connection to a proxy, which is  
then re-used, or

2) The UAS be able to receive a new TLS connection, meaning for all  
practical purposes that it has to have a cert that can be recognized  
by the requestor, which could be either the UAC or an intermediate  
proxy.

And of course, requiring TLS means that all UAs must implement TCP.  
While this is in the spec, it isn't in the real-world, and many of  
the mobile people have advanced arguments (that might or might not be  
correct) about the undesirability of TCP in low-power mobile  
applications, especially when they already have an IPSEC SA  
established to their proxies.

Outbound gives us an answer to requirement #1.

As to #2, I suppose we could have a reasonably deployable variation  
of outbound where the outbound proxy or its infrastructure issues a  
cert to the UAS, such that the TLS connection could be opened proxy- 
to-UAS instead of UAS-to-proxy. This would have the advantage of  
allowing the TLS connection to be established on a per-call basis.  
Vijay, Francois and I have also proposed an alternative that uses  
HTTP-like transparent TLS proxy support instead of hop-by-hop, but  
this requires some form of mutual authentication UA-to-UA to be  
effective, and some people think that's really hard.

But so far we have no consensus on the "TCP unsuitable for mobiles"  
question.

I really don't want to see 2 billion mobile users unable to request  
or receive calls to or from traditional Internet users, where the  
traditional Internet user really needs the perceived security of sips:.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 27 Oct 2006 11:37:37 -0500

> WEP? What Once you relax the meaning to "secure" then it's more or

Would you want it to fail if DTLS/DCCP were used instead of TLS/TCP?

--
Dean

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 09:43:12 -0700

> And of course, requiring TLS means that all UAs must implement TCP.

Well, or standardizing SIP/DTLS. While I don't think it makes sense
to allow SIPS to mean "SIP over anything secure", I don't see
a similar problem with it meaning "SIP over TLS or SIP over DTLS"

> Outbound gives us an answer to requirement #1.

Yeah, I think this is the right answer.

> to-UAS instead of UAS-to-proxy.

Another way to do this would be to relax not the TLS requirement
for the last hop but the requirement to identify the UAC with
a certificate rather than Digest. The details are a bit complicated,
though.

> This would have the advantage of

That's far from the only problem--unless you think that proxies pretty
much don't do anything useful besides transparently route traffic.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 09:44:27 -0700

> Would you want it to fail if DTLS/DCCP were used instead of TLS/TCP?

No, I don't see a problem with that. It seems to me that (D)TLS over
any transport has basically the same security properties, which
is the relevant issue here.

-Ekr

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Oct 2006 13:13:41 -0400

Yeah, I can go along with that.

BTW Francois: 1) no 2) yes

Brian

> Sent: Friday, October 27, 2006 12:44 PM
> To: Dean Willis
> Cc: Joel M. Halpern; 'IETF SIP List'

---

From: Dean Willis <[email-masked]>
Date: Fri, 27 Oct 2006 12:27:34 -0500

> is the relevant issue here.

That's useful to know. It might be possible to persuade the UDP fans  
in mobile land to use DTLS. I'm hearing good things about DTLS from  
other folks who have played with it on small systems.

And I can clearly see that a blanket policy that would accept WEP as  
"Secured" would be bad.

But please help us understand what's different about IPSEC usage in  
the IMS sense.

IMS has a persistent IPSEC SA established between the edge proxy and  
the UA. Authentication is accomplished using the SIM as a token  
generator, and the crypto is one of the usual mechanisms (keep in  
mind TLS still allows plain small-key DES, which isn't all that  
strong). The applications are constructed so that the SIP function is  
aware of the SA and that it is connected to an authenticated party.

What is different about the security properties here from TLS in  
outbound in such a way that it makes a difference to the SIP user?

--
Dean

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Oct 2006 13:57:02 -0400

There are a lot of mechanisms that can create a secure connection between
two entities.  It is often hard to equate the security properties of those
mechanisms.  Even between IPSEC and TLS, with the same ciphersuite, you
don't have the same security properties.  

The problem I have is that then sips means "we think we have created
something approximating what you asked for, by assembling a set of
mechanisms across the hops, and we think you should be happy"

I don't see how you admit IPSEC under some circumstances (and it would have
to be fairly carefully locked down to a set of specific circumstances.  For
example, you can't allow the IPSEC tunnel to connect more than the two
parties across a hop) and then say some other mechanisms are not allowed.
For example suppose I had a military grade link encryptor and just a proxy
on each end of the link.  It's a slippery slope.

It may be possible to create some new mechanism that describes the security
properties required, and allows any mechanism that meets those properties at
any hop.  I don't think that is sips.

Brian

> Sent: Friday, October 27, 2006 1:28 PM
> To: EKR

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Oct 2006 14:03:55 -0400

>>> path are using IPSec instead of TLS?

In general, I want "best effort security", by which I mean I want a 
secure call if I can get it, else I want an insecure call. But I want to 
know for sure which I got, so I can make a decision about how I use it.

Perhaps there could be multiple degrees of security, though in practice 
I don't think that will be sufficiently user friendly.

And I can imagine some environments where only secure calls are 
acceptable and others should fail. But I think that is the exception 
rather than the rule.

If the call is "secure", I don't much care what mechanism was used to 
achieve it. But I do want some assurance that I have received the degree 
of security that is being asserted. That could be via some combination 
of technologies and legal agreements.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Oct 2006 14:11:45 -0400

OK, I know I am not sufficiently competent on security matters to 
comment here. Nevertheless I will try:

It seems to me that if we are to have SIPS, then rather than tying it to 
TLS or (D)TLS, or just defining it as "some security mechanism", it 
ought to be tied to an extensible list of security mechanisms, with an 
IANA registry and a procedure for approving new ones. We can argue over 
the criteria that a new one must meet to qualify, but we won't have 
restricted how many answers there are.

	Paul

Dean Willis wrote:
> That's useful to know. It might be possible to persuade the UDP fans in 
> mobile land to use DTLS. I'm hearing good things about DTLS from other 
> folks who have played with it on small systems.
> 
> But please help us understand what's different about IPSEC usage in the 
> IMS sense.
> 
> IMS has a persistent IPSEC SA established between the edge proxy and the 
> UA. Authentication is accomplished using the SIM as a token generator, 
> and the crypto is one of the usual mechanisms (keep in mind TLS still 
> allows plain small-key DES, which isn't all that strong). The 
> applications are constructed so that the SIP function is aware of the SA 
> and that it is connected to an authenticated party.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Oct 2006 14:29:05 -0400

I think that is some new mechanism, that needs a lot of work, and it's not
sips.  It has value, but I don't think we know how to do that.  I think we
could engineer a solution, although probably not real soon.

I would think you describe some set of properties you require, have some way
to "vet" that a particular mechanism meets those properties, and then each
hop can select among the available vetted mechanisms to meet the desired
properties.  

I don't think agreeing on a suitable set of properties will be easy, and I
don't think agreeing on how various tools we have map into those properties
will be easy, but I think it may be possible.

I would give that mechanism a new name, and it may be worthy of its own work
group.  In the mean time sips = TLS (or DTLS) on every hop is of value, and
easily specified.

Brian

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, October 27, 2006 2:12 PM
> To: Dean Willis

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Oct 2006 13:25:37 -0500

Agree. 

> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Friday, October 27, 2006 10:57 AM
> To: 'Dean Willis'; 'EKR'
> Cc: 'Joel M. Halpern'; 'IETF SIP List'
> There are a lot of mechanisms that can create a secure 
> connection between two entities.  It is often hard to equate 
> the security properties of those mechanisms.  Even between 
> IPSEC and TLS, with the same ciphersuite, you don't have the 
> same security properties.  
> 
> The problem I have is that then sips means "we think we have 
> created something approximating what you asked for, by 
> assembling a set of mechanisms across the hops, and we think 
> you should be happy"
> 
> I don't see how you admit IPSEC under some circumstances (and 
> it would have to be fairly carefully locked down to a set of 
> specific circumstances.  For example, you can't allow the 
> IPSEC tunnel to connect more than the two parties across a 
> hop) and then say some other mechanisms are not allowed.
> For example suppose I had a military grade link encryptor and 
> just a proxy on each end of the link.  It's a slippery slope.
> 
> It may be possible to create some new mechanism that 
> describes the security properties required, and allows any 
> mechanism that meets those properties at any hop.  I don't 
> think that is sips.
> 
> Brian
> 
> > >>> Well, I do. The security (authentication) properties of 
> IPsec are 
> > >>> rather different then those of TLS. And why just say 
> IPsec is OK. 
> > >>> What about WEP? What Once you relax the meaning to 
> "secure" then 
> > >>> it's more or ess meaningless.
> > >>
> > > any transport has basically the same security properties, 
> which is 
> > > the relevant issue here.
> > 
> > generator, and the crypto is one of the usual mechanisms 
> (keep in mind 
> > TLS still allows plain small-key DES, which isn't all that strong). 
> > The applications are constructed so that the SIP function 
> is aware of 
> > the SA and that it is connected to an authenticated party.
> >

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Oct 2006 12:25:48 -0700

>WEP? What Once you relax the meaning to "secure" then it's more or 
This is true even with TLS: you can have wildly different security 
properties between
two TLS sessions. SIPS happily paves over those differences with the in 
context
meaningless word "secure".

Let's put it this way: if you were charged with determining whether a 
system was
adequately defended would SIPS *alone* tell you anything useful about 
its worthiness
to withstand attacks? I claim not. That's pretty different than HTTPS.

       Mike

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Oct 2006 14:42:39 -0500

Right: this is exactly my position too. 

> Sent: Friday, October 27, 2006 11:29 AM
> To: 'Paul Kyzivat'; 'Dean Willis'
> I think that is some new mechanism, that needs a lot of work, 
> and it's not sips.  It has value, but I don't think we know 
> how to do that.  I think we could engineer a solution, 
> although probably not real soon.
> 
> I would think you describe some set of properties you 
> require, have some way to "vet" that a particular mechanism 
> meets those properties, and then each hop can select among 
> the available vetted mechanisms to meet the desired properties.  
> 
> I don't think agreeing on a suitable set of properties will 
> be easy, and I don't think agreeing on how various tools we 
> have map into those properties will be easy, but I think it 
> may be possible.
> 
> I would give that mechanism a new name, and it may be worthy 
> of its own work group.  In the mean time sips = TLS (or DTLS) 
> on every hop is of value, and easily specified.
> 
> Brian
> 
> > It seems to me that if we are to have SIPS, then rather 
> than tying it 
> > to TLS or (D)TLS, or just defining it as "some security 
> mechanism", it 
> > IANA registry and a procedure for approving new ones. We can argue 
> > over the criteria that a new one must meet to qualify, but we won't 
> > have restricted how many answers there are.
> > 
> > 	Paul
> > 
> > Dean Willis wrote:
> > >
> > >>>> Well, I do. The security (authentication) properties 
> of IPsec are 
> > >> No, I don't see a problem with that. It seems to me that (D)TLS 
> > >> over any transport has basically the same security properties, 
> > >> which is the relevant issue here.
> > >
> > > strong). The applications are constructed so that the SIP 
> function 
> > > is aware of the SA and that it is connected to an 
> authenticated party.
> > >

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Oct 2006 12:50:29 -0700

>that each hop do the same thing.

No. TLS is a hopwise mechanism. SIPS is a hopwise mechanism mated to
transitive trust. They are not even remotely the same. They have *vastly*
different security properties.

>time but have a fairly good understanding of how to do it now.
                    ^^
    There's a missing pronoun here. If it was an implicit we, it must be 
a royal we
    because there seems to be a lot of people who don't understand what 
it's intended to
    do, let alone how to fix it.

>Go ahead and suggest something. All I see you doing now is complaining.
Golly, I tried to that about 5 years ago and what we got instead is SIPS 
at the
last minute with little if any consensus. And lo and beyond, 5 years 
later we
have a dysfunctional piece of protocol with little consensus and even 
less agreement
on what should be done. So pardon me if I'm not biting on the chomp when the
people who brought this to us still insist there's nothing wrong, and 
are in the
position to make empty jestures as rhetorical devices.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Oct 2006 12:58:15 -0700

>group.  In the mean time sips = TLS (or DTLS) on every hop is of value, and
Why should it be taken as a given the DTLS has the same properties as 
TLS? That
is far from clear, not least of which is that DTLS is brand spanking new 
vs. the
years and years of experience had with TLS. Extending SIPS to DTLS 
sustantially
weakens the argument about why other protocols are not adequate. IPsec, 
for example,
has way more water under the bridge, and there's a lot institutional 
knowledge about
its properties, warts and all.

       Mike

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 13:02:59 -0700

Michael Thomas <[email-masked]> writes:

> two TLS sessions.

Absolutely true. But the authentication properties (once you
profile the cert validation rules as done in 3261) do not vary
very much.

> SIPS happily paves over those differences with the
> in context

I don't agree that it wouldn't tell you anything useful.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Oct 2006 13:04:37 -0700

>I don't agree that it wouldn't tell you anything useful.
Care to elucidate? What does it tell you by _itself_?

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Oct 2006 13:07:07 -0700

Paul Kyzivat wrote:

> secure call if I can get it, else I want an insecure call. But I want 
> to know for sure which I got, so I can make a decision about how I use 
> it.

The base problem here is that people are trying to shoehorn a BCP into a 
normative
protocol. For a BCP, it would be perfectly reasonable to say "if you get 
TLS in, send
TLS out". Good net citizen, have a cookie. You get all of the same 
assurances as SIPS
(which is to say, none), but don't  drag in all of this pretzel logic 
about what
should happen when you have a WUP (worst uncommon practice) in the path, 
and all of
the unintended conflation of SIPS with HTTPS by the unwashed masses.

       Mike

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 13:16:34 -0700

> different security properties.

Sure. The message that started this chain read:

      , and I'm certainly

So, feel free to substitute "SIPS" for "SIP over TLS" in the above
sentence.

>     There's a missing pronoun here. If it was an implicit we, it must
>     be a royal we
>     because there seems to be a lot of people who don't understand
>     what it's intended to

Sure, me plus some other people.

> Golly, I tried to that about 5 years ago and what we got instead is
> SIPS at the

Funny, what I remember about five years ago was that you were
mostly doing the same kind of complaining you're doing now,
so pardon me if I don't consider the fact that you're unhappy
with SIPS to be a total showstopper.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 13:22:23 -0700

Michael Thomas <[email-masked]> writes:

> TLS? 
> That
> is far from clear, not least of which is that DTLS is brand spanking
> new vs. the
> years and years of experience had with TLS.

It shouldn't be taken as a given, it should be concluded from studying
the two protocols. There is an extended discussion of this point
in the DTLS paper (not the RFC).

> Extending SIPS to DTLS
> sustantially
> weakens the argument about why other protocols are not
> adequate. IPsec, for example,

The issue isn't primarily about security level, but rather about the
security guarantees and model it's intended to implement. The
authentication, key management and dataflow model of DTLS matches
TLS and that's the kind of thing I worry about getting right
at least as much as the crypto.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 13:24:45 -0700

> Care to elucidate? What does it tell you by _itself_?

Sure, it allows you to verify that you're talking to the correct
next person and that if they also behave as they are required
to, there will be a secure (minimally authenticated) channel
between you and the final proxy. If SIPS were revised to remove
the last hop exception then you could write "UAS" for "final
proxy".

-Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Oct 2006 16:34:04 -0400

Note that my comment and Brian's initial one on the same subject were 
independently and simultaneously created. As soon as I saw Brian's 
comment I knew he would be replying back to me.

I don't dispute that making the necessary specifications will be hard. I 
don't know if it would be useful to attach the SIPS name to this new 
thing or not. It may be that some other way (e.g. Proxy-Require) would 
be better. Or maybe a scheme name, SIPS or something else, would really 
be good for it.

But I'm so far not convinced that an all-TLS-based SIPS actually 
delivers anything that has a practical use.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Oct 2006 15:54:05 -0500

The practical use is to be able to deploy hop-by-hop TLS-based SIP
signalling (using transitive trust), with the current RFC 3261 
complemented with the explanation of my draft, in the SHORT TERM.

I.e., without waiting for SIP to develop the next protocol that
allows for0
the Session Initiation Protocol (SIP). It is intended that potential solutions 
specifying certificate authentication within SIP will use these requirements as 
guidelines. Supporting certificate authentication in SIP would provide strong 
authentication and increase the types of possible deployment scenarios.'</P>
<P></P>
<P>As a note, the I-D has been updated based on various offline comments 
received at IETF#66 regarding draft-00.</P>
<P></P>
<P>Comments and thoughts are appreciated.</P></FONT></SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV align=left>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt" align=left><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Thanks,</SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt" align=left><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt" align=left><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Steve.</SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt" align=left><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</P></DIV></BODY></HTML>

------_=_NextPart_001_01C6FA09.EA780D46--

--=======14836738=

--=======14836738=--

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Oct 2006 15:54:05 -0500

I.e., without waiting for SIP to develop the next protocol that
allows for other alternative security mechanisms.

You have to understand that people ARE implementing sips today because
of market demand. They won't stop doing this because we promise them
that a few years from now, we'll have something better.

I'd much rather have implementations that follow our recommendations
on that front, rather than have vastly different intrepretation of
RFC 3261's SIPS. If we don't have practical guidelines for the current
state of the art, that's exactly what will happen.

I don't believe any of us is arguing that sips is the greatest thing
since slice bread. I don't think any of us is arguing that it is
unreasonable to use other protocols for securing SIP either (although
there is a split of opinions on if that should be called sips or not).
We are just saying that sips can relatively easily be made to work for 
hop-by-hop TLS, in the short term.

> Sent: Friday, October 27, 2006 1:34 PM
> Cc: Brian Rosen; Dean Willis; Joel M. Halpern; IETF SIP List
> Note that my comment and Brian's initial one on the same 
> subject were independently and simultaneously created. As 
> soon as I saw Brian's comment I knew he would be replying back to me.
> 
> I don't dispute that making the necessary specifications will 
> be hard. I don't know if it would be useful to attach the 
> SIPS name to this new thing or not. It may be that some other 
> way (e.g. Proxy-Require) would be better. Or maybe a scheme 
> name, SIPS or something else, would really be good for it.
> 
> But I'm so far not convinced that an all-TLS-based SIPS 
> actually delivers anything that has a practical use.
> 
> 	Paul

 other alternative security mechanisms.

You have to understand that people ARE implementing sips today because
of market demand. They won't stop doing this because we promise them
that a few years from now, we'll have something better.

I'd much rather have implementations that follow our recommendations
on that front, rather than have vastly different intrepretation of
RFC 3261's SIPS. If we don't have practical guidelines for the current
state of the art, that's exactly what will happen.

I don't believe any of us is arguing that sips is the greatest thing
since slice bread. I don't think any of us is arguing that it is
unreasonable to use other protocols for securing SIP either (although
there is a split of opinions on if that should be called sips or not).
We are just saying that sips can relatively easily be made to work for 
hop-by-hop TLS, in the short term.

> Sent: Friday, October 27, 2006 1:34 PM
> Cc: Brian Rosen; Dean Willis; Joel M. Halpern; IETF SIP List
> Note that my comment and Brian's initial one on the same 
> subject were independently and simultaneously created. As 
> soon as I saw Brian's comment I knew he would be replying back to me.
> 
> I don't dispute that making the necessary specifications will 
> be hard. I don't know if it would be useful to attach the 
> SIPS name to this new thing or not. It may be that some other 
> way (e.g. Proxy-Require) would be better. Or maybe a scheme 
> name, SIPS or something else, would really be good for it.
> 
> But I'm so far not convinced that an all-TLS-based SIPS 
> actually delivers anything that has a practical use.
> 
> 	Paul

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Oct 2006 14:25:41 -0700

Eric Rescorla wrote:

>next person....

This is correct, and just as easily accomplished by talking to a well known
sip-over-tls port.

> and that if they also behave as they are required
This is just a hope on the part of the UAC. In analyzing a system, I'd 
expect that
you'd be more rigorous than vague and unverifyable hopes. In which case SIPS
does not provide anything useful by itself.

       Mike

---

From: Dean Willis <[email-masked]>
Date: Fri, 27 Oct 2006 16:50:17 -0500

On Oct 27, 2006, at 4:25 PM, Michael Thomas wrote:

> This is just a hope on the part of the UAC. In analyzing a system,  
> I'd expect that

So what we have here is a security assurance that's equivalent to  
having your used car salesman (and you know where he lives) promise  
to provide service after the sale, as opposed to a sale where you  
have no such promise and are buying your goods out of the back of an  
unmarked van from some guy named Joe.

It all comes down to "you trust the sed-car sales guy more (even  
though he MIGHT cheat you) because there's a chance you can come  
after him if the deal goes bad."

While not rigorous, that's still a little better basis for trust than  
nothing at all.

--
Dean

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 14:49:12 -0700

Sure.

> does not provide anything useful by itself.

If by "just a hope" you mean "the client can't enforce it" then sure,
that's true. But that doesn't make it valueless, it simply means
that the proxy is inside of your trust boundary. Sure, that's not
as nice as having it not be inside of your trust boundary, but
it's a tradeoff.

Anyway, I think we've said all there is useful to say here. We
all agree about what the behavior of SIPS is, you just happen
to think it's not of value whereas I do. Continuing to reassert
our opinions doesn't really buy us anything.

-Ekr

---

From: Dean Willis <[email-masked]>
Date: Fri, 27 Oct 2006 16:50:17 -0500

--
Dean

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 14:49:12 -0700

Sure.

-Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Oct 2006 18:24:54 -0400

> complemented with the explanation of my draft, in the SHORT TERM.

The problem I have with this is that it takes us from "the emperor is 
naked" to "the emperor is in his underwear".

If you take a system built using SIP over UDP, and upgrade it to SIPS, 
what can you now put in your sales brochure that you couldn't put before?

Apparently you can't now advertise "secure calling" or put a little lock 
icon on the display. All you can say is "we don't suck as bad as we used 
to". and you probably can't even realize this level of improvement on 
all calls. You still must be prepared for cases where you can't get 
SIPS. So I guess the claim must be "we don't suck as bad as we used to, 
on some calls". Maybe we could put a little "half ass" icon up when the 
call is via SIPS.

How much extra investment does that justify?

It seems like the best we could do is start deploying SIPS as a hidden 
cost of doing business, to try to get closer to what most customers no 
doubt assume is already there. But unless it is done quite ubiquitously 
it won't even help reduce the possibility of some really bad exploit 
happening.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Oct 2006 17:36:14 -0500

> Sent: Friday, October 27, 2006 3:25 PM
> The problem I have with this is that it takes us from "the 
> emperor is naked" to "the emperor is in his underwear".
> 
> If you take a system built using SIP over UDP, and upgrade it 
> to SIPS, what can you now put in your sales brochure that you 
> couldn't put before?

You can can deploy a network that allows sessions to be established
end-to-end security using TLS. Provided of course that all the proxies
are compliant (transitive trust).

You can NOT do that today without SIPS because there is no way
with SIP only to request that all hops be over TLS.

It's as simple as that.

It's not just a "sales brochure" thing. It's real funtionality.

> Apparently you can't now advertise "secure calling" or put a 
> little lock icon on the display. All you can say is "we don't 
> suck as bad as we used to". and you probably can't even 
> realize this level of improvement on all calls. You still 
> must be prepared for cases where you can't get SIPS. So I 
> guess the claim must be "we don't suck as bad as we used to, 
> on some calls". Maybe we could put a little "half ass" icon 
> up when the call is via SIPS.

This has absolutely nothing to do with what SIPS is intended to
do.

The draft makes it clear sips != padlock icon.

Again, the whole idea is to allow for establishing a session to
an address which implies that all hops will be over TLS.

> It seems like the best we could do is start deploying SIPS as 
> a hidden cost of doing business, to try to get closer to what 
> most customers no doubt assume is already there. But unless 
> it is done quite ubiquitously it won't even help reduce the 
> possibility of some really bad exploit happening.

I fail to see the relevance of this last paragraph to the discussion
of sips.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 27 Oct 2006 18:37:47 -0400

Part of what drove me to participate in this discussion is 
remembering a conversation with an operator who was deploying a SIP 
based service.  They have (had?) IPSec tunnels between their proxies 
and other service provides' proxies.  They know who is who.  They 
don't need a TLS certificate from the other proxy. The security they 
are delivering is, as far as I can tell, as good as that delivered by 
any pure TLS mechanism.  Possibly better than some.
But, as written, what they have done is against the rules.
And folks are complaining about it.
(So, we have an operator actually delivering security, and we give 
him grief.  This encourages security delivery?)

Maybe there is some way in which their security was actually noticeably weaker.
But it seems to me pretty strange for us to try to claim that such a 
deployment is insecure.
And it seems to me that the user is getting what he wants when he uses it.

Yours,
Joel M. Halpern

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 15:41:16 -0700

"Joel M. Halpern" <[email-masked]> writes:

> Part of what drove me to participate in this discussion is remembering
> a conversation with an operator who was deploying a SIP based service.
> They have (had?) IPSec tunnels between their proxies and other service
> provides' proxies.  They know who is who.  They don't need a TLS
> certificate from the other proxy. The security they are delivering is,
> as far as I can tell, as good as that delivered by any pure TLS
> mechanism.  Possibly better than some.
> (So, we have an operator actually delivering security, and we give him
> grief.  This encourages security delivery?)
>
> Maybe there is some way in which their security was actually
> noticeably weaker.  But it seems to me pretty strange for us to try
> to claim that such a deployment is insecure. And it seems to me
> that the user is getting what he wants when he uses it.

Who's claiming that it's insecure? I said it was noncompliant, not
insecure.

Anyway, it's not at all clear that an IPsec tunnel is actually
as good as TLS in this context. Is this a host-to-host tunnel or
a VPN? What's in the certificate, a domain name or an IP address?
There are lots of ways to bungle this with IPsec--and of course
with TLS too, but the difference is that we've profiled tLS
here.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Oct 2006 15:59:18 -0700

>are compliant (transitive trust).
No, no, no, no, no, NO! This is *exactly* why this is such an absolute 
crock.
That is *not* end-to-end security. This is exactly why sanctioning this 
half-baked
scheme is so dangerous. Harmful, even. It's bad enough when sales droids
embrace and extend the truth, but when you give them something that is so
trivial to get completely wrong and not even requiring so much as a grin 
f*ck...
that's a problem.

       Mike

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Oct 2006 18:05:26 -0500

Joel, there is nothing wrong with this. Nobody said it was insecure.

It just is not sips. 

> Sent: Friday, October 27, 2006 3:38 PM
> To: EKR
> Cc: 'IETF SIP List'
> remembering a conversation with an operator who was deploying 
> a SIP based service.  They have (had?) IPSec tunnels between 
> their proxies and other service provides' proxies.  They know 
> who is who.  They don't need a TLS certificate from the other 
> proxy. The security they are delivering is, as far as I can 
> tell, as good as that delivered by any pure TLS mechanism.  
> Possibly better than some.
> (So, we have an operator actually delivering security, and we 
> give him grief.  This encourages security delivery?)
> 
> noticeably weaker.
> But it seems to me pretty strange for us to try to claim that 
> such a deployment is insecure.
> >>>>Well, I do. The security (authentication) properties of IPsec are 
> >>>>rather different then those of TLS. And why just say IPsec is OK. 
> >>>>What about WEP? What Once you relax the meaning to "secure" then 
> >TLS still allows plain small-key DES, which isn't all that 
> strong). The 
> >applications are constructed so that the SIP function is 
> aware of the 
> >SA and that it is connected to an authenticated party.
> >

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Oct 2006 16:06:26 -0700

>with SIPS to be a total showstopper.
Funny, your memory is wrong. I was there for the first real SIP security 
get together
in, what, Adalaide? You weren't. I wrote a problems/framework draft, and was
active in the Packetcable voice security specification which predates 
any of this
including SRTP. As I recall, your first introduction was on the 
complaining side,
not the specifying side right before 3261 was about to go to last call.

So here we are, 5 years later. Boy oh boy, that big dollop of "security" 
that got
thrown in at the last minute sure was a godsend. Heavens, what would we have
done without S/MIME and SIPS? Silly me to think that separating out the 
problems
so they actually fit the requirements was a better plan.

       Mike

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Oct 2006 18:05:26 -0500

It just is not sips.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Oct 2006 16:06:26 -0700

Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Oct 2006 16:20:05 -0700

Francois Audet wrote:

>Please calm down.
>
>Here is one simple scenario.
>
>I deploy an Enteprise SIP network. I install 10 SIP proxies 
>accross the Corporate Network. All the proxies are certified to 
>properly implement SIPS. All the phones are also certified to
>implement SIPS properly. I know, because I am responsible for the
>network.
>
>An end user can call another end-user within that network
>with the certitude that if sips is used, it will be secured
>end-to-end.
>

How about an example when it's not all within the same administrative
entity. How abouts some examples that resemble, oh say, the mail system.
These have always been where my concerns are. Within my own domain,
I don't need SIPS; I can do that by executive fiat.

       Mike

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Oct 2006 19:21:51 -0400

> with SIP only to request that all hops be over TLS.

WHY would you do that, rather than just use SIP over UDP or TCP?

Presumably because you think it makes something better that somebody 
cares about. What is that?

> It's not just a "sales brochure" thing. It's real funtionality.

What functionality is it? Do people pay extra to get it?
What is it you tell them to get them to pay extra?

> I fail to see the relevance of this last paragraph to the discussion

When you put in SIPS, do you make *all* calls be SIPS? If not, how do 
you deal with the ones that are vs those that aren't?

For example: maybe you build a "SIPS PBX" that uses SIPS throughout the 
enterprise where it is deployed. The next wanted is SIP-based trunking 
to a service provider. Hopefully the SP is interested in supporting 
SIPS. But do you insist the SP use TLS throughout? Or maybe just to an 
SBC. (After all, an SBC is a UA, so it terminates the call.) Maybe it 
does SIP over IPsec on the other side. Is that ok?

What if that SP also terminates other enterprises that you sometimes 
call. And not all of them support SIPS. What happens when you call them? 
Do your calls have to hairpin through the PSTN because that is the only 
legal way to get from SIPS to SIP? Or do you somehow discover they only 
do SIP, so you use SIP when calling them?

Let me restate one question above because I think it might be a big deal:

How does SIPS work with B2BUAs/SBCs? Is it ok for an SBC to splice 
together a SIPS call and a SIP call? Do anybody believe this won't happen?

	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 16:12:24 -0700

Michael Thomas <[email-masked]> writes:

> Funny, your memory is wrong. I was there for the first real SIP
> security get together

> So here we are, 5 years later. Boy oh boy, that big dollop of
> "security" that got
> done without S/MIME and SIPS? Silly me to think that separating out
> the problems

You know, I considered responding to this, but honestly, it's
just not worth my time. 

Wake me up when you're prepared to have a technical discussion 
without the invective.

-Ekr

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Oct 2006 18:11:41 -0500

Please calm down.

> Sent: Friday, October 27, 2006 3:59 PM
> Cc: Paul Kyzivat; Joel M. Halpern; IETF SIP List; Dean Willis
> No, no, no, no, no, NO! This is *exactly* why this is such an 
> absolute crock.
> That is *not* end-to-end security. This is exactly why 
> sanctioning this half-baked scheme is so dangerous. Harmful, 
> even. It's bad enough when sales droids embrace and extend 
> the truth, but when you give them something that is so 
> trivial to get completely wrong and not even requiring so 
> much as a grin f*ck...
> that's a problem.
> 
>        Mike
> 
> >You can NOT do that today without SIPS because there is no 
> way with SIP 
> >only to request that all hops be over TLS.
> >
> >It's as simple as that.
> >
> >>Apparently you can't now advertise "secure calling" or put a little 
> >>lock icon on the display. All you can say is "we don't suck 
> as bad as 
> >>we used to". and you probably can't even realize this level of 
> >>improvement on all calls. You still must be prepared for 
> cases where 
> >>you can't get SIPS. So I guess the claim must be "we don't 
> suck as bad 
> >>as we used to, on some calls". Maybe we could put a little 
> "half ass" 
> >>icon up when the call is via SIPS.
> >>    
> >>
> >

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Oct 2006 18:26:03 -0500

> Sent: Friday, October 27, 2006 4:20 PM
> Cc: IETF SIP List
> accross the 
> >Corporate Network. All the proxies are certified to properly 
> implement 
> >SIPS. All the phones are also certified to implement SIPS 
> properly. I 
> >know, because I am responsible for the network.
> >
> >An end user can call another end-user within that network with the 
> >certitude that if sips is used, it will be secured end-to-end.
> >
> 
> How about an example when it's not all within the same 
> administrative entity. How abouts some examples that 
> resemble, oh say, the mail system.
> These have always been where my concerns are. Within my own 
> domain, I don't need SIPS; I can do that by executive fiat.

In that case, if you don't have trust with them, then don't use
sips. As simple as that.

Yes you need sips in your own domain, because some devices support TLS, 
others don't. Some users want to be addressed securily, others don't.

5-Ny
	for [email-masked]; Fri, 27 Oct 2006 19:26:10 -0400
Content-class: urn:content-classes:message
Subject: RE: [Sip] RE: TLS meaning
Date: Fri, 27 Oct 2006 18:26:03 -0500
From: "Francois Audet" <[email-masked]>
To: "Michael Thomas" <[email-masked]>
Cc: IETF SIP List <[email-masked]>

> Sent: Friday, October 27, 2006 4:20 PM
> Cc: IETF SIP List
> accross the 
> >Corporate Network. All the proxies are certified to properly 
> implement 
> >SIPS. All the phones are also certified to implement SIPS 
> properly. I 
> >know, because I am responsible for the network.
> >
> >An end user can call another end-user within that network with the 
> >certitude that if sips is used, it will be secured end-to-end.
> >
> 
> How about an example when it's not all within the same 
> administrative entity. How abouts some examples that 
> resemble, oh say, the mail system.
> These have always been where my concerns are. Within my own 
> domain, I don't need SIPS; I can do that by executive fiat.

In that case, if you don't have trust with them, then don't use
sips. As simple as that.

Yes you need sips in your own domain, because some devices support TLS, 
others don't. Some users want to be addressed securily, others don't.

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 27 Oct 2006 18:30:25 -0500

I am just catching up in the reverse order of mails. 

Typical NAT mentality... Polluting the protocol. My VISION is of SIPNET
...

Thx
Samir

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Oct 2006 16:32:44 -0700

>others don't. Some users want to be addressed securily, others don't.
No. I do not require a signaling element to decide whether to route via
SIP/TLS or  just SIP. I can just as easily statically provision it. Or I can
try it on a SIP/TLS listener port first. Or any other way to do the same
thing.

In any case, you didn't respond to my point that SIPS is not end to end
security. That's just false on its face, and the seeming fact that you don't
get the difference is the tip of a very problematic iceberg.

       Mike

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Oct 2006 19:08:57 -0500

> No. I do not require a signaling element to decide whether to 
> route via SIP/TLS or  just SIP. I can just as easily 
> statically provision it. Or I can try it on a SIP/TLS 
> listener port first. Or any other way to do the same thing.

You do if if it's the originator that wants to use TLS hop-by-hop.

> In any case, you didn't respond to my point that SIPS is not 
> end to end security. That's just false on its face, and the 
> seeming fact that you don't get the difference is the tip of 
> a very problematic iceberg.

We all understand that sips is NOT an end-to-end security protocol,
no need to insult people.

In any case, what I haven't heard from you is a useful proposal on
what you would actually do.

We're just trying to deal with the cards we are given.

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 27 Oct 2006 18:55:12 -0500

Hello All,

   The better would have been similar to what was done in SNMP v2 and
v3. 

Instead of just filing the some text, as IESG required for the security
considertation. Deprecate SIPS altogether. 

Call SIP V2 as UNSECURE and Create SIP V3 with security, or use it with
more elegant Proxy-Require/Require tag with my proposal.

Thx
SAmir

> > thrown in at the last minute sure was a godsend. Heavens, what would
we
> have

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 27 Oct 2006 19:05:06 -0500

> together a SIPS call and a SIP call? Do anybody believe this won't
happen?

I asked the same question. And then our man came up, we don't want to
state this.  And even the quys from leading SBC vendor agreed that, we
don't need it.. Great !! people don't want to know their own product
requirement !!!!

Thx
Samir

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2006 17:16:19 -0700

> more elegant Proxy-Require/Require tag with my proposal.

This assumes the exact point under discussion, namely that SIPS can't
be made good enough.

-Ekr

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 27 Oct 2006 19:31:54 -0500

Yes. Today's thread is converting into the another wacky thread. I am
still going through with different person's arguments.

Okay. how can I route telURI, urn etc over the SIP network securely with
only SIPS even if I accept the known caveats of last hop exception,
retargeting etc..

Thx
Samir

> Sent: Friday, October 27, 2006 5:16 PM
> To: Srivastava, Samir (SC100:8826)
> Cc: Michael Thomas; ext Cullen Jennings; Peterson, Jon; IETF SIP List;
> Audet, Francois (SC100:3055); Dean Willis

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 28 Oct 2006 09:40:32 +0300

> with SIP only to request that all hops be over TLS.

you cannot do that today with SIPS either, because SIPS according to
RFC3261 does NOT require that ALL hops are over TLS.  and if you check
the mailing list archives and even this present thread, you see that
there is no agreement that SIPS MUST mean "ALL hops are over TLS".  so i
don't understand what you are talking about.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 28 Oct 2006 09:42:20 +0300

> And it seems to me that the user is getting what he wants when he

yes, but has no way of knowing for sure what he gets.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 28 Oct 2006 09:40:32 +0300

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 28 Oct 2006 09:42:20 +0300

-- juha

---

From: David R Oran <[email-masked]>
Date: Sat, 28 Oct 2006 08:43:21 -0400

Sorry to jump into the middle of the thread, but given the long  
chain, I had to pick somewhere to insert my personal opinion. I'll  
note that I'm one of the guilty parties in raising the whole question  
about the utility of sips, so I guess I ought to support some way  
forward here. There was a suggestion earlier in the thread I really  
liked, which I think was:

a) get rid of sips as a url scheme.
b) write a BCP which says if you get TLS in, send TLS out.

In what way does this not give us EXACTLY the capability we have with  
SIPS, without all the complexity of a separate url scheme and the  
semantic mismatch problems people (including me) keep hammering on  
when we compare sips to https.

Dave Oran.

On Oct 27, 2006, at 6:24 PM, Paul Kyzivat wrote:

> The problem I have with this is that it takes us from "the emperor  
> is naked" to "the emperor is in his underwear".
>
> If you take a system built using SIP over UDP, and upgrade it to  
> SIPS, what can you now put in your sales brochure that you couldn't  
> put before?
>
> lock icon on the display. All you can say is "we don't suck as bad  
> as we used to". and you probably can't even realize this level of  
> improvement on all calls. You still must be prepared for cases  
> where you can't get SIPS. So I guess the claim must be "we don't  
> suck as bad as we used to, on some calls". Maybe we could put a  
> little "half ass" icon up when the call is via SIPS.
>
> It seems like the best we could do is start deploying SIPS as a  
> hidden cost of doing business, to try to get closer to what most  
> customers no doubt assume is already there. But unless it is done  
> quite ubiquitously it won't even help reduce the possibility of  
> some really bad exploit happening.
>
> 	Paul
>
>> We are just saying that sips can relatively easily be made to work  
>> for hop-by-hop TLS, in the short term.
>>> From: Paul Kyzivat [mailto:[email-masked]] Sent: Friday,  
>>> October 27, 2006 1:34 PM
>>> Note that my comment and Brian's initial one on the same subject  
>>> were independently and simultaneously created. As soon as I saw  
>>> Brian's comment I knew he would be replying back to me.
>>>
>>> I don't dispute that making the necessary specifications will be  
>>> hard. I don't know if it would be useful to attach the SIPS name  
>>> to this new thing or not. It may be that some other way (e.g.  
>>> Proxy-Require) would be better. Or maybe a scheme name, SIPS or  
>>> something else, would really be good for it.
>>>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 28 Oct 2006 06:34:04 -0700

> when we compare sips to https.

And what if you can't send TLS out because the other side doesn't
support it? If you go ahead and proceed with SIP in the clear, then
you've introduced an active attack problem (downgrade attack). If you
fail, then you've disincentivized people from securing *any* link
with TLS because it may cause their calls to fail. This is an
especially serious issue with long-term connections like outbound
encourages.

>From a security perspective, SIPS has two important properties:

1. It says to the client "you MUST talk to me over SSL".
2. It says to the proxies "I expect you to make the outgoing
   connection with TLS". 

As Samir has observed, the second property can be provided with some
indicator in the SIP header. However, the first can only be provided
by putting the indicator in the reference which you hand around (i.e.,
the SIP URI). This isn't to say it necessarily has to be a new URI
scheme--though it did in HTTP because HTTP doesn't have
parameters--but it's not clear to me that moving it to parameters
would really help.

-Ekr

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sat, 28 Oct 2006 15:22:34 -0400

> From: Samir Srivastava [mailto:[email-masked]]
> >

I not sure if you're referring to me - I speak for myself on this list, not
my company.  My company is fine with SIPS, and with your proposal for a
proxy-require to specify the key size and such.  In fact, my company would
probably profit if such were used more often.  You can probably guess why
they would be more profitable if UAs started using such mechanisms.  It's
for the reasons I argued against such mechanisms.  

-hadriel
p.s. and I think I do know my product requirements.  It's my job to know
them, and I tend to be right more often than not. :)

---

From: "Prashant Kumar" <[email-masked]>
Date: Sat, 28 Oct 2006 22:55:11 -0400

I assume according to RFC3261, SIPS indicates that you should send over a
secure channel. The secure channel could be TLS, IPSEC or any other means
the provider thinks it is secure. I am not sure why people are trying to
associate SIPS with https and TLS even though the original intention may be
was that.

I am not understanding the significance of this discussion. However, in any
case downgrading from SIPS URI to a SIP URI does not look like a good idea
since the "secure" assurance provided by a SIPS will be lost in that case!

Regards,
Prashant.

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Saturday, October 28, 2006 3:23 PM
To: 'Samir Srivastava'; 'Paul Kyzivat'; 'Francois Audet'
Cc: 'Joel M. Halpern'; 'IETF SIP List'; 'Dean Willis'
Subject: RE: [Sip] RE: TLS meaning

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 28 Oct 2006 21:36:22 -0700

> associate SIPS with https and TLS even though the original intention may be

As previously noted, the security properties of these mechanisms
aren't identical, so it doesn't preserve the UAC's intentions
to use whatever means the provider thinks are secure.

-Ekr

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sun, 29 Oct 2006 16:26:23 -0500

> Sent: Saturday, October 28, 2006 9:34 AM

I hope it doesn't say that.  I thought we had to use TLS. ;)

> parameters--but it's not clear to me that moving it to parameters

I think the part some of us are worried about is it will inherit the
perception of https: namely that the entire path from the caller to the
answerer is secure.  Just because an IETF doc says it's not the same, and
says it's not a lock icon, will not overcome the perception.  Even though an
https connection is only secure to the TLS terminator (the server or an
offloader), and the back-end from there is not, the assumption is the owner
of the terminator takes on the responsibility from there (if there is any
responsibility).  And the terminator owner wanted to secure it between the
browser and the terminator, and they got that.

But SIP is neither HTTP nor SMTP.  The sips uri may end at a pstn gateway,
or an h323 IWF, or whatever.  It may become sip later, as well.  The owner
of the TLS terminator does not necessarily equal the owner of the final UAS,
nor the owner of the answerer.  How can the owner of the terminator have any
responsibility for something that may happen somewhere else, unbeknownst to
him?  How/why would someone who types in a sips uri for their request not
think it's like https?  

In some ways the perception problem is exacerbated by the uri being the sips
scheme.  If it were a require/proxy-require instead, it would help alleviate
that perception problem, IMO.  But then you're left with trying such a
request without the foreknowledge of success probability that a
business-card sips address would give you.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Mon, 30 Oct 2006 10:21:49 -0600

What does sips: do for us?

It allows the end-user to ask the proxies to apply hop-by-hop  
cryptography and authentication, with the assurance that proxies that  
support the spec will honor that request.

It's not a high level of security as it says nothing about and cannot  
detect non-compliant proxies, but it is a property that we don't have  
with any other SIP mechanism at this time.

Many people believe this is a useful property despite its  
limitations. People are apparently trying to use it today, with  
inconsistent results. Francois' draft is intended to at least help  
them produce consistent results.

As we think about alternatives or changes in specification, let's  
keep that one useful property in-mind.

This leaves us with two questions, and we should try and  
differentiate further discussion by which question we're talking about:

1) Is it worth helping people get what they can out of SIPS: as  
roughly described in 3261, or is it so broken we should just suggest  
not bothering?

2) Do we need to do something beyond what sips:-as-per-RFC 3261 does,  
and if so, what properties does that something need to have? I  
personally suspect that there are three useful categories of "beyond":

	a. Fix the last-hop exception and first-hop lack-of-exception,  
either by eliminating it/them or more clearly codifying what we're  
talking about.

	b. Clarify the usage for non-TLS alternatives, if any.

	c. Provide an end-to-end alternative that is fully verifiable by the  
UAC (and maybe the UAS). Of course, this leaves open the question of  
what happens if either node is a B2BUA.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Oct 2006 09:02:57 -0800

It seems to me that SIPS has and has always had things completely wrong: 
it views this
from the perspective of the sender who has little or no control over the 
path that the
request is routed. About the only thing that a sender can do is say 
"Hey, I'd like this
to happen, but I'm at your mercy." Such is the cost of transitive trust.

What it seems to me is that we should not be viewing this from the 
standpoint of the
sender, but instead of the _receiver_ who ultimately should decide 
whether to accept or
reject a session -- and is probably in the best position to know the 
preferences of the
possibly human callee.

So instead of having a one-size-fits all approach, suppose that we just 
do a couple
of things:

1) Allow the originator to specify whether they'd like signaling 
confidentiality/integrity
    along the path; this is NOT a demand, it is a "please".
2) Have the ability for each hop to label the level of 
confidentiality/integrity along the
    path (eg, protect=[none|tls|ipsec|docsis|...])
3) The receiver inspects both the sender's hope, the protection afforded 
along the path
     intersected with its local policies to determine whether to accept 
the session or not.
4) We have also have a BCP which says nice proxies/b2bua's send messages out
    with as good if not better integrity/confidentialilty on the next hop

This of course doesn't eliminate the possibility of lying middle 
proxies, but it does
get rid of busy-body middle proxies who fail calls in ways that neither 
the sender
or receiver have very good control over. I mean, ultimately we'd like to 
give as much
control over the fate of the session to the end UA, right?

This would, for example, give receivers like a phone UA the ability to
determine that once it gets into its trust boundary, the necessity for 
TLS does not
compromise its policy, and that the sender shouldn't be alarmed if it's 
not encrypted
the entire way to the UA. Likewise, for a public PSTN gateway it might 
be of the
mind that what the heck -- I'm going to turn around and reformat these 
media/signaling
bits in the clear, so why should I bother consuming my resources on the 
previous
hop?

The point here is that there are a *substantial* number of scenarios 
that have very
different needs which are trying to be rolled up into the single "S" bit 
of SIPS. This
was a fairly reasonable thing with HTTPS since it is essentially always 
e2e. SIP
has always had a proxy routed architecture, and is thus far more 
complicated...

          Mike, I have another idea, but I'll break that into a separate 
message

Dean Willis wrote:

>     c. Provide an end-to-end alternative that is fully verifiable by 
> the  UAC (and maybe the UAS). Of course, this leaves open the question 
> of  what happens if either node is a B2BUA.

---

From: Avshalom Houri <[email-masked]>
Date: Mon, 30 Oct 2006 19:22:06 +0200

In a closed system there is no need for SIPS since the system knows
if it is secure or not.

I an open system we know nothing about intermediaries so SIPS only
gives the feeling of security which to me seems worse then knowing that
the connection is not secure at all.

If we can achieve 2.c then we can use SIPS for that until then SIPS
seems more confusing then helping.

--Avshalom

30/10/2006 18:21

To
IETF SIP List <[email-masked]>
cc

Subject
[Sip] What good is SIPS:?

                 a. Fix the last-hop exception and first-hop 
lack-of-exception, 
either by eliminating it/them or more clearly codifying what we're 
talking about.

                 c. Provide an end-to-end alternative that is fully 
verifiable by the 
UAC (and maybe the UAS). Of course, this leaves open the question of 
what happens if either node is a B2BUA.