Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

Michael Richardson <> Tue, 29 October 2019 16:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33CF112006E; Tue, 29 Oct 2019 09:08:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 UiNNFE-S0NA1; Tue, 29 Oct 2019 09:08:16 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6234212002F; Tue, 29 Oct 2019 09:08:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2DB7E3818F; Tue, 29 Oct 2019 12:05:31 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 678D485F; Tue, 29 Oct 2019 12:08:14 -0400 (EDT)
From: Michael Richardson <>
To: Benjamin Kaduk <>
cc:, The IESG <>,,,
In-Reply-To: <>
References: <> <> <22000.1572299410@localhost> <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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-sha256"; protocol="application/pgp-signature"
Date: Tue, 29 Oct 2019 12:08:14 -0400
Message-ID: <16729.1572365294@localhost>
Archived-At: <>
Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Oct 2019 16:08:18 -0000

Benjamin Kaduk <> wrote:
    >> > Section 5.8
    doc> although it results in additional network traffic.  The relying MASA
    doc> implementation MAY leverage internal state to associate this request
    doc> with the original, and by now already validated, voucher-request so
    doc> as to avoid an extra crypto validation.
    >> > It seems that doing so would turn the voucher-request into a bearer
    >> > token for retrieving audit-log information (if the MASA accepts
    >> > unauthenticated clients).
    >> That's what's intended.

    > I can see why that functionality is needed, but it seems likely to
    > introduce some privacy and/or security considerations to document.  It's a
    > bit too late in the day for me to reason through them, though.

I think that they are in fact documented!

    >> We tried hard and found a way not to say SHA-1 directly, allowing SHA256 to
    >> replace it appropriately.

    > That's all good and admirable; I'm suggesting that we add a note in the
    > security considerations of this document noting that we rely on the
    > domainID (however determined) to be second-preimage-resistant.

The voucher is not pinned to the domainID, but to the actual certificate.
Distinguishing the domainID for a moment from the thing in the certificate
that hashes the public key when it is signed, if a second-preimage attack
against the domainID would allow phony entries to be placed in the audit log.

Assuming that the domainID is calculated using the same hash that is used in
the certificate signature, then a second-preimage attack would break all of
the certificates, period.

I have added a section saying this, but it seems that our reference to
RFC7469 already deals with this.

    >> > Section 11.2
    doc> Although the nonce used by the Pledge in the voucher-request does not
    doc> require a strong cryptographic randomness, the use of TLS in all of
    doc> the protocols in this document does.
    >> > We discuss the need for strong randomness in the nonce in Section 11.3,
    >> > so it's not clear this is actually true.
    >> We don't think that the voucher nonce has to be of the same quality as
    >> something that
    >> goes into a KDF.  It is at the level of TCP Sequeunce number, not seed for
    >> generating a private key...

    > I mean, we literally say "Reducing the possibility of this is why the
    > pledge is mandated to generate a strong random or pseudo-random number
    > nonce."  So to also say "the nonce [...] does not require a strong
    > cryptographic randomness" seems to be in conflict with the former
    > statement.
    > Are you saying that "strong random" and "strong cryptographic random" mean
    > different things, or am I misreading the document in some other way?

A Cryptographically Strong Sequence is more than enough. (section 6.2 of RFC4086).
We don't need a "unguessable random number" (seed) section 5.
Maybe I'm splitting hairs here.

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-