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

Michael Richardson <> Sun, 04 July 2021 23:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 159BE3A2A27; Sun, 4 Jul 2021 16:42:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cGmj4n_BKO-1; Sun, 4 Jul 2021 16:42:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28C903A2A23; Sun, 4 Jul 2021 16:42:39 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B895538B08; Sun, 4 Jul 2021 19:45:00 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id L7-Lzv7S9xxM; Sun, 4 Jul 2021 19:44:55 -0400 (EDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 9DD4138B00; Sun, 4 Jul 2021 19:44:55 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 5727E319; Sun, 4 Jul 2021 19:42:33 -0400 (EDT)
From: Michael Richardson <>
To: Daniel Franke <>
In-Reply-To: <>
References: <>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Sun, 04 Jul 2021 19:42:33 -0400
Message-ID: <2878.1625442153@localhost>
Archived-At: <>
Subject: Re: [secdir] [Anima] Secdir early review of draft-ietf-anima-constrained-voucher-11
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 04 Jul 2021 23:42:48 -0000

Daniel Franke via Datatracker <> wrote:
    > I'm marking this as "Not Ready" principally because the whole Security
    > Considerations section is "TBD".

Yes.  We were hoping to get early reviews from people who had previously reviewed RFC8995.
Filling in the Security Considerations without repeating RFC8995's lengthy
section will be a challenge.

    > 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".

fair enough!
opened issue:

    > 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.
The short of it is that on many IoT devices, we already have CBOR, COSE code
present, because they are using ACE, OSCORE, etc.  we'll make this more
explicit thank you.

    > 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.

The examples are intended to provide meaningful input for unit tests.
This is quite common for anything involve cryptographic operations.
We don't intend to remove it.   Our experiences is that people outside of the
IETF find protocols without examples to be challenging to implement.
Should we merge Appendix A and B?

Michael Richardson <>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide