Subject: Re: [dispatch] SIPBRANDY and other dangers

From: "Ben Campbell" <[email-masked]>
Date: Mon, 06 Jun 2016 15:25:41 -0500

Since no one complained, and a few people expressed support directly to 
me offline, I added that text to the proposed charter, along with adding 
RTCWEB to the list of groups in the "expected to coordinate with" 
paragraph.

I will put this on the agenda for internal review on the next IESG 
telechat. That should not shut down discussion, so if people have 
further thoughts, please comment as soon as possible.

Thanks!

Ben.

On 26 May 2016, at 19:55, Ben Campbell wrote:

> Hi Jon,
>
> As an individual, I'm afraid the association of this effort with other 
> great unsolved problems (Great Unsolved Theories?) may be prophetic. 
> (Also, the implied acronym :-) ) I'd be happy if we just solved e2e 
> confidentiality. And I don't think we would be happy if we solved all 
> the other things and _not_ e2e confidentiality.
>
> It also seems to me that aligning identity models fits more with STIR 
> than with this group.
>
> That being said, what about something like the following:
>
> "While confidentiality is the first priority of the working group, it 
> may work on aligning these practices with WebRTC, for example by 
> defining best practices for ensuring recipients of media flows have 
> consented to receive such flows, in order to prevent or mitigate the 
> denial-of-service attack described in RFC 5245, section 18.5.1."
>
> Ben.
>
> On 26 May 2016, at 19:05, Peterson, Jon wrote:
>
>> It would be a fairly significant change to the proposed scope, but 
>> perhaps
>> one that's warranted.
>>
>> I understand why you have some process caution here about scoping a
>> consent mechanism to ICE at the outset, but if we're going to put 
>> this
>> problem under SIPPRANDY's umbrella, I think it could make sense to 
>> set the
>> explicit goal of getting a "grand unified theory" of VoIP security 
>> that
>> would align the security of SIP and WebRTC. As we all know, WebRTC 
>> went
>> down many of the paths that it did for the sake of backwards 
>> compatibility
>> with SIP, and it would be a shame if the effort to interwork the two
>> proved futile because of lack of e2e SRTP. Consent would be another 
>> prong
>> of that. So maybe writing ICE in as a foregone conclusion in the 
>> service
>> of that goal would let us skip some unnecessary deliberation. Getting
>> plausible interworking with WebRTC could also provide some further
>> incentive for implementers to crack open their SIP implementations.
>>
>> If a "grand unified theory" is the goal, then this also conforms 
>> nicely
>> with Cullen's recent efforts to figure out how to get STIR and 
>> WebRTC's
>> IdP aligned. As my strawman proposal for SIP media confidentiality 
>> had
>> both a STIR story and an opportunistic story, we could argue that 
>> getting
>> alignment of identity, consent, and encryption could be grouped under 
>> one
>> effort, which is mostly about getting offer/answer to deal with those
>> three things in a common way - especially as WebRTC IdP today conveys 
>> that
>> identity information as an SDP attribute.
>>
>> Realigning Offers[/Answers]: The Grand Unified Theory?
>>
>> Jon Peterson
>> Neustar, Inc.
>>
>> On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach"
>> <[email-masked] on behalf of [email-masked]> wrote:
>>
>>> As early as 2005, we identified a class of DoS attack that would be
>>> enabled by SIP systems, if widely deployed on the public internet.
>>> Called the "Voice Hammer," this attack involves triggering 
>>> potentially
>>> vast quantities of media traffic towards a target using normal SIP 
>>> call
>>> setup procedures.
>>>
>>> While I don't think this is something that SIPBRANDY is required to
>>> address, I would like it to be part of the discussion. I believe 
>>> this
>>> makes sense for two reasons: (1) I expect the recommendations that 
>>> come
>>> out of SIPBRANDY to require non-trivial endpoint changes, and it 
>>> would
>>> be good to consider coupling breaking changes to each other so as to
>>> minimize the number of potential modes of operation; and (2) the 
>>> issue
>>> is fundamentally a security issue -- albeit of a different nature --
>>> which would seem to require the same set of expertise as the other
>>> problems SIPBRANDY will work on.
>>>
>>> To that end, I propose adding the following sentence to the 
>>> "Objectives"
>>> paragraph in the SIPBRANDY charter:
>>>
>>> "The working group may also define best practices for ensuring
>>> recipients of media flows have consented to receive such flows, in 
>>> order
>>> to prevent or mitigate the denial-of-service attack described in RFC
>>> 5245, section 18.5.1."
>>>
>>> To be clear: I do not wish to presuppose that the solution to this
>>> problem will be ICE, or that it even is required in order for the WG 
>>> to
>>> declare success. I just want it to be available for consideration.
>>>
>>> /a
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 06 Jun 2016 15:27:05 -0500

The most recent proposed text is at 
https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ .

Ben.

On 6 Jun 2016, at 15:25, Ben Campbell wrote:

> Since no one complained, and a few people expressed support directly 
> to me offline, I added that text to the proposed charter, along with 
> adding RTCWEB to the list of groups in the "expected to coordinate 
> with" paragraph.
>
>> As an individual, I'm afraid the association of this effort with 
>> other great unsolved problems (Great Unsolved Theories?) may be 
>> prophetic. (Also, the implied acronym :-) ) I'd be happy if we just 
>> solved e2e confidentiality. And I don't think we would be happy if we 
>> solved all the other things and _not_ e2e confidentiality.
>>
>>> alignment of identity, consent, and encryption could be grouped 
>>> under one
>>> three things in a common way - especially as WebRTC IdP today 
>>> conveys that
>>>> problem will be ICE, or that it even is required in order for the 
>>>> WG to

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 7 Jun 2016 06:42:44 +0000

FWIW, I would like to say that I concur with your statement "I'd be happy if we just solved e2e confidentiality. And I don't think we would be happy if we solved all the other things and not e2e confidentiality." And hope that other targets won't jeopardize reaching the main goal.

Thanks,
Tolga

From: dispatch [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: Monday, June 06, 2016 4:27 PM
To: [email-masked]
Subject: Re: [dispatch] SIPBRANDY and other dangers

The most recent proposed text is at https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ .

Ben.

Since no one complained, and a few people expressed support directly to me offline, I added that text to the proposed charter, along with adding RTCWEB to the list of groups in the "expected to coordinate with" paragraph.

I will put this on the agenda for internal review on the next IESG telechat. That should not shut down discussion, so if people have further thoughts, please comment as soon as possible.

Thanks!

Ben.

Hi Jon,

As an individual, I'm afraid the association of this effort with other great unsolved problems (Great Unsolved Theories?) may be prophetic. (Also, the implied acronym :-) ) I'd be happy if we just solved e2e confidentiality. And I don't think we would be happy if we solved all the other things and not e2e confidentiality.

It also seems to me that aligning identity models fits more with STIR than with this group.

"While confidentiality is the first priority of the working group, it may work on aligning these practices with WebRTC, for example by defining best practices for ensuring recipients of media flows have consented to receive such flows, in order to prevent or mitigate the denial-of-service attack described in RFC 5245, section 18.5.1."

Ben.

It would be a fairly significant change to the proposed scope, but perhaps
one that's warranted.

I understand why you have some process caution here about scoping a
consent mechanism to ICE at the outset, but if we're going to put this
problem under SIPPRANDY's umbrella, I think it could make sense to set the
explicit goal of getting a "grand unified theory" of VoIP security that
would align the security of SIP and WebRTC. As we all know, WebRTC went
down many of the paths that it did for the sake of backwards compatibility
with SIP, and it would be a shame if the effort to interwork the two
proved futile because of lack of e2e SRTP. Consent would be another prong
of that. So maybe writing ICE in as a foregone conclusion in the service
of that goal would let us skip some unnecessary deliberation. Getting
plausible interworking with WebRTC could also provide some further
incentive for implementers to crack open their SIP implementations.

If a "grand unified theory" is the goal, then this also conforms nicely
with Cullen's recent efforts to figure out how to get STIR and WebRTC's
IdP aligned. As my strawman proposal for SIP media confidentiality had
both a STIR story and an opportunistic story, we could argue that getting
alignment of identity, consent, and encryption could be grouped under one
effort, which is mostly about getting offer/answer to deal with those
three things in a common way - especially as WebRTC IdP today conveys that
identity information as an SDP attribute.

Jon Peterson
Neustar, Inc.

On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach"
<[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:

As early as 2005, we identified a class of DoS attack that would be
enabled by SIP systems, if widely deployed on the public internet.
Called the "Voice Hammer," this attack involves triggering potentially
vast quantities of media traffic towards a target using normal SIP call
setup procedures.

While I don't think this is something that SIPBRANDY is required to
address, I would like it to be part of the discussion. I believe this
makes sense for two reasons: (1) I expect the recommendations that come
out of SIPBRANDY to require non-trivial endpoint changes, and it would
be good to consider coupling breaking changes to each other so as to
minimize the number of potential modes of operation; and (2) the issue
is fundamentally a security issue -- albeit of a different nature --
which would seem to require the same set of expertise as the other
problems SIPBRANDY will work on.

To that end, I propose adding the following sentence to the "Objectives"
paragraph in the SIPBRANDY charter:

"The working group may also define best practices for ensuring
recipients of media flows have consented to receive such flows, in order
to prevent or mitigate the denial-of-service attack described in RFC
5245, section 18.5.1."

To be clear: I do not wish to presuppose that the solution to this
problem will be ICE, or that it even is required in order for the WG to
declare success. I just want it to be available for consideration.

/a

________________________________

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

________________________________

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

________________________________

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

________________________________

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

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 08 Jun 2016 10:11:46 -0500

On 7 Jun 2016, at 1:42, Asveren, Tolga wrote:

> FWIW, I would like to say that I concur with your statement "I'd be 
> happy if we just solved e2e confidentiality. And I don't think we 
> would be happy if we solved all the other things and not e2e 
> confidentiality." And hope that other targets won't jeopardize 
> reaching the main goal.

I have hopes that the mention of that work having priority, along with 
the chair and AD attention, will mitigate that risk.

Ben.

> the other things and not e2e confidentiality.
>
> <[email-masked] on behalf of 
> [email-masked]<mailto:[email-masked][email-masked]>> 
> wrote:
>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 08 Jun 2016 15:07:59 -0500

I just made a minor update to say that SIPBRANDY may consider 
compatibility with aspects of PERC, and added PERC to the collaboration 
list. This is in response to some offline comments.

I invite comments (still to dispatch) about whether we should include 
that addition, or if we need any stronger requirements in that area.

Thanks!

Ben.

On 6 Jun 2016, at 15:27, Ben Campbell wrote:

>>> solved e2e confidentiality. And I don't think we would be happy if 
>>> we solved all the other things and _not_ e2e confidentiality.
>>>
>>> "While confidentiality is the first priority of the working group, 
>>> it may work on aligning these practices with WebRTC, for example by

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Jun 2016 20:14:47 +0000

Hi,

Since intermediaries are listed as one problem for achieving end-to-end SRTP, would it be useful to reference RFC 7879 as one input for the work?

Regards,

Christer

Sent: 08 June 2016 23:08

I just made a minor update to say that SIPBRANDY may consider compatibility with aspects of PERC, and added PERC to the collaboration list. This is in response to some offline comments.

I invite comments (still to dispatch) about whether we should include that addition, or if we need any stronger requirements in that area.

Thanks!

Ben.

Ben.

Thanks!

Ben.

Hi Jon,

Ben.

Jon Peterson
Neustar, Inc.

/a

dispatch mailing list

dispatch mailing list

dispatch mailing list

dispatch mailing list

dispatch mailing list

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 08 Jun 2016 15:25:46 -0500

On 8 Jun 2016, at 15:14, Christer Holmberg wrote:

> Hi,
>  
> Since intermediaries are listed as one problem for achieving 
> end-to-end SRTP, would it be useful to reference RFC 7879 as one input 
> for the work?
>  

I am of a mixed mind on that, since RFC 7879 mainly gives guidance to 
b2bua implementers on how not to break things. OTOH, it may make sense 
for SIPBRANDY to make assumptions about intermediaries adhering to that 
guidance.

Also, not specifically mentioning an RFC doesn't _prevent_ the working 
group from thinking about it if it makes sense.

Does anyone else have thought on this?

Thanks!

Ben.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 8 Jun 2016 15:14:17 -0700

> On Jun 8, 2016, at 1:25 PM, Ben Campbell <[email-masked]> wrote:
> 
> I am of a mixed mind on that, since RFC 7879 mainly gives guidance to b2bua implementers on how not to break things. OTOH, it may make sense for SIPBRANDY to make assumptions about intermediaries adhering to that guidance.
> 
> Also, not specifically mentioning an RFC doesn't prevent the working group from thinking about it if it makes sense.
> 
> 

Right. For that reason I don’t think an explicit mention is necessary.

Alissa

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 9 Jun 2016 10:17:16 +0000

The updated charter states "the WG may consider compatibility with aspects of PERC" but does not give any further guidance as to why this might be necessary unlike the text in the same paragraph referring to WebRTC and MMUSIC which does give some reasons why some consideration might be needed.

In the case of PERC I think it is important to note that a SIP endpoint must be able to negotiate using SDP offer/answer either a two party (SIPBrandy) or a multi-party session (PERC) without prior knowledge of which one will be used.  I think it would be useful to have this in the charter to make it clear, any other views on this?

Regards
Andy

Sent: 08 June 2016 21:08

Thanks!

Ben.

Ben.

Thanks!

Ben.

Hi Jon,

Ben.

Jon Peterson
Neustar, Inc.

/a

dispatch mailing list

dispatch mailing list

dispatch mailing list

dispatch mailing list

dispatch mailing list

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 09 Jun 2016 15:37:47 -0500

On 9 Jun 2016, at 5:17, Hutton, Andrew wrote:

> The upda
> ted charter states "the WG may consider compatibility with aspects of 
> PERC" but does not give any further guidance as to why this might be 
> necessary unlike the text in the same paragraph referring to WebRTC 
> and MMUSIC which does give some reasons why some consideration might 
> be needed.
>
> In the case of PERC I think it is important to note that a SIP 
> endpoint must be able to negotiate using SDP offer/answer either a two 
> party (SIPBrandy) or a multi-party session (PERC) without prior 
> knowledge of which one will be used.  I think it would be useful to 
> have this in the charter to make it clear, any other views on this?

Speaking as an individual, I don't think that requirement belongs in the 
charter. I'd rather leave it to the working group to do the right thing, 
and I'm not convinced we know for sure what that right thing is at this 
point in the process. I think there's a real risk of over constraining 
things if we are not careful.

If others have an opinion, please speak up asap.

Thanks!

Ben.

> compatibility with aspects of PERC, and added PERC to the 
> collaboration list. This is in response to some offline comments.
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 10 Jun 2016 09:47:15 +0000

My concern is that we have one group looking at SIP media security for multi-party sessions (PERC) and another looking at SIP media security for two party sessions (SIPBRANDY) and neither of the WG charters state that the work needs to be coordinated.

It might be obvious that they will be coordinated and that the same people will probably work on both and I assume that everybody would be sad if they came up with incompatible solutions but personally I think it would be good for the charter to say something about this.  However if I am alone on this and we want to leave it to the working groups to work it out then I can live with that.

Regards
Andy

From: Ben Campbell [mailto:[email-masked]]
Sent: 09 June 2016 21:38
To: Hutton, Andrew
Cc: [email-masked]
Subject: Re: [dispatch] SIPBRANDY and other dangers

The upda
ted charter states "the WG may consider compatibility with aspects of PERC" but does not give any further guidance as to why this might be necessary unlike the text in the same paragraph referring to WebRTC and MMUSIC which does give some reasons why some consideration might be needed.

Speaking as an individual, I don't think that requirement belongs in the charter. I'd rather leave it to the working group to do the right thing, and I'm not convinced we know for sure what that right thing is at this point in the process. I think there's a real risk of over constraining things if we are not careful.

Thanks!

Ben.

Regards
Andy

From: dispatch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ben Campbell
Sent: 08 June 2016 21:08
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dispatch] SIPBRANDY and other dangers

Thanks!

Ben.

Ben.

Thanks!

Ben.

Hi Jon,

Ben.

Jon Peterson
Neustar, Inc.

On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach"
<[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]<mailto:[email-masked][email-masked]%3cmailto:[email-masked][email-masked]>>> wrote:

/a

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

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

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

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

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

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 13 Jun 2016 14:33:05 +0100

The latest revision of the proposed SIPBRANDY charter includes PERC in 
the list of groups to be coordinated with. Is that insufficient? (It 
seems like overkill to revise the PERC charter just to mention 
coordination with SIPBRANDY).

Ben.

On 10 Jun 2016, at 10:47, Hutton, Andrew wrote:

> My concern is that we have one group looking at SIP media security for 
> multi-party sessions (PERC) and another looking at SIP media security 
> for two party sessions (SIPBRANDY) and neither of the WG charters 
> state that the work needs to be coordinated.
>
> It might be obvious that they will be coordinated and that the same 
> people will probably work on both and I assume that everybody would be 
> sad if they came up with incompatible solutions but personally I think 
> it would be good for the charter to say something about this.  However 
> if I am alone on this and we want to leave it to the working groups to 
> work it out then I can live with that.
>
> Regards
> Andy
>
>
>
> Speaking as an individual, I don't think that requirement belongs in 
> the charter. I'd rather leave it to the working group to do the right 
> thing, and I'm not convinced we know for sure what that right thing is 
> at this point in the process. I think there's a real risk of over 
> constraining things if we are not careful.
>
> From: dispatch 
> [mailto:[email-masked]<mailto:[email-masked]>] 
> On Behalf Of Ben Campbell
> Sent: 08 June 2016 21:08
> [email-masked]<mailto:[email-masked][email-masked]<mailto:[email-masked][email-masked]%3cmailto:[email-masked][email-masked]>>> 
> wrote:
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 13 Jun 2016 17:07:54 +0000

I'd like to think this would be sufficient. At a high level I agree that
the best practices for media confidentiality in SIP should take into
account any standards we've developed that facilitate end-to-end
confidentiality through various kinds of media intermediaries, including
conference bridges. But in terms of the charter, I don't think it needs
anything more than a requirement for coordination between the groups.

Jon Peterson
Neustar, Inc.

On 6/13/16, 6:33 AM, "dispatch on behalf of Ben Campbell"
<[email-masked] on behalf of [email-masked]> wrote:

>>[email-masked]<mailto:[email-masked]%20on%20behalf%20of%20ad
>>[email-masked]<mailto:[email-masked]%20on%20behalf%20of%20adam
>>@nostrum.com%3cmailto:[email-masked]%20on%20behalf%20of%20adam
>>@nostrum.com>>> 
>> wrote:
>>