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

Eliot Lear <> Wed, 17 June 2020 05:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7AD483A0EBC; Tue, 16 Jun 2020 22:31:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JWTWWZq7Gvmp; Tue, 16 Jun 2020 22:31:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 906E73A0EBA; Tue, 16 Jun 2020 22:31:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5823; q=dns/txt; s=iport; t=1592371882; x=1593581482; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Owsz3tmevHdZpRSxeDnh6JjvfyI/VGmta6z3StUOjZg=; b=GTMbVtuB976RC14i5Hfp7bCP4NJoZacJkqR76pEy4Ku8DTKN2mQOGDrf Q1c51iu23KCyMOlyUoX3DTZ3XVpQ5LSZ7YAI7JdKwVJ8SRlZ2+465ZXml RpiAVi8lb4oNbBs7nfoTx+7HRQddfCXwczkaXi0Wg96eWQziJidG8hyEW s=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.73,521,1583193600"; d="asc'?scan'208";a="27191345"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jun 2020 05:31:17 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id 05H5VGut002248 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Jun 2020 05:31:17 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_03704023-2E77-4104-AC4B-52BD2C02B42C"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Wed, 17 Jun 2020 07:31:16 +0200
In-Reply-To: <32493.1572639262@localhost>
Cc: Benjamin Kaduk <>,,,, The IESG <>,
To: Michael Richardson <>
References: <> <> <22000.1572299410@localhost> <> <32493.1572639262@localhost>
X-Mailer: Apple Mail (2.3608.
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: Wed, 17 Jun 2020 05:31:25 -0000


Could we recap a bit on this?  I have commented on the use of the rfc822Name myself, and was a bit concerned about misuse and misinterpretation prior to rfcSELF being present.

Now that it is it represents a new convention.  The question at hand is whether the information found on the LHS could be subject to misinterpretation by non-participants.  I wonder if we could add an EKU as a SHOULD to break the logjam.


> On 1 Nov 2019, at 21:14, Michael Richardson <> wrote:
> Signed PGP part
> 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 =-