Re: [secdir] Secdir last call review of draft-ietf-drip-arch-22
shuai zhao <shuai.zhao@ieee.org> Thu, 12 May 2022 00:11 UTC
Return-Path: <shuai.zhao@ieee.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865C4C15E413 for <secdir@ietfa.amsl.com>; Wed, 11 May 2022 17:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.673
X-Spam-Level:
X-Spam-Status: No, score=-7.673 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.575, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ieee.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5t9gXhEF6qQ for <secdir@ietfa.amsl.com>; Wed, 11 May 2022 17:11:22 -0700 (PDT)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FFC8C157B34 for <secdir@ietf.org>; Wed, 11 May 2022 17:11:22 -0700 (PDT)
Received: by mail-oi1-x22d.google.com with SMTP id w123so4619358oiw.5 for <secdir@ietf.org>; Wed, 11 May 2022 17:11:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=aIkXh1JVzNc/SKytPkTMNM0lrFkQ5jXV8G3o81Q8U3U=; b=K6fTd/A0qyTzU8HD1mtlJfxRcgxktLihdWmiB2FDpzbT1XDG4bq+bDeXO6XnHvDByT aCSzQh8o8pmP6cSmNevzHQFw86+ZKrjzhpKn6eSwUpDB2vhWL3WD9DeanKvRNx0hujdB QKqydLHA9Tx4fWK1u+keJ9RsltXH13qKFYOdk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=aIkXh1JVzNc/SKytPkTMNM0lrFkQ5jXV8G3o81Q8U3U=; b=WUxBUhn7q0zLNJHPeyfilWzby0xDiHSUbYvXs+KOpCAtsVrR0M6KTVYvHO6/M8AgMD Q3v5vRO7ZcG2KwijRhvgJ4qt1rwWXIm6yHgdLR5rTysHqhEz5k3QlqceXIILbcEHZ71D 3UAAiTNEYlCJk2iHj5yH2KN2TggHbqsXSShl0m2mUJbx2jdxGaD89tA4DhCie4o3DePv kFhqacE1vN5bwtM9DeWziSBDLMP5rFsVieORAAFHHylbTs+EtajOrz5atB/NYF5yKbtg fJUNPs16eaOYGLtd0OwjiyeZYHuHEje7zlhjhqQv0rQEKQa3gF/Wy1JieXzGgui2agt+ YcjA==
X-Gm-Message-State: AOAM533rj/jUcV4RHT2jlih+HIQRZx1LtrS1pgYVjpTdeGSgiNzC6rZR nja2gb3HK/pz1Sxl//1TkQtalA==
X-Google-Smtp-Source: ABdhPJy56KDssy8nEnY0hzyJ5ls2Br0mPEVRy8ZQzoW8aRYFNdsU8lvWcOyuoKHFJ+a5aNhiABGvFw==
X-Received: by 2002:a05:6808:e8f:b0:2f7:6c1a:c1a with SMTP id k15-20020a0568080e8f00b002f76c1a0c1amr3703871oil.129.1652314281117; Wed, 11 May 2022 17:11:21 -0700 (PDT)
Received: from PH0PR17MB5728.namprd17.prod.outlook.com ([52.96.186.37]) by smtp.gmail.com with ESMTPSA id u4-20020a4aae84000000b0033a3450cc20sm1576863oon.0.2022.05.11.17.11.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 May 2022 17:11:20 -0700 (PDT)
From: shuai zhao <shuai.zhao@ieee.org>
To: Valery Smyslov <valery@smyslov.net>, "Stuart W. Card" <stu.card@axenterprize.com>, Robert Moskowitz <rgm@htt-consult.com>
CC: "draft-ietf-drip-arch.all@ietf.org" <draft-ietf-drip-arch.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "tm-rid@ietf.org" <tm-rid@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: Secdir last call review of draft-ietf-drip-arch-22
Thread-Index: ATQ0MTk5zSQFxTv/75qhlPYoCbOlN8hixD9V
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Thu, 12 May 2022 00:11:18 +0000
Message-ID: <PH0PR17MB5728869B4521B619367A133AF4CB9@PH0PR17MB5728.namprd17.prod.outlook.com>
References: <164864828914.19999.4038160950945043224@ietfa.amsl.com>
In-Reply-To: <164864828914.19999.4038160950945043224@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_PH0PR17MB5728869B4521B619367A133AF4CB9PH0PR17MB5728namp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/kcZvQLrXZKn3JNopnwZL6kl8u8w>
Subject: Re: [secdir] Secdir last call review of draft-ietf-drip-arch-22
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2022 00:11:26 -0000
Hi Valery, We have this Github issue tracker<https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/40> for your comments. Please see our response below. From: Valery Smyslov via Datatracker <noreply@ietf.org> Date: Wednesday, March 30, 2022 at 6:51 AM To: secdir@ietf.org <secdir@ietf.org> Cc: draft-ietf-drip-arch.all@ietf.org <draft-ietf-drip-arch.all@ietf.org>, last-call@ietf.org <last-call@ietf.org>, tm-rid@ietf.org <tm-rid@ietf.org> Subject: Secdir last call review of draft-ietf-drip-arch-22 Reviewer: Valery Smyslov Review result: Has Issues The topic of the draft is complex and involves many fields which I'm not expert of. The overall architecture looks secure, however it's difficult for me to analyse all the details. Nevertheless, it seems to me that there are some security issues with the draft. 1. Section 3.2 A UA equipped for Broadcast RID SHOULD be provisioned not only with its HHIT but also with the HI public key from which the HHIT was derived and the corresponding private key, to enable message signature. A UAS equipped for Network RID SHOULD be provisioned likewise; the private key resides only in the ultimate source of Network RID messages (i.e., on the UA itself if the GCS is merely relaying rather than sourcing Network RID messages). Each Observer device SHOULD be provisioned either with public keys of the DRIP identifier root registries or certificates for subordinate registries. I wonder why SHOULDs are used here and not MUSTs. In which cases it's OK not to equip e.g. UAs with private keys and how they will perform digital signatures in this case? Am I missing something? Shuai/ Solution: change first SHOULD to MUST in section 3.2 2. It is not clear for me how revocation is done in case the private key of UA is compromised. While the Security considerations section states that revocation procedures are yet to be determined, I think that some text about the directions in which they are planned to be determined should be present. Bob/ Since these are raw keys, revocation is not directly possible. The drip-registry draft may evolve various methodologies for providing revocation information. At this writing, we would be really speculating. Perhaps, black-holing in DNS; if a DET has been revoked, a DNSSEC protected response on looking up the DET would say so. We might be able to include this as an example for revocation, but only an example at this point. Shuai/ Nothing to be updated. 3. Section 9. The size of the public key hash in the HHIT is also of concern. It is well within current server array technology to compute another key pair that hashes to the same HHIT. If I understand the draft correctly, the size of public key hash is 20 or 19 octets (Section 3.1). Bob/ The architecture document does not detail the format of an HHIT. It turns out that in draft-ietf-drip-rid, the hash size is 64 bits so this attack is real and details about it are in the Security Considerations of that draft. Perhaps say: The size of the public key hash in the HHIT (64 bits) is also of concern Finding another key pair that hashes to the same hash requires second preimage attack, which must take in this case 2^160 or 2^152. In my understanding of the state-of-art, it's still beyond possibilities of current computers. Am I missing something? Bob/ Unfortunately you have to see: draft-ietf-drip-rid-17 sec 10. [Med] The initial point was to record the potential security consideration that should be further examined in the solution spec. I'm not convinced we need to call out solution-specific details (e.g., 64 bits) here or call out ietf-drip-rid. 4. The Security Considerations section is silent about possible impact of Cryptographically Relevant Quantum Computers. While it's not clear whether such computers will be ever build, the proposed architecture looks fragile with respect to them. First, from my understanding the architecture, private/public key pairs in UA are relatively long-lived and difficult to update. This gives an attacker plenty of time to break them and once they are broken, enough time to exploit. Second, the impact of breaking can be substantial due to the nature of UA (a potentially dangerous object). Third, while many protocols involved in this architecture can be upgraded with quantum safe cryptographic primitives, it seems to me that for some pieces it will be really challenging (e.g. the draft discusses limitations on payload size for Bluetooth, which will be more severe with PQ cryptography with much larger keys and signatures). I think this issue must be addressed somehow, at least mentioned. Bob/ Intentionally so. We could get lost in the weeds. We are extremely size and computing constrained and current QSC is just not providing solutions. IF such a crypto suite is invented, it can be slotted in, as we have designed for crypto-agility. Also, we do not spell it out, but we do say that a DET may be used for only a single 'operation' (flight to us non-UAS operators). Thus a concerned implementor could use a fresh DET, making the exposure for only the duration of the operation. We do not spell this out, as there are other operational reasons for a UAS operator to constantly change DETs. Suggests adding the following text to Section 8 Security Considerations 8.1 Post Quantum Computing out of scope There has been no effort, at this time, to address post quantum computing cryptography. UAs and Broadcast Remote ID communications are so constrained that current post quantum computing cryptography is not applicable. Plus since a UA may use a unique HHIT for each operation, the attack window could be limited to the duration of the operation. Finally, as the HHIT contains the ID for the cryptographic suite used in its creation, a future post quantum computing safe algorithm that fits the Remote ID constraints may readily be added. 5. While an example when one UA physically steals UAS RID sender of another UA is clever, I think that such scenarios (physical security) are not in scope of IETF work. I believe that many others similar schemes can be invented, so I suggest to discuss physical security in a separate subsection of Section 9. Bob/ Proposed Text below: 9.1 Private key physical security The security provided by asymmetric cryptographic techniques depends upon protection of the private keys. It may be necessary for the GCS to have the key pair to register the HHIT to the USS. Thus it may be the GCS that generates the key pair and delivers it to the UA, making the GCS a part of the key security boundary. Leakage of the private key either from the UA or GCS to the component manufacturer is a valid concern and steps need to be in place to ensure safe keeping of the private key. Since it is possible for the UAS RID sender of a small harmless UA (or the entire UA) to be carried by a larger dangerous UA as a "false flag", it is out of scope to deal wtih secure store for the private key. Not related to security: Section 3.2: A self-attestation of a HHIT used as a UAS ID can be done in as little as 84 bytes when Ed25519 [RFC8032] is used, by avoiding an explicit encoding technology like ASN.1 or Concise Binary Object Representation (CBOR [RFC8949]). This attestation consists of only the HHIT, a timestamp, and the EdDSA signature on them. If no encoding is used then how extensibility is achieved? Bob: Extensibility is in the HHIT which includes the Suite ID (Ed25519/cSHAKE here). A different HHIT Suite ID will result in a differently structured self-attestation. None exist right now, so no attempt is made to consider what other results would look like. I also wonder how algorithm agility property is achieved for broadcast RID messages. Bob: As above the HHIT includes the Suite ID. Note that the HHIT is an extension of the HIT in rfc7401 that also provided algorithm agility through the included Suite ID. Out of scope. Nothing to do here....
- [secdir] Secdir last call review of draft-ietf-dr… Valery Smyslov via Datatracker
- Re: [secdir] Secdir last call review of draft-iet… Robert Moskowitz
- Re: [secdir] Secdir last call review of draft-iet… mohamed.boucadair
- Re: [secdir] [Last-Call] Secdir last call review … Michael Richardson
- Re: [secdir] Secdir last call review of draft-iet… Valery Smyslov
- Re: [secdir] Secdir last call review of draft-iet… Card, Stu
- Re: [secdir] Secdir last call review of draft-iet… Valery Smyslov
- Re: [secdir] Secdir last call review of draft-iet… shuai zhao
- Re: [secdir] Secdir last call review of draft-iet… Valery Smyslov
- Re: [secdir] [Drip] Secdir last call review of dr… Robert Moskowitz
- Re: [secdir] [Drip] Secdir last call review of dr… Valery Smyslov
- Re: [secdir] Secdir last call review of draft-iet… Card, Stu