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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

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

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

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

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


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

> 
> [...]
> 
> >
> >>
> >> I'm confused by language about "inspect[ing] the RTP headers and RTCP
> >> packets" here and in the subsections. What do you mean about
> >> inspecting
> >> rtcp packets? Is this an attempt to dance around content inspection?
> >> Wont a good portion of the "rtcp packets" be encrypted?
> >
> > Yes. A B2BUA can inspect the unencrypted portions of the RTCP packet.
> >
> 
> The wording "and RTCP packets" may lead people to believe it can inspect
> the entire packet. It might be worth saying "unencrypted parts of the
> RTCP packet". It's probably not necessary to say that every time, since
> it complicates the sentence structure, but it would be helpful to do so
> at least the first time.
> 
> [...]
> 
> >> The paragraph takes the form of "To do A, you must do B, and B is not
> >> allowed". It might be easier to say that "You can't do A, because of
> >> the
> >> issue with B."
> >
> > Ok. Will re-word this sentence to some thing like this:
> >
> > NEW:
> > A B2BUA cannot modify RTP headers or RTCP packets, as to do so it
> > needs to
> > act as a DTLS endpoint, terminate the DTLS-SRTP session and
> > decrypt/re-encrypt RTP packet.
> 
> I suggest "...it would need to...". Otherwise that looks good.

Sure, will change.

> 
> >>
> >> Can you be more precise about what "break end-to-end security" means?
> >> e.g. the receiver would consider the packets invalid? Also, this
> >> paragraph might could use another mention of 4474/4474bis.
> >
> > How about this:
> > EXISTING:
> > This would break end-to-end security and hence a B2BUA MUST NOT
> > terminate DTLS-SRTP session.
> >
> >
> > NEW:
> > This would cause the identity verification procedure discussed in
> > 4474bis
> > to fail and hence a B2BUA MUST NOT terminate the DTLS-SRTP session.
> >
> 
> I suggest "identity and integrity protection procedures". Otherwise it
> looks good.

Okay, will change.

> 
> >
> >>
> >> - 4: "Since DTLS operates on
> >>  the 5-tuple"
> >>
> >> What does that mean? It sounds something like "encrypts" or
> >> "authenticates" the 5, tuple--but I don't think that's what you mean.
> >
> > How about this ?
> > "Since each DTLS connection is setup on a unique 5-tuple.."
> 
> Works for me.
> 
> >
> >
> >>
> >> "unique transport addresses"
> >> Do you mean the b2bua must replace each answerers's address with a
> >> distinct address? Also do you mean distinct address, or distinct
> >> combination of address and port?
> >
> > Transport address means IP address and port
> >
> 
> I'm not sure everyone will read it that way, unless you define that in
> the draft or reference a definition.

Yes, will add reference.

-Tiru

> 
> [...]