[secdir] Secdir early review of draft-ietf-anima-constrained-voucher-11

Daniel Franke via Datatracker <noreply@ietf.org> Thu, 01 July 2021 00:04 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 315F63A30DC; Wed, 30 Jun 2021 17:04:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Daniel Franke via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: anima@ietf.org, draft-ietf-anima-constrained-voucher.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.33.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <162509788114.10193.4485290358108899416@ietfa.amsl.com>
Reply-To: Daniel Franke <dfoxfranke@gmail.com>
Date: Wed, 30 Jun 2021 17:04:41 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/JjzYESeYlkXat-GEu0N3NT9o4_A>
Subject: [secdir] Secdir early review of draft-ietf-anima-constrained-voucher-11
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, 01 Jul 2021 00:04:41 -0000

Reviewer: Daniel Franke
Review result: Not Ready

I'm reviewing this document as a member of SecDir per the request for early
review.

I'm marking this as "Not Ready" principally because the whole Security
Considerations section is "TBD".

Having no prior familiarity with the ANIMA WG or its output, I found the
introductory section of this draft rather bewildering. The document I wanted to
read for background, RFC 8366, is cited a few sentences in, but the context
didn't make it clear that this was where I wanted to look. Please provide a
paragraph or so worth of background about the ecosystem that this draft lives
in before launching into protocol-specific jargon like "voucher" and "pledge".

You mention trying to conserve both network bandwidth and code size. I see how
you're saving a bit of bandwidth by shortening URLs, using CBOR instead of
JSON, and in some cases avoiding retransmission of public keys. But I'm not
following where the code size wins come from. The procedure described in
section 5.3.1 doesn't seem to save anything significant, since you still need a
whole RFC 5280 implementation for the fallback path.

You've given "ECDSA" as a mandatory-to-implement algorithm, but haven't
specified what particular curves must be supported. Without this, you haven't
gotten any closer to assuring interoperability.

Appendix A looks like a funny thing to find in an RFC. Are you planning to have
the RFC Editor remove this prior to publication, like you'd do for an
"Implementation Status" section? If so, you should include an explicit
instruction to that effect.