[MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-sdp-uks-07: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Sat, 10 August 2019 03:22 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBE912004D; Fri, 9 Aug 2019 20:22:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mmusic-sdp-uks@ietf.org, Bo Burman <bo.burman@ericsson.com>, mmusic-chairs@ietf.org, bo.burman@ericsson.com, mmusic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.100.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <156540736004.1746.17935620098171968310.idtracker@ietfa.amsl.com>
Date: Fri, 09 Aug 2019 20:22:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/MyuShy9Hb75kz6jaUC356dQQOmw>
Subject: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-sdp-uks-07: (with COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Aug 2019 03:22:40 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mmusic-sdp-uks-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-uks/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for these updates; they are a big improvement.

In Section 3.2

   The absence of an identity binding does not relax this requirement;
   if a peer provided no identity binding, a zero-length extension MUST
   be present to be considered valid.

For some reason my brain keeps trying to tell me that this could be
misinterpreted somehow, as implying that if the peer doesn't implement
this extension it would be considered invalid.  But I don't see any
actual specific problems with this text, so it's probably fine.

   An "external_id_hash" extension that is any length other than 0 or 32
   is invalid and MUST cause the receiving endpoint to generate a fatal
   "decode_error" alert.

Very pedantic here, but the numbers aren't quite right, as the
"external_id_hash" extension would be length 1 or 33 due to the length
octet.  We'd have to say that the "binding_hash" is length 0 or 32 to be
pedantically correct.

Section 6

   Without identity assertions, the mitigations in this document prevent
   the session splicing attack described in Section 4.  Defense against
   session concatenation (Section 5) additionally requires protocol
   peers are not able to claim the certificate fingerprints of other
   entities.

nit: "requires that".