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

Michael Richardson <> Fri, 01 November 2019 20:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3228C121322; Fri, 1 Nov 2019 13:14:27 -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 n5170GWz7_yR; Fri, 1 Nov 2019 13:14:24 -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 B6674120A34; Fri, 1 Nov 2019 13:14:24 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 7279D3897A; Fri, 1 Nov 2019 16:11:34 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 7CF3E612; Fri, 1 Nov 2019 16:14:22 -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: Fri, 01 Nov 2019 16:14:22 -0400
Message-ID: <32493.1572639262@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: Fri, 01 Nov 2019 20:14:32 -0000

Benjamin Kaduk <> wrote:
    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.

To be clear: any registrar which has ever formed a valid voucher-request MAY
retrieve the audit-log at regular intervals to verify the status of the
device.  The words, "now already validated" means that the MASA agreed with
the voucher-request.  Most implementations are going to log the
voucher-request as part of the internal audit log, so a memcmp() on that is enough.

This would reveal new owners.  Whether the new owner is legitimate or not is
not something we can answer: it might be that the device has been stolen, or
maybe it's legitimately lent, rented, sold, etc.

    >> > Section 11
    >> > I am somewhat embarassed that I did not previously note that the
    >> > mechanism used to generate the domainID needs to be
    >> > second-preimage-resistant or an attacker can claim to be a registrar for
    >> > a domain that already exists.
    >> Right now, that's in:
    >> 5.8.2.  Calculation of domainID
    >> The domainID is a binary value (a BIT STRING) that uniquely
    >> identifies a Registrar by the "pinned-domain-cert"
    >> If the "pinned-domain-cert" certificate includes the
    >> SubjectKeyIdentifier (Section [RFC5280]), then it is to be
    >> used as the domainID.  If not, the SPKI Fingerprint as described in
    >> [RFC7469] section 2.4 is to be used.  This value needs to be
    >> calculated by both MASA (to populate the audit-log), and by the
    >> Registrar (to recognize itself).
    >> 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.

I've added this to the security considerations as 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?

I take your point, and I guess we were splitting hairs.
I'll just rephrase it to remove the Although statement.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]        |   ruby on rails    [

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