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

[Roni Even <[e-mail]>]

HI Dan,

1.       The first two documents are in the RFC editor queue and the third one is well advanced and is an important document for a lot of work in the ART area and is in its final stages. The RFC editor waits for RFCs for normative references before publishing the document.

2.       RFC7022 is relevant for all RTP payloads, it updates RFC3550 which is the RTP specification and provide guidelines for choosing RTCP CNAMEs. The CNAME is the identification of the RTP endpoint. The CLUE RTP usage document outlines how to use RTP in CLUE and in the security section we ouline how to address security concerns for RTP by using a specific RTP profile and choosing specific ways to create the relevant parameters.
Roni

From: Dan Harkins [mailto:[e-mail]]
Sent: יום ד 11 ינואר 2017 19:50
To: Roni Even; [e-mail]; [e-mail]; [e-mail]
Subject: Re: secdir review of draft-ietf-clue-rtp-mapping


  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]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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.