Re: [straw] AD Evaluation of draft-ietf-straw-b2bua-dtls-srtp-07

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

Hi,

What's the status of the update?

Also, a few more comments inline:

Thanks!

Ben.


On 9 Oct 2015, at 6:55, Tirumaleswar Reddy (tireddy) wrote:

>> -----Original Message-----
>> From: Ben Campbell [mailto:[e-mail]]
>> Sent: Thursday, October 08, 2015 10:18 PM
>> To: Tirumaleswar Reddy (tireddy)
>> Cc: Ram Mohan R (rmohanr); 
>> [e-mail];
>> [e-mail]
>> Subject: Re: [straw] AD Evaluation of 
>> draft-ietf-straw-b2bua-dtls-srtp-07
>>
>>
>>
>> On 8 Oct 2015, at 10:45, Tirumaleswar Reddy (tireddy) wrote:
>>
>>>> -----Original Message-----
>>>> From: Ben Campbell [mailto:[e-mail]]
>>>> Sent: Thursday, October 08, 2015 6:49 PM
>>>> To: Ram Mohan R (rmohanr)
>>>> Cc: [e-mail]; [e-mail]
>>>> Subject: Re: [straw] AD Evaluation of
>>>> draft-ietf-straw-b2bua-dtls-srtp-07
>>>>
>>>> Thanks for the response. Further comments inline. I removed 
>>>> sections
>>>> that don't appear to need further discussion.
>>>>
>>>> Thanks!
>>>>
>>>> Ben.
>>>>
>>>> On 8 Oct 2015, at 4:41, Ram Mohan R (rmohanr) wrote:
>>>>>>
>>>>
>>>> [...]
>>>>
>>>>>>
>>>>>>
>>>>>> Comments and Questions
>>>>>> ======================
>>>>>>
>>>>>> - There's a marked lack of mention of B2BUAs that inspect or 
>>>>>> modify
>>>>>> media content. I realize that this draft does not seek to enable
>>>>>> that particular elephant-in-the-room. Is it worth mentioning them
>>>>>> as out of scope?
>>>>>
>>>>> In section 1.2 (Goals) we can add this text. Is this ok ?
>>>>> EXISTING:
>>>>> The following sections describe the behavior B2BUAs MUST follow in
>>>>> order to avoid any impact to end-to-end DTLS-SRTP sessions.
>>>>>
>>>>>
>>>>> NEW:
>>>>> The following sections describe the behavior B2BUAs can follow to
>>>>> avoid breaking end-to-end DTLS-SRTP sessions.
>>>> B2BUAs terminating DTLS-SRTP
>>>>> session are outside the scope of this document.
>>>
>>> I think the above line is not required. This doc discusses the 
>>> problem
>>> with B2BUAs terminating DTLS-SRTP session, mechanism to detect such
>>> B2BUA and says that B2BUA must not to be enabled in this mode.
>>>
>>
>> See next comment...
>>
>>>>
>>>> I think that's moving in the right direction, but there's normative
>>>> text elsewhere that says b2buas MUST NOT terminate dtls-srtp. Would
>>>> it make sense to say something like "B2BUAs that inspect or modify
>>>> media content are outside the scope of this document"?
>>>>
>>>> Or is it the intent to forbid such devices ?
>>>
>>> The intent is to prohibit such devices because of the privacy 
>>> concern.
>>
>> That's a different answer than Ram gave. Content aware/modifying 
>> B2BUAs
>> cannot both be forbidden and out-of-scope at the same time.
>>
>> I think the confusion here is around whether this draft should say 
>> b2buas
>> MUST not terminate dtls-srtp, or to say that they cannot under most
>> circumstances without breaking 4474/4474bis identity signatures.
>> The former needs 2119 language, the latter is just a statement of 
>> fact.
>
> I think we should go with the former, otherwise it creates a privacy 
> problem.

While I agree with the sentiment, there's a bit of a standing problem 
here. We can't really force B2BUA vendors to even read this spec, much 
less comply with it. So this seems to be an attempt to put requirements 
on devices that don't implement the spec containing the requirement.

So it seems to me the best we can do is take the approach of saying 
something to the effect of "The dtls-srtp framework recommends that 
endpoints use RFC4474 to integrity protect the fingerprint attributes. 
Thus, under most circumstances, B2BUAs cannot terminate the dtls-srtp 
connection without invalidating the signature and causing the session to 
fail."

Basically, that effectively makes the scope of the draft "How b2bua's 
that want to play nice with dtls-srtp" can avoid breaking things".

>
>>
>> There are some exceptions to the "cannot" in the above paragraph. For
>> example, a b2bua that is collocated with the offerer's identity 
>> service could
>> modify fingerprints prior to applying the identity signature. Or 
>> since 5763
>> only says endpoints SHOULD use 4474, a b2bua might see unprotected
>> fingerprints and attempt to modify them.  Does this draft mean to 
>> forbid
>> those behaviors?
>
> Endpoint or SIP proxy in the endpoints network has to insert the 
> identity assertion to avoid B2BUA in the signaling path from 
> terminating the DTLS connection and decrypting the media. WebRTC also 
> has the same problem that without IdP and identity assertion, 
> malicious signaling server can decrypt the media.

Right. I don't think this draft can prevent that. But it can rule it out 
of scope.

>
>>
>>>
>>>>
>>>>>> Does this draft intend to make them illegal for SRTP protected
>>>>>> sessions with it's proscription about terminating dtls?
>>>>>
>>>>> The behaviour for cases where B2BUA terminates DTLS-SRTP is not in
>>>>> the scope of this draft.
>>>>>
>>>>
>>>> See above comment about normative statements concerning the
>>>> termination of dtls-srtp.
>>>>
>>>> [...]
>>>>
>>>>>>
>>>>>> -3.1.1, 3rd paragraph from end: "the B2BUA SHOULD be prepared to
>>>>>> receive DTLS, STUN and media on the ports it advertised to Bob in
>>>>>> the INVITE request. "
>>>>>>
>>>>>> What are the consequences if it's not prepared to do so?
>>>>>
>>>>> The consequences can be - the messages may get dropped which in 
>>>>> turn
>>>>> may delay STUN/DTLS checks and would requires the endpoints to
>>>>> re-transmit the messages.
>>>>>
>>>>
>>>> Given that this is a SHOULD rather than a MUST, it would be useful 
>>>> to
>>>> describe those consequences in the text.
>>>
>>> The other alternative would be to change from SHOULD to MUST and 
>>> avoid
>>> the above problems.
>>
>> I would not object to that--although on reflection, isn't this 
>> requirement true
>> of all b2buas? That is, is it in any way specific to dtls-srtp?  Is 
>> that
>> documented elsewhere?
>
> I don't think any other doc is discussing this point.

Okay. It might have been better to have that in a more general spec than 
this, but it doesn't hurt to have it here as well.

>
>>
>>>
>>>>
>>>> [...]
>>>>
>>>>>>
>>>>>> Also, I think the 4474bis reference needs to be normative, given
>>>>>> that
>>>>>> one needs to understand that draft to implement the normative 
>>>>>> bits
>>>>>> about
>>>>>> modifying anything protected by the signature. OTOH, does this 
>>>>>> need
>>>>>> to
>>>>>> reference 4474bis, or would 4474 suffice?
>>>>>
>>>>> rfc4474bis is appropriate since it defines mechanisms to use SDP
>>>>> parameters (like a=fingerprint) in the Identity header digest.
>>>>> We will use rfc4474bis and make the reference normative.
>>>>
>>>> Your response is reasonable, but keep in mind that will block
>>>> publication of this draft until 4474bis is published.
>>>
>>> Yes, https://tools.ietf.org/html/rfc4474#section-13.1 discusses
>>> signature over the SIP bodies but does not go into detail like
>>> rfc4474bis explains using fingerprint for generating assertion. 
>>> Would
>>> it be okay to have normative reference of rfc4474 and informative
>>> reference of rfc4474bis ?
>>
>> Both protect the fingerprint. 4474 just does it by protecting the 
>> entire
>> body. 4474bis has the may be more deployable. But it seems to me that
>> either work for the purposes of this draft. And since 4474bis 
>> proposes
>> to obsolete 4474, a reference to 4474 will effectively become a
>> reference to 4474bis.
>
> Thanks, will update draft.
>
>>
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> -3.1.2: "The mechanism described in Security Considerations 
>>>>>> section
>>>>>> MUST
>>>>>> be
>>>>>> used by endpoint to detect malicious B2BUA¹s that MAY attempt to
>>>>>> terminate the DTLS-SRTP session."
>>>>>>
>>>>>> I'm not sure it makes sense for this draft to put normative
>>>>>> requirements
>>>>>> on endpoints. Do you mean to say they "can" use
>>>>>> the mechanism?
>>>>>
>>>>> This has to be fixed. The idea is to have either endpoint or the 
>>>>> SIP
>>>>> proxy
>>>>> server in the endpoints network to generate Identity header on
>>>>> behalf
>>>>> of
>>>>> the endpoint and perform identity validation procedure.
>>>>
>>>> I'm not sure I understand what you mean by "this has to be fixed". 
>>>> Do
>>>> you mean fixed in the draft, or that endpoints need to fix 
>>>> behavior?
>>>
>>> I think Ram meant fix the draft.
>>
>> In any case, if this draft places new normative requirements on
>> dtsl-srtp endpoints or identity services, it would need to update 
>> 5763.
>
> Yes, will update that this doc updates 5763.
>
> Cheers,
> -Tiru
>
>>
>> [...]
> _______________________________________________
> straw mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/straw