[Rats] RATS Architecture
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 21 May 2020 13:35 UTC
Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C199E3A0CB1 for <rats@ietfa.amsl.com>; Thu, 21 May 2020 06:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 UZGWT97TeNZf for <rats@ietfa.amsl.com>; Thu, 21 May 2020 06:35:36 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621E63A0CAE for <rats@ietf.org>; Thu, 21 May 2020 06:35:36 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id x22so5508988otq.4 for <rats@ietf.org>; Thu, 21 May 2020 06:35:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Ff0mF+hFncJyvbJRo+1kn+AgIqn0WPWetcKj46YMR70=; b=TIp5EO/Gy+z8AY7W5ykKCXb3SgECWPPlJmUi4bae76oMsdcdcmpskRiUvURxw+LZRa qAjOJbx5MZXkDuWcLO0shHQEkMwwUyc8DGnekuvLGhwB27ylBtwaFFcXPuLsPyd7KZki hAEc1ALecviBIAagBxC7Zw6x4wgvJaxnLcABBBFDJxZ8qjx22d55nbCnUsmgkpbMD1dX amIBPHuBnc8k3W+2jopp3csyUS8jXEp+OKPoeTQZa7d7fE0oUgMba+MflwK4amZfg9p0 QVgOQCZep2aaxt9LrzHoAf2vvJfraK/N96UjwBspzOEe6wk539dPW+JKPN9XUUWetub/ 9cKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Ff0mF+hFncJyvbJRo+1kn+AgIqn0WPWetcKj46YMR70=; b=qgvwWcvC7Yxkp15sWDnuslnAQ7HlsUA4q0XUTE3zXv1ykALbBt2R48MrPfpYwKVwRH GNGGHW4QvRo52v5NuWb32lIFcCk2bEFBJSEdeMDK0WL5jslYZSTs5IOLqM+50KS8wX+9 YNc2o4lvXqC1dbXdu5q3KL81709riaPXUrOKFceW3tPguDaQGQxEFJfOEO2agzczzSsY fnhrBL9oNKLRXkdS0veVBCknGvWnlTGEF0Zzb3obZP4aodd3cD29u18FEKwTNKZCAhmv G29Qh5SEvGO3NLqBIvyPgCqIaZqbhVJdSvzgQmVRaldPrfDnDFhFT3QQpGPp2OAc0eO2 Jbaw==
X-Gm-Message-State: AOAM531gMDZYuPBswLJ7FbwY537j+eDsaqjb3/UTOcF35ADXtSLu5uol PC4u6MUxrETv23sPpyy98PZwhTcKN5LgbcVUULZ9Zaeg
X-Google-Smtp-Source: ABdhPJw+lVzq+LBLjAvcBqDzMXWxdxy+z8xFIFmHznE/mjcSZSwcbVXr7o3gjG24yslQLoWUDdYLT6BMEBmLY2xgd+M=
X-Received: by 2002:a9d:5d13:: with SMTP id b19mr7537783oti.151.1590068135084; Thu, 21 May 2020 06:35:35 -0700 (PDT)
MIME-Version: 1.0
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Thu, 21 May 2020 09:34:59 -0400
Message-ID: <CAHbuEH6f+MAQtyhL64C0gYJYbdX8N-Pzo1WkPqZ3xZXApPhMsg@mail.gmail.com>
To: rats@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005c48d205a6289629"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/2rwmcm7pQICXN8lzlX21lEkb9Is>
Subject: [Rats] RATS Architecture
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 May 2020 13:35:39 -0000
Greetings! I took some time to review the current version of the architecture document and have some comments and suggestions. The comments are from the editor's version. Please do post early and often updates to the IETF draft repository. Version numbers do not matter, it's okay to have a large number :-) These are meant to be helpful comments to improve the draft. Introduction: Could we change: From: Trust is a decision being made. To: To trust is a decision that spans beyond the technical assertions. I struggle a little with the following: "Trustworthiness is a quality that is assessed via evidence created." As when one determines trustworthiness, it may span beyond evidence that is "created". Perhaps drop the word created? I think it spans beyond that as well, but may be too nit picky to expand. The evidence could have to do with something other then the system and those who manage it for instance. Terminology: The following definition should be just for "appraisal policy" unless there are other types of appraisal policies in context for this body of work: Appraisal Policy for Attestation Result: A set of rules that direct how a Relying Party uses the Attestation Results regarding an Attester generated by the Verifiers. Compare /security policy/ in [RFC4949] I don't think direct is the right word. If this is so you can make judgments on relying party decisions, the policy is more of a statement on the decision process than how they are directed, which could be more subjective. The verifier here reads as if they generate the policy, but are verifying against a set policy. Proposed: A set of rules for a Relying Party to verify attestation results. The following 'definition' seems to get into role recommendations rather than being a definition: Attester: An entity whose attributes must be appraised in order to determine whether the entity is considered trustworthy, such as when deciding whether the entity is authorized to perform some operation Shouldn't this stick to what an attester is/does? Perhaps: attester - entity who puts forth data that may include configuration or static system information, evidence, or claims. The evidence may be digitally signed. For evidence, should this definition be more about what evidence is rather than about the roles involved? The attester may not be the same component or system that attests to the evidence as well. Evidence could be measurement data, telemetry (e.g. counters on a system interface - YANG or SNMP), results of a policy comparison to configuration data). Evidence: A set of information about an Attester that is to be appraised by a Verifier Perhaps: Evidence: Information about or originating from a system/firmware/software that may include configuration data, measurements, telemetry, or inferences. Is the following definition necessary? Verifier Owner: An entity, such as an administrator, that is authorized to configure Appraisal Policy for Evidence in a Verifier Section 3: Consider changing the following sentence: From: " Each use case includes a description, and a summary of what an Attester and a Relying Party refer to in the use case." To: " Each use case includes a description followed by a summary of the Attester and a Relying Party roles." Section 3.1: Sentence 1: Consider changing from: "Network operators want a trustworthy report of identity and version of information of the hardware and software on the machines attached to their network, for purposes such as inventory, auditing, and/or logging." To: "Network operators want a trustworthy report that includes identity and version of information of the hardware and software on the machines attached to their network, for purposes such as inventory, audit, anomaly detection, record maintenance and/or trending reports (logging)." In the following sentence, "health" is fine, but did you consider the more commonly used, "hygiene"? >From the editor's version: "Typically, solutions start with a specific component (called a "Root of Trust") that provides device identity and protected storage for measurements. These components perform a series of measurements, and express this with Evidence as to the hardware and firmware/software that is running." Perhaps better stated as: "Typically, solutions start with a specific component (called a "Root of Trust") that provides device identity and protected storage for measurements. The system components perform a series of measurements that may be signed by the Root of Trust, considered as Evidence of the hardware, firmware, BIOS, software, etc. that is running." "express this with" is confusing and possibly misleading. This proposed phrasing allows for evidence to be broader than the series of measurements as it might include system or configuration information. It's not the RoT that does the measurements, but they do attest to it. Would the attester in this example be the root of trust of the device rather than the full system? Section 3.2: Perhaps change the wording from: "A device manufacturer wants to protect its intellectual property in terms of the ML model it developed and that runs in the devices that its customers purchased, and it wants to prevent attackers, potentially including the customer themselves, from seeing the details of the model." To: "A device manufacturer wants to protect its intellectual property. This is primarily the ML model it developed and runs in the devices purchased by its customers. The goals for the protection include preventing attackers, potentially the customer themselves, from seeing the details of the model." I'm confused by the phrasing of the rest of the section and am wondering if it can be improved. Current: "This typically works by having some protected environment in the device attest to some manufacturer service. If remote attestation succeeds, then the manufacturer service releases either the model, or a key to decrypt a model the Attester already has in encrypted form, to the requester. Attester: A device desiring to run an ML model to do inferencing Relying Party: A server or service holding ML models it desires to protect" I think it would help to talk about inferences in the written description. For the attester, if it's the whole system as opposed to a component, then then definition makes sense. I'm wondering if it is crisper when narrowed. RoT captures inferences of the ML modeling used as evidence. Does the relying party hold the ML model or knowledge of expected inferences? I'm happy to propose alternative text once I have more information to more fully understand the use case. Section 3.3:This one took a couple of reads to understand. While it is understandable, it could be more explicit to make it easier to get on first read. How about changing the following From: Attestation is desired to prevent leaking data to compromised devices. To: "An assessment of system hygiene is made against a set of policies to verify the state of a system using attestations for the system requesting data. Attestation is desired to prevent leaking data to compromised devices." Section 3.6 Nit: From: "One significant problem is malware that holds a device hostage and does not allow it to reboot to prevent updates to be applied. " To: "One significant problem is malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. Remote attestation aids in the verification process that may occur locally as well as it is less likely that the policy or verification processes have also been compromised if hosted on a separate system." The second sentence is suggested as this also occurs locally on systems today, but there is value in having this via remote attestation. I'll send the next batch when I get far enough through the document. I didn't want to hold up on these comments. Thank you for all your work on the document! -- Best regards, Kathleen
- [Rats] RATS Architecture Kathleen Moriarty
- Re: [Rats] RATS Architecture Henk Birkholz
- Re: [Rats] RATS Architecture Michael Richardson
- Re: [Rats] RATS Architecture Henk Birkholz
- Re: [Rats] RATS Architecture Kathleen Moriarty