[Drip] First review of drip-rid on cfrg and my response
Robert Moskowitz <rgm@labs.htt-consult.com> Fri, 24 September 2021 13:55 UTC
Return-Path: <rgm@labs.htt-consult.com>
X-Original-To: tm-rid@ietfa.amsl.com
Delivered-To: tm-rid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6C23A29BF for <tm-rid@ietfa.amsl.com>; Fri, 24 Sep 2021 06:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0UwvCG0DGB9 for <tm-rid@ietfa.amsl.com>; Fri, 24 Sep 2021 06:55:49 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239713A29BC for <tm-rid@ietf.org>; Fri, 24 Sep 2021 06:55:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 210C1624D4 for <tm-rid@ietf.org>; Fri, 24 Sep 2021 09:54:48 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nSsSO77vvPTh for <tm-rid@ietf.org>; Fri, 24 Sep 2021 09:54:35 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 378BB624C7 for <tm-rid@ietf.org>; Fri, 24 Sep 2021 09:54:35 -0400 (EDT)
To: "tm-rid@ietf.org" <tm-rid@ietf.org>
From: Robert Moskowitz <rgm@labs.htt-consult.com>
Message-ID: <5c74de19-8792-0516-3e3a-014e08766bbb@labs.htt-consult.com>
Date: Fri, 24 Sep 2021 09:55:29 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------2DD285481A4ADA227FD4AE04"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/mGzhYQMaHlhmi6Mx3mZQZPxsayY>
Subject: [Drip] First review of drip-rid on cfrg and my response
X-BeenThere: tm-rid@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Drone Remote Identification Protocol <tm-rid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tm-rid/>
List-Post: <mailto:tm-rid@ietf.org>
List-Help: <mailto:tm-rid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Sep 2021 13:55:54 -0000
Here is a comment from cfrg that will impact the Security Considerations section of the next ver. I welcome any comments on this here... -------- Forwarded Message -------- Subject: Re: [CFRG] [Non-DoD Source] Re: Please review draft-ietf-drip-rid Date: Fri, 24 Sep 2021 09:47:19 -0400 From: Robert Moskowitz <rgm-sec@htt-consult.com> To: Gajcowski, Nicholas H <nhgajco=40nsa.gov@dmarc.ietf.org>, cfrg@ietf.org <cfrg@ietf.org> Nick, Thank you for this analysis. I will incorporate it in the Security Considerations of the next version. It points to the importance of validating the self-attestion with the public key in the online registry or receiving the offline self-attestion and validating the Registry (HDA) public key from cache. See Appendix B and draft=-ietf-drip-auth. Determined adversaries CAN produce an EdDSA that duplicates an HHIT, but not yet produce the private key for a published EdDSA public key. It would be nice to have more bits in the hash component, but then I loose the feature of using the HHIT as a non-routable IPv6 address. Don't think I want to go that way. There are already apps in devlopment that use this. On 9/23/21 1:15 PM, Gajcowski, Nicholas H wrote: > > Concerning pre-image resistance, the threat as I understand is that > someone can create a separate Host Identity, i.e., EdDSA public key, > that produces an already taken HHIT, i.e, satisfies a 64-bit condition > on the output of cSHAKE128( static data || public key ). The way to > do this would be through brute force, i.e., compute private, public > EdDSA key pairs until you find one with the desired cSHAKE128 output. > This should take about 2^64 attempts. To get an idea of how hard this > would be, consider that a *single* bitcoin mining ASIC can do on the > order of 2^46 sha256 hashes a second or about 2^62 hashes in a single > day. (Also, note there are DES crackers available that will exhaust > the space of 2^56 keys). The point being, 2^64 is not prohibitive > esp. as this can be done in parallel. > > To address this shortcoming, RFC 3972 includes a hardening function > that ups the cost of finding a pre-image by increasing the number of > hashes needed to create a CGA. However, this has obvious limitations > as it increases the cost of creating a CGA by the same factor it > increases the cost of stealing a CGA. A better tradeoff is to > increase the number of bits taken from the hash such as the 96 bits > used in ORCHIDv2. > > Now it should be noted that the 2^64 attempts is for stealing a > *specific* HHIT/CGA. As noted in the case of CGAs (RFC 3972),stealing > *a* CGA with the same prefix out of many becomes commensurately > cheaper and so that applies here. Say there are roughly 1,024 such > possible HHITs for which you'd be happy stealing any one of. Then > rather trying to satisfy a 64-bit condition on the cSHAKE128 output, > you need only satisfy a 54-bit condition (since you have 2^10 more > opportunities for success). > > In the end, I suspect this boils down to not to whether it's feasible > to find a 64 bit preimage, but rather how expensive you want to make it. > > As for collisions of the CGA, I'm not sure what that buys an attacker > as the threat model is unclear. I suppose an attacker will then have > two UAs with the same CGA with one being legitimate/registered. > Unclear how that is better than simply having the two use the same > public key/HOST_ID unless perhaps you want to retain some form of > deniability. > > Nick G > > *From:*CFRG <cfrg-bounces@irtf.org> *On Behalf Of *Robert Moskowitz > *Sent:* Friday, September 17, 2021 1:32 PM > *To:* cfrg@ietf.org > *Subject:* [Non-DoD Source] Re: [CFRG] Please review draft-ietf-drip-rid > > I am not aware of any PQ signature that will work here and accepted > for production systems. So I continue to work with pre-PQ so vendors > can make hardware today to meet their 2023 mandate to support these > rules. That means manufacturing soon. The manufacturers are very > unhappy on how long it is taking ASTM to finish the revision and get > FAA approval of the Memorandum Of Compliance. And we in DRIP will > have to do an addendum to the ASTM MoC for our contribution. > > So please keep the discuss is: > > Do I use EdDSA properly? > Is my use of cSHAKE right? > What are the collision and pre-image attacks. Is there more that I > should reference. > > > On 9/17/21 11:34 AM, Michael Scott wrote: > > On Fri, Sep 17, 2021 at 3:21 PM Blumenthal, Uri - 0553 - MITLL > <uri@ll.mit.edu <mailto:uri@ll.mit.edu>> wrote: > > I have not read the draft, but my answer to Watson is - > because there is not enough room for Post-Quantum > certificates, and Ed25519 is not an acceptable alternative for > some of us. > > I for one would be interested in just how extensive this "some of > us" group is. In the interests of transparency I think they should > step forward and identify themselves. It is a view I respect, but > personally disagree with. > > If people in good faith are willing to make major efforts to put > forward proposals to this forum, it would only be fair for them to > be aware of the extent of that grouping who would reject such > proposals out-of-hand. > > Mike > > -- > Regards, > Uri > > There are two ways to design a system. One is to make is so > simple there are obviously no deficiencies. > The other is to make it so complex there are no obvious > deficiencies. > - C. A. R. Hoare > > > On 9/17/21, 09:59, "CFRG on behalf of Watson Ladd" > <cfrg-bounces@irtf.org <mailto:cfrg-bounces@irtf.org> on > behalf of watsonbladd@gmail.com > <mailto:watsonbladd@gmail.com>> wrote: > > I've read your email and have only one response. > > Why? > > There is enough room for an entire certificate chain using > Ed25519 and > compact encodings. That would be a lot simpler. > > Sincerely, > Watson Ladd > > -- > Astra mortemque praestare gradatim > > _______________________________________________ > CFRG mailing list > CFRG@irtf.org <mailto:CFRG@irtf.org> > https://www.irtf.org/mailman/listinfo/cfrg > <https://www.irtf.org/mailman/listinfo/cfrg> > _______________________________________________ > CFRG mailing list > CFRG@irtf.org <mailto:CFRG@irtf.org> > https://www.irtf.org/mailman/listinfo/cfrg > <https://www.irtf.org/mailman/listinfo/cfrg> > > > > _______________________________________________ > > CFRG mailing list > > CFRG@irtf.org <mailto:CFRG@irtf.org> > > https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg> > > > _______________________________________________ > CFRG mailing list > CFRG@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg
- [Drip] First review of drip-rid on cfrg and my re… Robert Moskowitz