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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 9 Oct 2015 11:55:40 +0000

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Thursday, October 08, 2015 10:18 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Ram Mohan R (rmohanr); [email-masked];
> [email-masked]
> 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:[email-masked]]
> >> Sent: Thursday, October 08, 2015 6:49 PM
> >> To: Ram Mohan R (rmohanr)
> >> Cc: [email-masked]; [email-masked]
> >> 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.

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

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

> 
> >
> >>
> >> [...]
> >>
> >>>>
> >>>> 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

> [...]

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 16 Oct 2015 17:41:08 -0500

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:

>> Cc: Ram Mohan R (rmohanr); 
>> [email-masked];
>> [email-masked]

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

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

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

> _______________________________________________
> straw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/straw

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 17 Oct 2015 04:37:23 +0000

HI Ben,

-----Original Message-----
From: Ben Campbell <[email-masked]>
Date: Saturday, 17 October 2015 4:11 am
To: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Cc: Cisco Employee <[email-masked]>,
"[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [straw] AD Evaluation of draft-ietf-straw-b2bua-dtls-srtp-07

>What's the status of the update?

I will send the diffs soon.
>that want to play nice with dtls-srtp" can avoid breaking things".

Agree with you on the practical aspects of this being implemented. I am
fine with 
adding above suggested text.

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

Agreed. 

>this, but it doesn't hurt to have it here as well.

OK. So we will make it MUST

Regards,
Ram

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sun, 18 Oct 2015 03:26:30 +0000

Hi Ben,

Attached are the diffs with the comments incorporated. Please review and
let us know if we have missed some thing.

Regards,
Ram

-----Original Message-----
From: straw <[email-masked]> on behalf of Cisco Employee
<[email-masked]>
Date: Saturday, 17 October 2015 10:07 am
To: Ben Campbell <[email-masked]>, "Tirumaleswar Reddy (tireddy)"
<[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [straw] AD Evaluation of draft-ietf-straw-b2bua-dtls-srtp-07