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

[Alissa Cooper <[e-mail]>]

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) <[e-mail]> wrote:
> 
> Hi Alissa,
> 
> Thanks for your feedback. Please see inline
> 
> -----Original Message-----
> From: Alissa Cooper <[e-mail]>
> Date: Saturday, 19 March 2016 at 6:05 PM
> To: Cisco Employee <[e-mail]>
> Cc: Ben Campbell <[e-mail]>,
> "[e-mail]"
> <[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]" <[e-mail]>, IESG
> <[e-mail]>, "[e-mail]"
> <[e-mail]>
> 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
> 
> 
> 
>> 
>> = 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.”
> 
> 
> 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
>> 
>> 
>>> On Jan 17, 2016, at 7:44 PM, Ram Mohan R (rmohanr) <[e-mail]>
>>> wrote:
>>> 
>>> Hi Ben,
>>> 
>>> We will publish a new revision in the next couple of weeks.
>>> 
>>> Regards,
>>> Ram
>>> 
>>> -----Original Message-----
>>> From: Ben Campbell <[e-mail]>
>>> Date: Friday, 15 January 2016 at 4:13 AM
>>> To: "[e-mail]"
>>> <[e-mail]>
>>> Cc: Cisco Employee <[e-mail]>, Alissa Cooper
>>> <[e-mail]>,
>>> "[e-mail]" <[e-mail]>, "[e-mail]"
>>> <[e-mail]>, IESG <[e-mail]>, "[e-mail]"
>>> <[e-mail]>
>>> 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 <[e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/straw
>>> 
>> 
>