Re: [secdir] secdir review of draft-ietf-clue-rtp-mapping

[Dan Harkins <[e-mail]>]

   Hi Roni,

On 1/10/17 11:30 PM, Roni Even wrote:
>
> Hi Dan,
>
> Thanks for the review
>
> See inline
>
> Roni
>
> *From:*Dan Harkins [mailto:[e-mail]]
> *Sent:* יום ו 06 ינואר 2017 23:52
> *To:* [e-mail]; [e-mail]; 
> [e-mail]
> *Subject:* secdir review of draft-ietf-clue-rtp-mapping
>
>
>   Greetings,
>
>    I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>    This draft provides some recommendations and mappings to allow RTP
> to be used in the CLUE protocol.
>    I believe this draft is Ready with the following nits:
> 1) it makes normative reference to 3 other I-Ds. I am not familiar
> with those drafts or their status or whether any of the normative
> behavior this draft relies upon is contentious or not. Somebody
> (not me) should make sure that all ducks are in a row before this
> draft advances.
> */[Roni Even] I assume you are referring to the normative references in 
> general since there all references in the Security section are 
> informational. /*
   I'm referring to the 3 Internet-Drafts referenced in the
section called "Normative References", section 10.1. An I-D
is, as noted, a "work in progress". So you're making a normative
reference to a document in a state of flux. That sounds a bit
alarming to me. What if, as they progress, the things you are
normatively depending on change in a way that make this
dependency not work anymore?

   I'm just saying someone (not me) has to make sure that that
does not happen. The alternative is to wait for them to be
published and then refer to them as RFCs.
> 2) having RFC 2119 words in the Security Considerations seems OK
> for saying things like "CLUE endpoints MUST support RTP/SAVPF and
> DTLS-SRTP keying [RFC5764]" because it's just saying you need to
> support something else that is providing you security. But I think
> MUST language describing how the protocol needs to behave in order
> to be secure itself belongs outside the Security Considerations.
> I'm referring to: "Inappropriate choice of CNAME values can be a
> privacy concern, since long-term persistent CNAME identifiers can be
> used to track users across multiple calls.  CLUE endpoint MUST
> generate short-term persistent RTCP CNAMES, as specified in RFC7022
> [RFC7022], resulting in untraceable CNAME values that alleviate this
> risk." I suggest placing that in a different section, possibly making
> a new section that describes has all the various recommendations
> being made on CLUE in one place.
> */[Roni Even] I am not sure, both cases are the same. RTP has multiple 
> profiles and for security the secure profile MUST be supported. RTP 
> also has CNAME and the creation of CNAME is specified in another 
> document [RFC 7022],  for security reasons you MUST choose a specific 
> mode to create the CNAMEs. I am not sure that having a section with 
> all the normative language in the document make much sense since they 
> will be out of context. /*
   RFC 7022 does not place a requirement on CLUE endpoints. Its
seems this I-D is placing a requirement on CLUE endpoints, namely
that they MUST generate RTCP CNAMES per RFC 7022. Now maybe I'm
misreading this and there is actually some other RFC that places
this requirement on CLUE endpoints. In which case you should refer
to that document for the requirement. But if it is this document
placing a behavioral requirement on CLUE endpoints, then it is my
personal opinion that such a requirement is not appropriate for
the Security Considerations.

   regards,

   Dan.