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

["Ram Mohan R (rmohanr)" <[e-mail]>]

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 <[e-mail]>
Date: Thursday, 24 March 2016 at 4:31 AM
To: Cisco Employee <[e-mail]>
Cc: Ben Campbell <[e-mail]>, "[e-mail]" <[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)

>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
>>>> 
>>> 
>> 
>