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

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

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.