[dtn] Secdir last call review of draft-ietf-dtn-bpsec-default-sc-07

Christian Huitema via Datatracker <noreply@ietf.org> Fri, 28 May 2021 18:23 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dtn@ietf.org
Delivered-To: dtn@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 870EC3A3105; Fri, 28 May 2021 11:23:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Christian Huitema via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-dtn-bpsec-default-sc.all@ietf.org, dtn@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.30.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <162222621650.3936.204909667434697510@ietfa.amsl.com>
Reply-To: Christian Huitema <huitema@huitema.net>
Date: Fri, 28 May 2021 11:23:36 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/gQuO0Vh6XZZGCGfYzZkeqHUdA4o>
Subject: [dtn] Secdir last call review of draft-ietf-dtn-bpsec-default-sc-07
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2021 18:23:37 -0000

Reviewer: Christian Huitema
Review result: Ready

I reviewed draft-ietf-dtn-bpsec-default-sc-02 as part
of an early security review requested by the transport AD. This is the follow-up
last call review of draft-ietf-dtn-bpsec-default-sc-07.

The draft is ready, although I would prefer to see somechanges in the encoding
of AEAD tags as explained below.

The changes in draft-07 address most of the points I made in the early review.
The small nit concerning a reference in the table of BIB-HMAC-SHA2 Security Parameters
is fixed and the implementation of AEAD algorithms is easy to read.

I appreciate that the draft now contains an entire appendix describing examples of messages,
their clear-text encoding and the result of authentication and encryption. This probably
required significant effort, and it does address my suggestion to add test vectors in
order to manage implementation complexity.

I could just say that the draft is ready, except for one addition that I find a bit spurious.
The description of AES-GCM states that "the authentication tag produced by the GCM	
mode of AES is not considered part of the cipher text itself", and that "the	
authentication tag is expected to be carried in the BCB-AES-GCM	security block". The
statement is not technically false, but the separation of message and tag goes against
the design of many AEAD implementations, in which the application provides the
crypto API with a clear text of some length, and retrieves a cipher text of a different
length, including the tag. Separating that tag and moving it to a different location
is yet another way to introduce complexity.

That complexity can probably still be managed for AES-GCM, but the general trend is
to implement encryption and authentication in a single operation. I fully expect that
new encryption algorithms will continue that trend, and may well do away with the
formal separation between ciphertext and tag. Recognizing that encryption and
authentication are not separable would simplify the DTN bundle protocol.