Subject: [sipcore] SIPS must die, die, die

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 10 Jun 2016 11:52:13 +0200

Friends,

I think it’s time to kill the SIPS: uri. I know that some of you thought it was dead, but it is not the case.

It doesn’t add anything, personally I don’t see it in use anywhere and it confuses a lot of discussions about TLS usage in SIP.

We need to see what happens if we remove SIPS: from the SIP playground - what’s missing?

Questions arise:

- Can we live without SIPS: and without “;transport=TLS” or do we need to take the transport parameter back?
- Can my TLS connection reuse idea (previous mail) solve UA to edge proxy issues?
- Do we need TLS transport in VIA headers?
- Are we going to have to prepare for DTLS transport too? (See Dale Worley’s previous emails) ?

I think it’s time to spend some time with TLS in SIPcore again. What do you think?

/O

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 10 Jun 2016 18:03:26 +0000

I agree that the SIPS URI is not dead, but it is clearly stated in RFC 5630 (which updates RFC 3261) that a successful call using a SIPS URI requires the use of TLS on each hop. Requests where this cannot be fulfilled have to be rejected.

That is surely a big enough hint to only use it where that is what you want.

Keith

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Olle E. Johansson
Sent: 10 June 2016 10:52
To: SIPCORE
Cc: Olle E Johansson
Subject: [sipcore] SIPS must die, die, die

Friends,

Questions arise:

/O

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 10 Jun 2016 18:07:08 -0400

"Olle E. Johansson" <[email-masked]> writes:
> I think it's time to spend some time with TLS in SIPcore again. What
> do you think?

My memory is that the latest revision decided, as Keith says, that if
you make a call to a sips: URI, you are guaranteed that every signaling
step is covered by TLS, or the call is rejected -- and "transport=TLS"
doesn't have that guarantee.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 11 Jun 2016 06:47:49 +0000

Hi,

> My memory is that the latest revision decided, as Keith says, that if you make a call to a sips: URI, you > are guaranteed that every signaling step is covered by TLS, or the call is rejected

...or the SIPS URI is "converted" to a SIP URI by an intermediary. In reality there is no guarantee.

Regards,

Christer

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Sat, 11 Jun 2016 13:53:44 +0000

The current status of the RFCs is clear.

While this behaviour may occur, it is non-conformant with the current requirements of the RFCs, and IETF cannot be the protocol police.

Keith

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 11 June 2016 07:48
To: Dale R. Worley; Olle E. Johansson
Cc: [email-masked]
Subject: Re: [sipcore] SIPS must die, die, die

Hi,

> you make a call to a sips: URI, you > are guaranteed that every 
> signaling step is covered by TLS, or the call is rejected

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 11 Jun 2016 14:11:31 +0000

I don't disagree.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Drage, Keith (Nokia - GB)<mailto:[email-masked]>
Sent: ‎11/‎06/‎2016 16:53
To: Christer Holmberg<mailto:[email-masked]>; Dale R. Worley<mailto:[email-masked]>; Olle E. Johansson<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [sipcore] SIPS must die, die, die

Keith

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 11 June 2016 07:48
To: Dale R. Worley; Olle E. Johansson
Cc: [email-masked]
Subject: Re: [sipcore] SIPS must die, die, die

Hi,

Regards,

Christer

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sat, 11 Jun 2016 14:12:09 +0000

God forbid real life implementation gets considered....   I could continue but considering the last discussion that shut down, I'll leave it at that

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards 
AT&T
Cell: 609-903-3360
Email: [email-masked]

> On Jun 11, 2016, at 9:54 AM, Drage, Keith (Nokia - GB) <[email-masked]> wrote:
>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Sat, 11 Jun 2016 16:53:06 +0000

5630 was there to make a precise statement about what the use of SIPS URI versus transport=tls meant. The former means the user wants TLS on every hop between the endpoints, the latter applies only to the current hop, with possibly some implication I trust my provider to do the rest.

Now you might argue there is space in there for "give me TLS on these bits, and I'll trust the rest to be secure" but that would seem to be getting a bit complicated to define.

Otherwise I would argue that deployments should respect the requirements of what a SIPS URI means, and only seek to improve on transport=TLS.

Keith

-----Original Message-----
From: DOLLY, MARTIN C [mailto:[email-masked]] 
Sent: 11 June 2016 15:12
To: Drage, Keith (Nokia - GB)
Cc: Christer Holmberg; Dale R. Worley; Olle E. Johansson; [email-masked]
Subject: Re: [sipcore] SIPS must die, die, die

Martin C Dolly

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 11 Jun 2016 12:59:48 -0400

> ...or the SIPS URI is "converted" to a SIP URI by an intermediary. In reality there is no guarantee.

So the choices are:

1) use SIPS as defined, meeting all the constraints
2) use SIPS but cheat when convenient
3) don't use SIPS

Can anyone cite are real deployments that meet (1)? I suspect there are 
none.

I hope nobody here is advocating (2). It has no useful security properties.

Hence ISTM that (3) is the only deployable alternative.

	Thanks,
	Paul

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 12 Jun 2016 08:02:39 +0000

I vote 3, don't use SIPS

Martin C Dolly

> On Jun 11, 2016, at 1:00 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Can anyone cite are real deployments that meet (1)? I suspect there are none.
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 12 Jun 2016 12:09:06 +0200

> On 10 Jun 2016, at 20:03, Drage, Keith (Nokia - GB) <[email-masked]> wrote:
> 
That’s the theory. But where’s the practise? I’ve seen old SIPura/linksys/cisco phones where you could add a prefix to the phone number and request a SIPS call. I guess zero calls was made using that feature

And even if the RFC says that TLS must be used in each hop, there’s no guarantee of anything, especially if the call is routed over another
technology somewhere, like ISDN. Is that even allowed for SIPS?

We struggled with this for a while in Asterisk, which is a multiprotocol b2bua and did not find any good solution on how to handle SIPS
in the dialplan or at all. And there was nothing to test with.

For me, I haven’t seen any use of SIPS anywhere. I do see a lot of TLS, used in default mode or opportunistic mode. But with SIP: 
URI schemes.

What’s the use case here? Is anyone really using SIPS anywhere and is that use-case not possible to handle without SIPS: in the URI?

/O

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Mon, 13 Jun 2016 13:56:25 +0000

That option was clearly understood by the SIP WG when we did RFC 5630. However it was decided to very clearly state what it meant so that both service providers and users could decide whether to use it or not, and they still have that freedom. I suspect the majority have chosen not to, but the option is still there.

Given that we spent so much time on providing RFC 5630 to update RFC 3261 in this area, I am reluctant to change the direction now - this achieved IETF consensus.

Keith

P.S. I also take this opportunity to remember Francois Audet, who did such a lot of work driving this document to completion.

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C
Sent: 12 June 2016 09:03
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [sipcore] SIPS must die, die, die

I vote 3, don't use SIPS

Martin C Dolly

>>>> I think it's time to spend some time with TLS in SIPcore again. 
>>>> What do you think?
>>> 
>>> My memory is that the latest revision decided, as Keith says, that 
>>> if you make a call to a sips: URI, you > are guaranteed that every

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 13 Jun 2016 18:24:14 +0000

On the question of "cheating," the SIPS mechanism was originally intended
to be used in concert with DNS records that advertised SIPS as a service:
see the security considerations of RFC3263, for example. I'm not aware
that RFC5630 overwrote any of that guidance. In some scenarios, this could
make it possible to detect an intermediary downgrade from SIPS to SIP, as
both the endpoints - the UAC that originally targeted a SIPS URI and the
UAS or destination proxy advertising the URI - can collaborate to make
sure SIPS is requested and expected.

In highly mediated networks where SIP requests transit many hops, I'm sure
SIPS is at best a nuisance. Its design optimized more for a trapezoid, or
something close to it, than a PSTN-like network. I'd hesitate though to
eliminate a signaling confidentiality mode for SIP that has some
possibility of preventing pervasive metadata collection, even if we know
there are some environments where that protection will not be provided.
HTTPS is a nuisance in many highly mediated parts of the web, too.

Jon Peterson
Neustar, Inc.

On 6/13/16, 6:56 AM, "sipcore on behalf of Drage, Keith (Nokia - GB)"
<[email-masked] on behalf of [email-masked]> wrote:

>That option was clearly understood by the SIP WG when we did RFC 5630.
>However it was decided to very clearly state what it meant so that both
>service providers and users could decide whether to use it or not, and
>they still have that freedom. I suspect the majority have chosen not to,
>but the option is still there.
>
>Given that we spent so much time on providing RFC 5630 to update RFC 3261
>in this area, I am reluctant to change the direction now - this achieved
>IETF consensus.
>
>Keith
>
>P.S. I also take this opportunity to remember Francois Audet, who did
>such a lot of work driving this document to completion.
>

---

From: Richard Shockey <[email-masked]>
Date: Mon, 13 Jun 2016 16:23:15 -0400

On 6/13/16, 2:24 PM, "sipcore on behalf of Peterson, Jon" <[email-masked] on behalf of [email-masked]> wrote:

>SIPS is at best a nuisance. 

RS> That is an understatement.  SIPS is not used in virtually any component of the carrier based Public SIP Networks that rely on E.164 naming that I know of. Though it is specified as MUST support in the SIP Forum SIPConnect profiles for PBX to SP on the wire integration to my knowledge it has never been implemented by any vendor or SSP.  In short SIPS is a total Pain in the Ass.  Given the appalling track record the IETF has in designing implementable security protocols, I question whether this effort is worth the time.  But that’s OK ..if people want to tilt at windmills, be my guest.  What I want to know is does anyone really care? 

Its design optimized more for a trapezoid, or

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 14 Jun 2016 09:36:47 +0200

> On 13 Jun 2016, at 20:24, Peterson, Jon <[email-masked]> wrote:
> 
> 
I think we need to start with “what if we remove SIPS” and go back and
see what’s missing and how we can fix that. A lot of people point to SIPS as
the solution - but no one is implementing or using it. 

What is the problem it solves? Is there another way? What’s the status for 
S/MIME.

I don’t think we’ll find that the answer is SIPS: as a URI scheme, but the
SIP over TLS transport is still very much needed, discovered by NAPTR/SRV
and supported by DANE or some other PKI structure.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 14 Jun 2016 09:43:38 +0200

> On 13 Jun 2016, at 22:23, Richard Shockey <[email-masked]> wrote:
> 
> 

My point is that a lot of people falsely believe that SIPS: is the way to go for SIP security and do not do 
anything and certainly doesn’t even try to understand the complexity of SIPS:

We can start with removing SIPS: or start in the other end with SIP security. Media seems to be
the target of SIPBRANDY but my feeling is that SIP is an issue.

As stated many times, this was a problem we discovered hard at SIPit - where implementations registred
contacts using “;transport=TLS” and not using SIPS: - and did not have any client certificates.

It’s a mess and I feel that we need to clean this up in orders for developers to know where to go.

/O

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 14 Jun 2016 09:48:44 +0100

On 14 Jun 2016, at 8:43, Olle E. Johansson wrote:

> RS> That is an understatement.  SIPS is not used in virtually any 
> component of the carrier based Public SIP Networks that rely on E.164 
> naming that I know of. Though it is specified as MUST support in the 
> SIP Forum SIPConnect profiles for PBX to SP on the wire integration to 
> my knowledge it has never been implemented by any vendor or SSP.  In 
> short SIPS is a total Pain in the Ass.  Given the appalling track 
> record the IETF has in designing implementable security protocols, I 
> question whether this effort is worth the time.  But that’s OK ..if 
> people want to tilt at windmills, be my guest.  What I want to know is 
> does anyone really care?
>
>

SIPBRANDY will target SIP-signaled media. SIP security certainly matters 
for that. Whether or not the group has anything to say about SIPS is up 
to the group to decide.  (But my guess from the work so far is that the 
group will focus more on using STIR/4474bis to protect fingerprints, 
etc.)

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Jun 2016 08:48:59 +0000

Hi,

...

>I think we need to start with ³what if we remove SIPS² and go back and
>see what¹s missing and how we can fix that. A lot of people point to SIPS
>as
>What is the problem it solves? Is there another way? What¹s the status
>for 
>S/MIME.

Nobody does that either. And, it wouldn¹t guarantee anything either, would
it?

>I don¹t think we¹ll find that the answer is SIPS: as a URI scheme, but the

You can already do SIP over TLS using the SIP: scheme - just establish a
TLS connection and send your message :)

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 14 Jun 2016 11:03:31 +0200

> On 14 Jun 2016, at 10:48, Ben Campbell <[email-masked]> wrote:
> 
> 
> 
> SIPBRANDY will target SIP-signaled media. SIP security certainly matters for that. Whether or not the group has anything to say about SIPS is up to the group to decide.  (But my guess from the work so far is that the group will focus more on using STIR/4474bis to protect fingerprints, etc.)
That was my guess too :-)

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 14 Jun 2016 11:05:01 +0200

> On 14 Jun 2016, at 10:48, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> ...
> 
Well, it would get end2end security - but no one has thought about b2bua’s
and all those middleboxes in that scenario. 
Right, I have only seen a bit of code in resiprocate but no usage.
> TLS connection and send your message :)
Right. But the problem is getting the inbound request. Only Outbound solves
that and no one wants outbound right?
So that puts us back to my other proposal about half-outbound.

/O

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 14 Jun 2016 15:51:11 +0000

ON: 13 June 2016 Richard Shockey 

> Though it is specified as MUST support in the
> short SIPS is a total Pain in the Ass

SIPS is actually not required by SIPconnect although TLS is a MUST requirement hence the confusion.

Whenever I have seen SIPS used it has resulted in some kind of bug report being generated and I have to say I have not heard of it being used for some time.  It needs to deprecated and the use of TLS clarified.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 14 Jun 2016 15:57:47 +0000

> So that puts us back to my other proposal about half-outbound.

Agreed we discussed this a lot in the SIPconnect2.0 work clearly there are lots of SIP over TLS implementations but actually there is no RFC that actually described what these implementations are doing. The half-outbound looks like a workable solution that would could fix that.

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Tue, 14 Jun 2016 16:04:02 +0000

Please confirm whether RFC 5630 (including annex A) is clear in this respect or not, and be specific about where it is not. You should not be implementing RFC 3261 without also implementing RFC 5630, as one updates the other.

As far as I am concerned, that document is clear about what is needed to support SIPS, and what is needed to support transport=TLS.

The use of SIPS should not generate a bug report, because it is not an error. You may need to reject the call because you cannot support the capability, but that is no different to many other reasons for rejection.

We do not normally deprecate RFCs just because people have failed to read the document, of failed to provide their implementations in conformance with the document, or even just failed to implement a particular capability.

If you don't want to support SIPS, then fine, that is an acceptable position, but you need more evidence to tell the world not to use it.

Keith

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: 14 June 2016 16:51
To: Richard Shockey; Peterson, Jon; Drage, Keith (Nokia - GB); DOLLY, MARTIN C; Paul Kyzivat
Cc: [email-masked]
Subject: RE: [sipcore] SIPS must die, die, die

> Though it is specified as MUST support in the SIP Forum SIPConnect 
> profiles for PBX to SP on the wire integration to my knowledge it has 
> never been implemented by any vendor or SSP.  In short SIPS is a total 
> Pain in the Ass

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 14 Jun 2016 12:09:19 -0400

I am with Keith here.
There is no problem with the SIPS recommendations as defined in the RFC, so
I am not sure on what basis we would deprecate that.
If you do not like it, do not implement it.

Regards,
 Rifaat

On Tue, Jun 14, 2016 at 12:04 PM, Drage, Keith (Nokia - GB) <
[email-masked]> wrote:

> Please confirm whether RFC 5630 (including annex A) is clear in this
> respect or not, and be specific about where it is not. You should not be
> implementing RFC 3261 without also implementing RFC 5630, as one updates
> the other.
>
> As far as I am concerned, that document is clear about what is needed to
> support SIPS, and what is needed to support transport=TLS.
>
> The use of SIPS should not generate a bug report, because it is not an
> error. You may need to reject the call because you cannot support the
> capability, but that is no different to many other reasons for rejection.
>
> We do not normally deprecate RFCs just because people have failed to read
> the document, of failed to provide their implementations in conformance
> with the document, or even just failed to implement a particular capability.
>
> If you don't want to support SIPS, then fine, that is an acceptable
> position, but you need more evidence to tell the world not to use it.
>
> Keith
>
> Whenever I have seen SIPS used it has resulted in some kind of bug report
> being generated and I have to say I have not heard of it being used for
> some time.  It needs to deprecated and the use of TLS clarified.
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 14 Jun 2016 16:26:36 +0000

Ok my statement regarding deprecation was probably a bit rash and maybe SIPS as specified in RFC 5630 could be made to work but at least in the SIP Trunking world I don’t think anybody has implemented it this way as the SIP trunking transport is hard wired and SIPS is not useful.

Andy

From: Rifaat Shekh-Yusef [mailto:[email-masked]]
Sent: 14 June 2016 17:09
To: Drage, Keith (Nokia - GB)
Cc: [email-masked]; Hutton, Andrew
Subject: Re: [sipcore] SIPS must die, die, die

I am with Keith here.
There is no problem with the SIPS recommendations as defined in the RFC, so I am not sure on what basis we would deprecate that.
If you do not like it, do not implement it.

Regards,
 Rifaat

On Tue, Jun 14, 2016 at 12:04 PM, Drage, Keith (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:
Please confirm whether RFC 5630 (including annex A) is clear in this respect or not, and be specific about where it is not. You should not be implementing RFC 3261 without also implementing RFC 5630, as one updates the other.

Keith

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 14 June 2016 16:51
To: Richard Shockey; Peterson, Jon; Drage, Keith (Nokia - GB); DOLLY, MARTIN C; Paul Kyzivat
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [sipcore] SIPS must die, die, die

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jun 2016 12:37:33 -0400

> As far as I am concerned, that document is clear about what is needed to support SIPS, and what is needed to support transport=TLS.

I just looked at it.

An area that I would be concerned with is in topologies including SBCs. 
They aren't explicitly addressed, but that isn't surprising since almost 
none of the sip specs do. They do seem to be covered by section 5.1.1.3 
on Derived Dialogs. But I don't know if those implementing or deploying 
SBCs would agree on that. If somebody doesn't think this applies to 
SBCs, they they might be treated as a "get out of jail free" card to 
stop using TLS.

Another possible concern is calls that transition from SIPS to some 
non-SIP protocol. E.g., is it permissible to terminate a SIPS call on a 
PSTN gateway? I can't find anything in 5630 that considers these. On one 
had, I might really want the SIPS level security all the way to the 
gateway. On the other hand, if that works I might be deluded in thinking 
I have more security than is delivered by the PSTN.

> If you don't want to support SIPS, then fine, that is an acceptable position, but you need more evidence to tell the world not to use it.

I have mixed feelings about this. ISTM the main problem is that you 
can't accurately claim that you support 3261 unless you build in code 
paths to support SIPS. But you are free to restrict your code to 
deployments that don't *use* SIPS. You might not ever test the SIPS 
paths (or even have a way to test them). What is the point of this?

And if you are building UAC that connects via registration you will 
never be able to use SIPS unless you also implement and use Outbound. 
But Outbound support is optional.

Perhaps the answer is to remove the mandatory to implement aspect of SIPS.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 14 Jun 2016 18:39:36 +0200

> On 14 Jun 2016, at 18:04, Drage, Keith (Nokia - GB) <[email-masked]> wrote:
> 
Yes, it points clearly to SIP Outbound (RFC 5626). Which also has very few implementations.
As an alternative it points to use of SIP client certs - which I can’t find any clear specification of.

> The use of SIPS should not generate a bug report, because it is not an error. You may need to reject the call because you cannot support the capability, but that is no different to many other reaso…
Agree.

> If you don't want to support SIPS, then fine, that is an acceptable position, but you need more evidence to tell the world not to use it.
I think the fact that it still there blocks usage of TLS. But let’s focus on proper use of TLS and how we can help that, because it seems
like most people agree we need to look into that again.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 14 Jun 2016 18:41:38 +0200

> On 14 Jun 2016, at 18:37, Paul Kyzivat <[email-masked]> wrote:
> 
> An area that I would be concerned with is in topologies including SBCs. They aren't explicitly addressed, but that isn't surprising since almost none of the sip specs do. They do seem to be covered by section 5.1.1.3 on Derived Dialogs. But I don't know if those implementing or deploying SBCs would agree on that. If somebody doesn't think this applies to SBCs, they they might be treated as a "get out of jail free" card to stop using TLS.
> 
> Another possible concern is calls that transition from SIPS to some non-SIP protocol. E.g., is it permissible to terminate a SIPS call on a PSTN gateway? I can't find anything in 5630 that considers these. On one had, I might really want the SIPS level security all the way to the gateway. On the other hand, if that works I might be deluded in thinking I have more security than is delivered by the PSTN.
> 
> I have mixed feelings about this. ISTM the main problem is that you can't accurately claim that you support 3261 unless you build in code paths to support SIPS. But you are free to restrict your code to deployments that don't *use* SIPS. You might not ever test the SIPS paths (or even have a way to test them). What is the point of this?
That’s a good point. If we remove SIPS: it’s no longer part of any requirements.
> 
> And if you are building UAC that connects via registration you will never be able to use SIPS unless you also implement and use Outbound. But Outbound support is optional.
Well, the option is client certs) and mutual TLS auth, also discussed (and dismissed…) in 5630  ;-)
> Perhaps the answer is to remove the mandatory to implement aspect of SIPS.
Yes.

/O

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 14 Jun 2016 16:48:06 +0000

The goal of sips is that you get a session established that has TLS end to end, hop by hop, or you don’t get a session established.

That seems to me to be a worthy goal, although it would be acceptable to just know if each hop was TLS protected.

Asking for TLS is nice, knowing it’s happened is much better.  Yes, lying is always possible.

If we deprecate SIPS, what do we replace it with that gets us some knowledge of TLS in every hop?

I’m generally not in favor of deprecating a useful capability just because implementations are lacking.  If it doesn’t work, that’s one thing. If implementors chose not to do it, and didn’t provide an effective alternative, then I have some hope they will figure it out, usually when something goes horribly wrong.

Brian
> On Jun 14, 2016, at 12:41 PM, Olle E. Johansson <[email-masked]> wrote:
> 
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 14 Jun 2016 17:29:24 +0000

Just to add a bit to what Brian said...

>the solution - but no one is implementing or using it.

Ostensibly what would be missing is a mechanism for user agents to
indicate that any intermediaries handling their request should only
forward it with hop-by-hop confidentiality and integrity protections. And
for SIP resources to indicate their preference to be reached in this
fashion.

> 
>What is the problem it solves?

Pervasive eavesdropping?

> Is there another way?

Maybe.

>What¹s the status for S/MIME.
>

If your intention is that we should replace SIPS with something that
provides a stronger assurance of hop-by-hop signaling confidentiality,
then great, let's specify that stronger mechanism first and then we'll
deprecate SIPS in favor of it. If the process is instead, let's deprecate
SIPS and then hope we can invent something else to address pervasive
eavesdropping later, I would probably say that's unacceptable, provided we
think there are any deployment environments in which SIPS could work as
advertised. And yes, I'm aware there are deployment environments in which
it is just a nuisance, but coincidentally, those are also deployment
environments that are not overly concerned with pervasive eavesdropping.

Again, discovering via NAPTR/SRV that the resource wants to be reached
over TLS was one of the primary functions for which SIPS was devised. I'm
not sure how different anything we come up along those lines would
realistically be from what's already in RFC3263.

Jon Peterson
Neustar, Inc.

---

From: "Neelakantan, Neel" <[email-masked]>
Date: Tue, 14 Jun 2016 17:57:15 +0000

> Sent: Tuesday, June 14, 2016 11:42 AM
> To: Paul Kyzivat <[email-masked]>
> Cc: [email-masked]; Olle E Johansson <[email-masked]>
> > An area that I would be concerned with is in topologies including SBCs. They
> aren't explicitly addressed, but that isn't surprising since almost none of the
> sip specs do. They do seem to be covered by section 5.1.1.3 on Derived
> Dialogs. But I don't know if those implementing or deploying SBCs would
> agree on that. If somebody doesn't think this applies to SBCs, they they
> might be treated as a "get out of jail free" card to stop using TLS.
> >
> > Another possible concern is calls that transition from SIPS to some non-SIP
> protocol. E.g., is it permissible to terminate a SIPS call on a PSTN gateway? I
> can't find anything in 5630 that considers these. On one had, I might really
> want the SIPS level security all the way to the gateway. On the other hand, if
> that works I might be deluded in thinking I have more security than is
> delivered by the PSTN.
> >
> >> We do not normally deprecate RFCs just because people have failed to
> read the document, of failed to provide their implementations in
> conformance with the document, or even just failed to implement a
> particular capability.
> >>
> >> If you don't want to support SIPS, then fine, that is an acceptable position,
> but you need more evidence to tell the world not to use it.
> >
> > I have mixed feelings about this. ISTM the main problem is that you can't
> accurately claim that you support 3261 unless you build in code paths to
> support SIPS. But you are free to restrict your code to deployments that
> don't *use* SIPS. You might not ever test the SIPS paths (or even have a way
> to test them). What is the point of this?
> > And if you are building UAC that connects via registration you will never be
> able to use SIPS unless you also implement and use Outbound. But
> Outbound support is optional.

 [[Neel]] That still does not solve the problems of NAT/Firewalls right?  Agreed they are tangential, but we need to look at overall reality of deployment.

> >>> profiles for PBX to SP on the wire integration to my knowledge it
> >>> has never been implemented by any vendor or SSP.  In short SIPS is a
> >>> total Pain in the Ass
> >>
> >> Whenever I have seen SIPS used it has resulted in some kind of bug
> report being generated and I have to say I have not heard of it being used for

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jun 2016 16:04:43 -0400

> for SIP resources to indicate their preference to be reached in this

What is the point of the hop-by-hop protections in this context? Do we 
really need it? Won't STIR and SIPBRANDY provide what is needed without it?

>> What is the problem it solves?

Since hop-by-hop presumes that all the intermediaries are trusted, and 
this rarely seems like a good assumption for preventing pervasive 
eavesdropping, maybe it isn't worth the trouble.

	Thanks,
	Paul

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 14 Jun 2016 20:45:22 +0000

The threat of pervasively monitoring signaling is basically metadata
collection - seeing who called whom at what time, and so on. Neither STIR
nor SIPBRANDY explicitly addresses that. If the attacker can compromise
intermediaries, or otherwise persuade them to yield logs of the signaling,
then agreed SIPS would add little value. But that is far harder to arrange
than just snooping on cleartext traffic over the wire.

I do think it's a different threat, and it requires different
countermeasures. Those countermeasures will not be universally available,
but forcing SIP over TLS as much as possible still would make life harder
for these passive attackers.

Jon Peterson
Neustar, Inc.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jun 2016 21:58:45 -0400

> for these passive attackers.

Agreed, but that can be achieved simply by getting TLS to be the default.

That might be an easier thing to sell if we can get SIP over DTLS defined.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 15 Jun 2016 07:21:50 +0200

> On 14 Jun 2016, at 22:45, Peterson, Jon <[email-masked]> wrote:
> 
> 
Thank you Jon! 

That’s exactly what I want to do by making implementing
TLS in SIP more straightforward, better documented and easier to test.
I do believe the SIPS: uri scheme has been a hindrance and by removing it
(or just discussing what will happen if we remove it) we will focus on the
right things to make both SIP over TLS in a secure context and SIP over 
TLS in opportunistic mode more of a default than it is now.

We’ve come far in the specification of SIPconnect 2.0 (work in progress)
but identified a few issues that needs to be solved in the IETF.
One is the “half-outbound” and another is how to live without “;transport=tls”.

I’m trying to summarize my view of the discussion about SIPS: and some
of the areas I think we need to look at in a separate document.

/O