[Last-Call] Secdir last call review of draft-ietf-avtcore-rtp-evc-05

Sean Turner via Datatracker <noreply@ietf.org> Wed, 11 October 2023 14:53 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F31C151089; Wed, 11 Oct 2023 07:53:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Sean Turner via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: avt@ietf.org, draft-ietf-avtcore-rtp-evc.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 11.12.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <169703598045.28899.18058923487691438647@ietfa.amsl.com>
Reply-To: Sean Turner <sean@sn3rd.com>
Date: Wed, 11 Oct 2023 07:53:00 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/9CtTZv5HcSs_ePDAN2WIsBPv8Kw>
Subject: [Last-Call] Secdir last call review of draft-ietf-avtcore-rtp-evc-05
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Oct 2023 14:53:00 -0000

Reviewer: Sean Turner
Review result: Has Issues

tl;dr: Just one issue that I'll get to after rambling for a bit.

This is your typical I-D for an RTP Payload Format for foo. It contains the
usual disclaimers in the Security Considerations section that are found in RTP
Payload Format RFCs:

* It's just about the payload format
* Read RTP & Options for Securing RTP
* There's no MTI security solution (see RFC 7202)
* Apps SHOULD provide a strong security mechanism

This I-D, like RFC 7798, also includes considerations for:
* DoS concerns during compression
* SEI
* End-to-End Security

Issue: If this I-D is like RFC 7798, why does RFC 7798 say this:

 Therefore, the usage of data origin authentication and data integrity
 protection of at least the RTP packet is RECOMMENDED, for example,
 with SRTP [RFC3711].

And this I-D says this:

 Therefore, the usage of data origin authentication and data integrity
 protection of at least the RTP packet is RECOMMENDED but NOT REQUIRED
 based on the thoughts of [RFC7202].

It seems like this I-D says it's similar to HEVC, but then adds this little bit
extra.  Also, "NOT REQUIRED" isn't BCP 14 language so it's probably got to be
changed by either rewording or making it lower case.

Editorial:
* s9 (missing period): s/avoid those/avoid those.