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

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

This diff is published now. New revision -
https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-dtls-srtp/

Ram

-----Original Message-----
From: Cisco Employee <[e-mail]>
Date: Thursday, 31 March 2016 at 10:28 AM
To: "[e-mail]" <[e-mail]>, Alissa Cooper <[e-mail]>
Cc: Ben Campbell <[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)

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