Re: [secdir] SecDir review of draft-ietf-avtcore-rfc5285-bis-09

[Roni Even <[e-mail]>]

Hi Frank,
Thanks for the review
See the response in-line
Thanks
Roni Even

Hi,
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 document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized.  The actual extensions in use in a session are signaled in the setup information for that session.  This document obsoletes RFC5285.


The document appears in reasonably good shape.
As a whole, the Security Considerations section analyzes the possible threats to the RTP header extension mechanism, and gives the suitable solutions well.

But, there are still several open issues (TBDs) in the document that need to be completed before publication.
Below a series of my own comments, questions for your consideration.


Comments about the Security Considerations Section:

In fact, [RFC3264] also considers packet confidential protection by encrypting the packet bodies to protect against eavesdropping. This point is missed here.





[Roni Even] The text says that “The security considerations of [RFC3264<https://tools.ietf.org/html/rfc3264>] MUST be followed, to prevent, for example, extension usage blocking.”



While Secure Real-time Transport Protocol (SRTP) [RFC3711] covers the same security requirements and measures of RTP header extension mechanism of this draft, but some of its cryptographic algorithms are old and not updated, such as its default and mandatory-to-implement algorithms like: AES-CM and NULL for Encryption, HMAC-SHA1 for Message Authentication/Integrity and so on. Would you please consider to mention this issue in your draft and suggest to use the up to date and secure algorithms to adopt to internet of today. For example, AES-CCM/AES-GCM and HMAC-SHA2_256_128/HMAC-SHA2_512_256?


[Roni Even] I do not think that discussing general SRTP ciphers relative merit in the general header extension document is the appropriate place for it. What is relevant is the RTP Header extension Encryption part, and thus one can consider if this comment applies towards RFC6904. The integrity protection can be considered relevant, but maybe not appropriate for this document. I do note that when using RFC 6904, the stream cipher used for header extension encryption is defined by the ciphers themselves to ensure similar strength.



It is the application profiles that has to mandate ciphers for SRTP. And that is happening and are considering the security needs. If the default ciphers in RFC 3711 becomes totally broken, then we clearly should revise 3711 to address that issue.



I think one needs to consider the arguments in RFC 7202 and RFC7201 when writing any discussion of which ciphers to use. I would think we should keep it non specific and maybe we can add the following text:



“The RTP application designer needs to consider their security needs, that includes cipher strength for SRTP packets in general and what that means for the integrity and confidentiality of the RTP header extensions. As defined by RFC6904 the encryption stream cipher for the header extension is dependent on the chosen SRTP cipher. It can be noted that the default SRTP ciphers (AES CM 128 bits with HMAC-SHA1) are relative weak and more modern ciphers are stronger and should be considered.”




Editorial suggestions:

Title of section 6: it does not comply with the rule that the first alphabet is capital.
[Roni Even] I am not sure which one, this section starts with SDP

Setion 1: the last paragraph misses a ending "."
[Roni Even] OK

A section of Terminology is missed, since there are several words in the draft need this part.
[Roni Even] This is a bis draft so we did not add any new terms. I can look at creating a new section but do we really need it.

Section 4.1.2: in third paragraph, there is a wrong word "dp", which should be "do".
[Roni Even] Thanks, OK

Section 6: suggest to use "SDP Offer/Answer [RFC3264]" to replace "offer/answer [RFC3264]".
[Roni Even] I noticed inconsistency in the document some time with SDP some without and even one with SIP. I can fix this to be “SDP Offer/Answer [RFC3264]” in all the document.


Thank you.


B.R.
Frank