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

Hi Ben,

We will publish a new revision in the next couple of weeks.

Regards,
Ram

-----Original Message-----
From: Ben Campbell <ben@nostrum.com>
Date: Friday, 15 January 2016 at 4:13 AM
To: "draft-ietf-straw-b2bua-dtls-srtp@ietf.org"
<draft-ietf-straw-b2bua-dtls-srtp@ietf.org>
Cc: Cisco Employee <rmohanr@cisco.com>, Alissa Cooper <alissa@cooperw.in>,
"straw-chairs@ietf.org" <straw-chairs@ietf.org>, "straw@ietf.org"
<straw@ietf.org>, IESG <iesg@ietf.org>, "christer.holmberg@ericsson.com"
<christer.holmberg@ericsson.com>
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 <ben@nostrum.com> 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
>> straw@ietf.org
>> https://www.ietf.org/mailman/listinfo/straw