[secdir] Secdir last call review of draft-ietf-cellar-ebml-13

Valery Smyslov via Datatracker <noreply@ietf.org> Thu, 31 October 2019 08:09 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D8A120839; Thu, 31 Oct 2019 01:09:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Valery Smyslov via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Cc: last-call@ietf.org, cellar@ietf.org, draft-ietf-cellar-ebml.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.108.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Valery Smyslov <valery@smyslov.net>
Message-ID: <157250938001.30360.4800852999851408878@ietfa.amsl.com>
Date: Thu, 31 Oct 2019 01:09:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/qzdf9kepdu3OnnxTwX5iwU4EH2o>
Subject: [secdir] Secdir last call review of draft-ietf-cellar-ebml-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Oct 2019 08:09:40 -0000

Reviewer: Valery Smyslov
Review result: Ready

Reviewer: Valery Smyslov	
Review result: Ready

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.


The draft describes an Extensible Binary Meta Language (EBML)
format, that is a generalized file format for any type of data. As such
the EBML itself doesn't include any mechanisms providing
security services, besides marginal integrity check via crc32,
that is optional and limited in use. The EBML relies on external
mechanisms that would provide security services. 

The Security Considerations section describes various issues 
that the EBML implementations should take into consideration 
even in the presence of external cryptographic protection.
The list of issues seems to be quite exhaustive for the EBML.

I previously reviewed the -09 version of the draft.
Comparing with the -09 version the Security 
Considerations section in the -13 version is expanded a bit,
making the described security issues more clear.