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

["Ben Campbell" <[e-mail]>]

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