[secdir] Security directorate review of draft-ietf-rats-eat-13
Hilarie Orman <hilarie@purplestreak.com> Fri, 15 July 2022 23:09 UTC
Return-Path: <hilarie@purplestreak.com>
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 DAFC9C13C519; Fri, 15 Jul 2022 16:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.928
X-Spam-Level:
X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 fJf0yEggr_p3; Fri, 15 Jul 2022 16:09:17 -0700 (PDT)
Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A97CC159490; Fri, 15 Jul 2022 16:09:17 -0700 (PDT)
Received: from in01.mta.xmission.com ([166.70.13.51]:33734) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <hilarie@purplestreak.com>) id 1oCUQt-00Gots-ST; Fri, 15 Jul 2022 17:09:15 -0600
Received: from [166.70.232.207] (port=32103 helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <hilarie@purplestreak.com>) id 1oCUQr-00CfAn-M6; Fri, 15 Jul 2022 17:09:15 -0600
Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 26FN5QfV014526; Fri, 15 Jul 2022 17:05:26 -0600
Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id 26FN5Q0j014525; Fri, 15 Jul 2022 17:05:26 -0600
Date: Fri, 15 Jul 2022 17:05:26 -0600
Message-Id: <202207152305.26FN5Q0j014525@rumpleteazer.rhmr.com>
From: Hilarie Orman <hilarie@purplestreak.com>
Reply-To: Hilarie Orman <hilarie@purplestreak.com>
To: To: iesg@ietf.org, secdir@ietf.org;
Cc: draft-ietf-rats-eat.all@ietf.org
X-XM-SPF: eid=1oCUQr-00CfAn-M6; ; ; mid=<202207152305.26FN5Q0j014525@rumpleteazer.rhmr.com>; ; ; hst=in01.mta.xmission.com; ; ; ip=166.70.232.207; ; ; frm=hilarie@purplestreak.com; ; ; spf=pass
X-XM-AID: U2FsdGVkX1/2hPh1HYfqYt/xT811qmzt
X-SA-Exim-Connect-IP: 166.70.232.207
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ***;To: iesg@ietf.org, secdir@ietf.org
X-Spam-Relay-Country:
X-Spam-Timing: total 1632 ms - load_scoreonly_sql: 0.08 (0.0%), signal_user_changed: 12 (0.7%), b_tie_ro: 10 (0.6%), parse: 0.89 (0.1%), extract_message_metadata: 4.8 (0.3%), get_uri_detail_list: 1.83 (0.1%), tests_pri_-1000: 2.7 (0.2%), tests_pri_-950: 1.41 (0.1%), tests_pri_-900: 1.11 (0.1%), tests_pri_-90: 200 (12.3%), check_bayes: 199 (12.2%), b_tokenize: 7 (0.4%), b_tok_get_all: 8 (0.5%), b_comp_prob: 3.0 (0.2%), b_tok_touch_all: 177 (10.8%), b_finish: 0.98 (0.1%), tests_pri_0: 1395 (85.5%), check_dkim_signature: 0.55 (0.0%), check_dkim_adsp: 37 (2.3%), poll_dns_idle: 29 (1.8%), tests_pri_10: 2.2 (0.1%), tests_pri_500: 9 (0.6%), rewrite_mail: 0.00 (0.0%)
X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000)
X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/pHag-WP-Zkqo-Yvzv_RdXDfSGsM>
Subject: [secdir] Security directorate review of draft-ietf-rats-eat-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 15 Jul 2022 23:09:21 -0000
Security review of The Entity Attestation Token (EAT) draft-ietf-rats-eat-13 Do not be alarmed. I generated this review of this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the encoding of tokens holding data about "an entity, a device, some software and/or some hardware." The data are called "claims". The claims are for "authenticating, identifying and characterizing implementations where implementations are devices, chips, hardware, software and such." In the provided examples, the claims are generally relevant to the security status of an entity. In short, the document says that an entity may make security claims about itself, another entity can sign those claims (and others that it cares to tack on), and a third entity can then verify the signature and assume that the claims are correct. It is difficult to fathom the expected use environment, though. Why should the third party assume that the signer is trustworthy? Why is it trustworthy for evaluating the claims of the first party? What are the responsibilities of the signer? How does the relying party let the other parties know what attributes it needs? How are these trust relationships discovered, maintained, updated, revoked, etc.? In this scheme, devices, be they hardware of software, must have a universal identifier installed by the manufacturer. The draft notes that this is a privacy problem and suggests several ways around it. I cannot determine if the identifier is a required "claim" or not. The only required claim that I saw was the nonce, but the UEID occurs in all examples. The document seems to imply that relying parties need a guarantee that the UEID is unique. There is an appendix that purports to calculate the collision probability of the universal identifier string (UEID) based on the number of bits. The calculation only makes sense if the UEIDs are chosen with uniform randomness. This onus is apparently on the entity manufacturer. The probability of this being done correctly is lower than the chance of a collision if it were done correctly. There is a "claim" that occurs frequently in the examples that has the name "security level". The document notes that it has no clear meaning, but it has three possible values (which are not "low", "medium", and "high"). There really should be a different name for this, something like "special defenses" or "vague resistance descriptor". The document asserts that it defines "a network protocol for proving trustworthiness to a Relying Party." I'm not sure that it is a protocol (and it does not "prove" trustworthiness). It seems to be only a format for describing some particular attributes that may or may not be relevant to trusting a device. The first example, Simple TEE Attestation, has a typo of "manfests" for "manifests".
- [secdir] Security directorate review of draft-iet… Hilarie Orman