Subject: Re: [straw] Alissa Cooper's Discuss on draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Sat, 19 Mar 2016 05:35:09 -0700

I took a look at the latest version of this document. It has definitely improved, but I still find it problematic in a few ways.

= Sec 1.1 and 1.2 =

The language about the narrow case for which this document’s guidance is targeted is better. But I think it needs to emphasize just how much of a corner case this is. RFC 7362 recommends against latching, and address hiding is more often provided using TURN. Rather than saying things like "there are certain B2BUAs that are typically deployed for address hiding or media latching, as described in [RFC7362]” without any of that context, I would suggest something like “B2BUAs may be deployed for address hiding or media latching [RFC7362], although TURN is more often used for this purpose and media latching is not recommended due to its security properties.”

= Sec. 1.2 and 7 =

I still find it odd to say that various flavors of B2BUA are “outside the scope of this document” when in fact the document spends most of its words describing how those B2BUAs would not be expected to conform to its recommendations. Instead of saying that the specific types of implementations are “outside the scope of this document,” I would recommend saying that the recommendations made in the document are not expected to be applied by those types of B2BUAs given deployment reality.

= Sec 4 and 5 =

I gather that these sections are intended to explain which kinds of B2BUAs are expected to be able to comply with the recommendations in Sec 3 and how, which is good. I would recommend making that explicit in the section headings and the intro to each section. In particular, it’s not clear to me why the intro to Sec 4 talks about impact on DTLS-SRTP and the intro to Sec 5 (and the section titles) talk about handling of DTLS-SRTP. I thought the two sections were supposed to be giving parallel explanations for the different kinds of B2BUAs.

= Sec 5.1.1 =

Per the comment above, this text doesn’t make sense:

"A media relay B2BUA, as described in Section 3, forwards the
   certificate fingerprint and SDP setup attribute it receives from one
   endpoint unmodified towards the other endpoint and vice-versa.”

I thought Sec 3 was providing the recommended behavior, and Sec 5 was talking about how different kinds of B2BUAs have the ability to comply with those recommendations or not. This makes it sound like Sec 3 defines the behavior of media relay B2BUAs. 

Thanks,
Alissa

> On Jan 17, 2016, at 7:44 PM, Ram Mohan R (rmohanr) <[email-masked]> wrote:
> 
> Hi Ben,
> 
> We will publish a new revision in the next couple of weeks.
> 
> Regards,
> Ram
> 
> -----Original Message-----
> From: Ben Campbell <[email-masked]>
> Date: Friday, 15 January 2016 at 4:13 AM
> To: "[email-masked]"
> <[email-masked]>
> Cc: Cisco Employee <[email-masked]>, Alissa Cooper <[email-masked]>,
> "[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>, IESG <[email-masked]>, "[email-masked]"
> <[email-masked]>
> Subject: Re: [straw] Alissa Cooper's Discuss on
> draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT)
> 
>> Hi,
>> 
>> What's the status on an update?
>> 
>> Thanks!
>> 
>> Ben.
>> 
>> 
>> On 9 Dec 2015, at 14:25, Ben Campbell wrote:
>> 
>>> I had an offline discussion with Alissa and Barry yesterday. I think
>>> we have a proposed way forward to deal with the "big-picture" issues
>>> from Alissa's discuss. This does not necessarily cover every detail of
>>> her (or Stephen's) discuss and comments, but I think we need to deal
>>> with the existential stuff first.
>>> 
>>> The draft needs clarifications to the problem statement, the draft
>>> goals and scope, and a clearer separation between normative statements
>>> and non-normative considerations.
>>> 
>>> I think that would be easiest with some reorganization. Here's a
>>> proposed outline. (I don't think you need to stick to this outline in
>>> detail, as long as the points are clear)
>>> 
>>> Thanks!
>>> 
>>> Ben.
>>> ----------------
>>> 
>>> Problem:
>>> 
>>> - B2BUAs (especially SBCs) often make e2e dtls-srtp impossible. There
>>> are use cases where they could do their jobs and still allow e2e
>>> dtls-srtp.
>>> - The dtls-srtp dependency on RFC 4474 makes that hard in many cases.
>>> - What do we mean by e2e DTLS-SRTP? (I _think_ we mean from the
>>> perspective of the b2bua, where that b2bua is not a party to the
>>> DTLS-SRTP SA, and doesn't have the session key or private keys for
>>> DTLS cert(s).
>>> 
>>> Goals and Scope:
>>> 
>>> - Goal is to provide guidance on how b2buas that could possibly do
>>> their jobs without breaking e2e dtls-srtp to do so.
>>> - B2BUAs exist that will still not allow e2e dtls-srtp for various
>>> reasons. These are out-of-scope, and the draft should not attempt to
>>> make value judgements about them.
>>> - Termination of dtls-srtp at the b2bua is out of scope by definition
>>> (it's not e2e).
>>> 
>>> Normative rules for B2BUAs to allow e2e DTLS-SRTP:
>>> 
>>> - Consider both media signaling layers (including for non-media-path
>>> b2buas)
>>> - Discuss differences for 4474 and 4474bis, including how a b2bua
>>> might tell them apart.(Hopefully 4474 will be obsolete soon, but we
>>> should still discuss it, since it has significant impact on things
>>> like media-latching since it signs the entire SDP payload.)
>>> - Discuss differences if the b2bua acts as a 4474/4474bis
>>> authenticator and/or verifier.
>>> 
>>> Implications/considerations for each b2bua type (non-normative):
>>> 
>>> - How do the normative requirements in the previous sections impact
>>> the various b2bua types.
>>> 
>>> Normal security and privacy considerations.
>>> 
>>> 
>>> 
>>> On 9 Dec 2015, at 12:50, Alissa Cooper wrote:
>>> 
>>>>> On Dec 3, 2015, at 1:12 PM, Ben Campbell <[email-masked]> wrote:
>>>>> 
>>>>> On 2 Dec 2015, at 23:17, Alissa Cooper wrote:
>>>>> 
>>>>>> Could you articulate the reasons why someone would build a B2BUA
>>>>>> that
>>>>>>>>> follows the recommendations in this draft?
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> B2BUAs used in deployments like the above mentioned scenarios can
>>>>>>> use the
>>>>>>> recommendations in this draft.
>>>>>> 
>>>>>> 
>>>>>> Ok. What I am still missing is why this draft needs to be published
>>>>>> to make that happen. This is the type of SBC to which the Section
>>>>>> 3.1.1 guidance is directed. How does the behavior of existing
>>>>>> media-latching SBCs differ from what 3.1.1 tells them to do? And if
>>>>>> this type of SBC implementation is the key target audience,
>>>>>> doesn¹t that make the 3.1.2 guidance essentially no-ops?
>>>>> 
>>>>> Authors:
>>>>> 
>>>>> After discussion on today's telechats, and some side discussions
>>>>> with Alissa, I believe this question is the lynch-pin for making any
>>>>> progress. I advise people to work this out first before worrying
>>>>> about the rest of the discussion: Can we articulate how we expect
>>>>> this draft will change implementer and/or operator behavior?
>>>>> 
>>>>> Obviously B2BUAs that exist for reasons that require modification of
>>>>> RTP/RTCP, or cleartext access to the encrypted bits of SRTP are not
>>>>> going to conform, and are therefore out of scope. The draft doesn't
>>>>> seem to concern itself with b2buas that are not in the media path at
>>>>> all. (Maybe it should, since there are plenty of purely
>>>>> signaling-plane ways to break dtls-srtp?).
>>>>> 
>>>>> That leaves the question of b2buas in the media path that do not
>>>>> require modification or cleartext access to protected bits in
>>>>> srtp--effectively media-relays as described in 3.1.1 Do we believe
>>>>> people do not know how to build or use such devices without breaking
>>>>> dtls-srtp? Are people aware of such devices that break dtls-srtp
>>>>> when they don't need to? Perhaps by misconfiguration, or because
>>>>> they use SBCs designed for more invasive use cases?
>>>> 
>>>> As Ben says, I think this draft would add value if it could
>>>> articulate the problem statement, including the kinds of B2BUAs that
>>>> cause the problem, and then articulate a solution that those kinds of
>>>> B2BUAs have a reasonable chance of implementing given what they are
>>>> otherwise designed to do.
>>>> 
>>>> Alissa
>>>> 
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> Ben.
>>> 
>>> _______________________________________________
>>> straw mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/straw
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sun, 20 Mar 2016 16:18:09 +0000

Hi Alissa,

Thanks for your feedback. Please see inline

-----Original Message-----
From: Alissa Cooper <[email-masked]>
Date: Saturday, 19 March 2016 at 6:05 PM
To: Cisco Employee <[email-masked]>
Cc: Ben Campbell <[email-masked]>,
"[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>, IESG
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [straw] Alissa Cooper's Discuss on
draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT)

>I took a look at the latest version of this document. It has definitely
>improved, but I still find it problematic in a few ways.
>
>= Sec 1.1 and 1.2 =
>
>The language about the narrow case for which this document’s guidance is
>targeted is better. But I think it needs to emphasize just how much of a
>corner case this is. RFC 7362 recommends against latching, and address
>hiding is more often provided using TURN. Rather than saying things like
>"there are certain B2BUAs that are typically deployed for address hiding
>or media latching, as described in [RFC7362]” without any of that
>context, I would suggest something like “B2BUAs may be deployed for
>address hiding or media latching [RFC7362], although TURN is more often
>used for this purpose and media latching is not recommended due to its
>security properties.”

Ok. Will add the suggested text:

EXISTING:
However, there are certain B2BUAs
   that are typically deployed for address hiding or media latching, as
   described in [RFC7362], and such B2BUAs are able to perform their
   functions without requiring termination of DTLS-SRTP sessions i.e.
   these B2BUAs need not act as DTLS proxy and decrypt the RTP payload.

NEW:
B2BUAs may be deployed for address hiding or media latching [RFC7362],
although TURN is more often used for this purpose and media latching is not
recommended due to its security properties. Such B2BUAs are able to
perform their
functions without requiring termination of DTLS-SRTP sessions i.e.
these B2BUAs need not act as DTLS proxy and decrypt the RTP payload.

>
>= Sec. 1.2 and 7 =
>
>I still find it odd to say that various flavors of B2BUA are “outside the
>scope of this document” when in fact the document spends most of its
>words describing how those B2BUAs would not be expected to conform to its
>recommendations. Instead of saying that the specific types of
>implementations are “outside the scope of this document,” I would
>recommend saying that the recommendations made in the document are not
>expected to be applied by those types of B2BUAs given deployment reality.

EXISTING:
Those B2BUAs terminating DTLS-SRTP sessions are outside the
   scope of this document.

NEW:
The recommendations made in this document are not expected to be applied
by B2BUAs terminating DTLS-SRTP sessions given deployment reality.

>
>= Sec 4 and 5 =
>
>I gather that these sections are intended to explain which kinds of
>B2BUAs are expected to be able to comply with the recommendations in Sec
>3 and how, which is good. I would recommend making that explicit in the
>section headings and the intro to each section. In particular, it’s not
>clear to me why the intro to Sec 4 talks about impact on DTLS-SRTP and
>the intro to Sec 5 (and the section titles) talk about handling of
>DTLS-SRTP. I thought the two sections were supposed to be giving parallel
>explanations for the different kinds of B2BUAs.

I will do the following changes:
Titles for Section 4 - “Behavior of Signaling Plane B2BUAs”

Title for Section 5 - “ Behavior of Media Plane B2BUAs”

Section 4 intro text:
EXISTING:
Section 3.1 of [RFC7092] describes different categories of signaling
plane B2BUAs.  This section explains the impact these B2BUAs can have on
end-to-end DTLS-SRTP sessions.
NEW:
Section 3.1 of [RFC7092] describes different categories of signaling
plane B2BUAs.  This section explains how these B2BUAs are expected to
comply with the recommendations in Section 3

Section 5 intro text:
EXISTING:
This section describes the DTLS-SRTP handling by the different types
of media plane B2BUAs defined in [RFC7092].
NEW:
This section describes how the different types of media plane B2BUAs
defined in [RFC7092]
are expected to comply with the recommendations in Section 3

>   endpoint unmodified towards the other endpoint and vice-versa.”

NEW:

A media relay B2BUA follows the rule 1 mentioned in Section 3 and forwards
the certificate fingerprint and SDP setup attribute it receives from one
endpoint unmodified towards the other endpoint and vice-versa.

Regards,
Ram

>
>I thought Sec 3 was providing the recommended behavior, and Sec 5 was
>talking about how different kinds of B2BUAs have the ability to comply
>with those recommendations or not. This makes it sound like Sec 3 defines
>the behavior of media relay B2BUAs.
>
>Thanks,
>Alissa
>
>

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 21 Mar 2016 13:38:18 -0500

On 20 Mar 2016, at 11:18, Ram Mohan R (rmohanr) wrote:

[...]

> From: Alissa Cooper <[email-masked]>

[...]

> these B2BUAs need not act as DTLS proxy and decrypt the RTP payload.

I think the statement that TURN is more often used for media latching is 
at least somewhat aspirational. But I'm okay with that aspiration :-)

(The reality probably varies by market type and the "purpose" of the 
latching, but that sort of detail would only be a distraction here.)

Ben.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 22 Mar 2016 05:16:02 +0000

Hi Ben,

-----Original Message-----
From: Ben Campbell <[email-masked]>
Date: Tuesday, 22 March 2016 at 12:08 AM
To: Cisco Employee <[email-masked]>
Cc: Alissa Cooper <[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Re: [straw] Alissa Cooper's Discuss on
draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT)

>at least somewhat aspirational. But I'm okay with that aspiration :-)

:) Agree. There are more B2BUAs out there in field doing latching than
people using TURN.
But I think there is no harm in saying this way.

Ram

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Mar 2016 04:00:32 +0000

> From: straw [mailto:[email-masked]] On Behalf Of Ram Mohan R
> (rmohanr)
> Sent: Tuesday, March 22, 2016 10:46 AM
> To: Ben Campbell
> Cc: Alissa Cooper; [email-masked]; [email-masked]
> Subject: Re: [straw] Alissa Cooper's Discuss on draft-ietf-straw-b2bua-dtls-
> srtp-09: (with DISCUSS and COMMENT)
> 
> Hi Ben,
> 
> >>although TURN is more often used for this purpose and media latching
> >>is not recommended due to its security properties. Such B2BUAs are
> >>able to perform their functions without requiring termination of
> >>DTLS-SRTP sessions i.e.
> >I think the statement that TURN is more often used for media latching
> >is at least somewhat aspirational. But I'm okay with that aspiration
> >:-)
> 
> :) Agree. There are more B2BUAs out there in field doing latching than people
> using TURN.

How about the following text ?
B2BUAs may be deployed for address hiding or media latching [RFC7362], although endpoints can use ICE, only advertise the relayed candidate allocated by the TURN server for address privacy to the remote peer and avoid the security threats discussed in Section 5 of [RFC7362].

-Tiru

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 23 Mar 2016 00:44:08 -0500

On 22 Mar 2016, at 23:00, Tirumaleswar Reddy (tireddy) wrote:

> although endpoints can use ICE, only advertise the relayed candidate 
> allocated by the TURN server for address privacy to the remote peer 
> and avoid the security threats discussed in Section 5 of [RFC7362].
>

  My preference is the language that Ram and Alissa came up with 
(aspirational or otherwise.) Aspirational or not, I think we should make 
it clear that the IETF does not recommend SBC media latching and prefers 
TURN.

Ben.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Mar 2016 08:15:13 +0000

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, March 23, 2016 11:14 AM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Ram Mohan R (rmohanr); Alissa Cooper; [email-masked];
> [email-masked]
> >>>> B2BUAs may be deployed for address hiding or media latching
> >>>> [RFC7362], although TURN is more often used for this purpose and
> >>>> media latching is not recommended due to its security properties.
> >>>> Such B2BUAs are able to perform their functions without requiring
> >>>> termination of DTLS-SRTP sessions i.e.
> >>> I think the statement that TURN is more often used for media
> >>> latching is at least somewhat aspirational. But I'm okay with that
> >>> aspiration
> >>> :-)
> >>
> >> :) Agree. There are more B2BUAs out there in field doing latching
> >> than people using TURN.
> (aspirational or otherwise.) Aspirational or not, I think we should make it
> clear that the IETF does not recommend SBC media latching and prefers
> TURN.

Got it, but TURN has to be used with ICE.
NEW: 
B2BUAs may be deployed for address hiding or media latching [RFC7362], although TURN [RFC5766] with ICE [RFC5245] is recommended for this purpose and media latching is not recommended due to its security properties.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Mar 2016 10:12:46 -0400

> Got it, but TURN has to be used with ICE.

Why? It *can* be used with ICE, but it can also work without ICE. If you 
have reason to believe that TURN will be needed then you might not 
bother with ICE.

	Thanks,
	Paul

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 23 Mar 2016 09:34:21 -0500

On 23 Mar 2016, at 3:15, Tirumaleswar Reddy (tireddy) wrote:

>>> [RFC7362],

Sure, but it's not the point of this draft to teach the details of how 
to use TURN.

> although TURN [RFC5766] with ICE [RFC5245] is recommended for this 
> purpose and media latching is not recommended due to its security 
> properties.

I am okay with either this wording or Ram's.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Mar 2016 14:52:20 +0000

> From: straw [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Wednesday, March 23, 2016 7:43 PM
> To: [email-masked]
> >> (aspirational or otherwise.) Aspirational or not, I think we should
> >> make it clear that the IETF does not recommend SBC media latching and
> >> prefers TURN.
> >
> Why? It *can* be used with ICE, but it can also work without ICE. If you have
> reason to believe that TURN will be needed then you might not bother with
> ICE.

Yes, TURN can be used without ICE. But in the context of Security considerations discussed in https://tools.ietf.org/html/rfc7362#section-5, ICE is required to prove the identity of the peer before data is sent (though DTLS can also be used be used to prove the identity).

-Tiru

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 23 Mar 2016 10:00:25 -0500

On 23 Mar 2016, at 9:52, Tirumaleswar Reddy (tireddy) wrote:

> Yes, TURN can be used without ICE. But in the context of Security 
> considerations discussed in 
> https://tools.ietf.org/html/rfc7362#section-5, ICE is required to 
> prove the identity of the peer before data is sent (though DTLS can 
> also be used be used to prove the identity).

The draft in question is about dtls-srtp :-)

But again, I assert that the point here is not to teach the details of 
TURN and/or ICE. I don't think the draft needs to talk about when you do 
or do not need ICE.

Ben.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Mar 2016 15:01:48 +0000

> From: straw [mailto:[email-masked]] On Behalf Of Ben Campbell
> Sent: Wednesday, March 23, 2016 8:30 PM
> Cc: [email-masked]; Paul Kyzivat
> >> Why? It *can* be used with ICE, but it can also work without ICE. If
> >> you have reason to believe that TURN will be needed then you might
> >> not bother with ICE.
> >
> >
> But again, I assert that the point here is not to teach the details of TURN
> and/or ICE. I don't think the draft needs to talk about when you do or do not
> need ICE.

Agreed.

-Tiru

---

From: Victor Pascual Avila <[email-masked]>
Date: Wed, 23 Mar 2016 17:04:29 +0100

On Tue, Mar 22, 2016 at 6:16 AM, Ram Mohan R (rmohanr)
<[email-masked]> wrote:
>>>is not

How about something like the following: "B2BUAs may be deployed for
address hiding or media latching [RFC7362], although TURN (and ICE) is
expected to be used more often for this purpose as it provides better
security properties"

-Victor

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 23 Mar 2016 11:45:20 -0500

On 23 Mar 2016, at 11:04, Victor Pascual Avila wrote:

>>> latching is
>> than

I would personally be happy with that. The more neutral tone might be 
less off-putting to the target audience.

Alissa, would that work for you?

Ben.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 23 Mar 2016 15:58:48 -0700

> On Mar 23, 2016, at 9:45 AM, Ben Campbell <[email-masked]> wrote:
> 
> I would personally be happy with that. The more neutral tone might be less off-putting to the target audience.
> 

WFM

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 23 Mar 2016 16:01:00 -0700

Changes look good, thanks. I will clear when you post the rev.

Note that I may move to ABSTAIN as I’m still not 100% convinced of the value of this draft. Not sure yet. But I appreciate the additional work you put into it.

Alissa

> On Mar 20, 2016, at 9:18 AM, Ram Mohan R (rmohanr) <[email-masked]> wrote:
> 
> Hi Alissa,
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 31 Mar 2016 04:57:34 +0000

Thanks to every one for their feedback. Here is the diff attached. I will
publish this during the IETF week.

Regards,
Ram

-----Original Message-----
From: Alissa Cooper <[email-masked]>
Date: Thursday, 24 March 2016 at 4:31 AM
To: Cisco Employee <[email-masked]>
Cc: Ben Campbell <[email-masked]>, "[email-masked]" <[email-masked]>,

>Note that I may move to ABSTAIN as I’m still not 100% convinced of the
>value of this draft. Not sure yet. But I appreciate the additional work
>you put into it.
>
>Alissa
>