[Rats] RATS use cases review

Jessica Fitzgerald-McKay <jmfmckay@gmail.com> Wed, 10 July 2019 17:54 UTC

Return-Path: <jmfmckay@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 C6A7C120398 for <rats@ietfa.amsl.com>; Wed, 10 Jul 2019 10:54:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.297
X-Spam-Level:
X-Spam-Status: No, score=0.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 XAkkj_uKckgt for <rats@ietfa.amsl.com>; Wed, 10 Jul 2019 10:54:27 -0700 (PDT)
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 15C16120391 for <rats@ietf.org>; Wed, 10 Jul 2019 10:53:53 -0700 (PDT)
Received: by mail-oi1-x233.google.com with SMTP id g7so2316569oia.8 for <rats@ietf.org>; Wed, 10 Jul 2019 10:53:53 -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=vzSOjUbYT5jeYmbg9F0rtwBkY5D57pf6xUL+zjpRZlY=; b=aNqzKn9WNMqDLte6fqL3W7Pub72fRTnKX8ODF9kv5aze5sukSr+/XgWVAd1S1LDco7 L/0hXX8EtruR9JAXDR798drigIXTxD2NCvhHBupcHFDE6TYONgCXJYvNo2JkUiRZ1o9A lr60eVB25IESzxFaHLoLzk6QNNO1OwKmUVIdRpsjbENti5L7IC8jevI8AYzbz3G3mx8G do/+bg5Uvsu6gQTTs7BpaXarLGkAUMdsl6IKFAFuq9C/07wxaYQBI/T/QCsjcBHcqIcu je7j0eBjIA8K9PcorZBEDLqhcjAEjp9PEJ9yhYHXFwOneauYBARRh1J/HARC9RjBCkiS NaSA==
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=vzSOjUbYT5jeYmbg9F0rtwBkY5D57pf6xUL+zjpRZlY=; b=a4mmqBCfBaDVX1YOxckc+Rs2OxZxqkGCvijUZm7EFXC3xaJ+6/zAlluIPpah9VBON6 meNPH6SnWXesSDJ4M2xWhNkh9X4b0j3zSLcanblP2t94jPV6bDOwZNHiXsRRi95ykExj JyX7nhf1EouK8HDppkfKTGvvekiLg6kWU46RUBeBZqv+1hnRSpFw/hrgeOTf6cNQQMSx 8NkO691JG0dpPXmnomkJJn7Vq7vL2BehAtJj17LueQ4aSNcaQ5paP+v/gXApv7CvbgcL y++VNU/AIJ1j5mC07hAJCBk4piSE7ni3OsRsYuCiT1Nc+xon8FHOdFzfW9jUm5Ar6/sG RGXw==
X-Gm-Message-State: APjAAAVWVfnghLYmBYFFEff+UKWZSlw+BrsbaiCcpMcIxZZqcJH2lSjj QyF6RRIGuztvwhteg2zyw8SE9RF5p40rzwCoBHsuHClobGQ=
X-Google-Smtp-Source: APXvYqxc3qK/5kj1aGaW9VzgRIydtU1Ey5oD05KcLiSLLnToz9uGRJFl8XPOfzb3wPuPLuF2TQXudSWrXSYwPjMoAX8=
X-Received: by 2002:a05:6808:8c2:: with SMTP id k2mr4029293oij.98.1562781231973; Wed, 10 Jul 2019 10:53:51 -0700 (PDT)
MIME-Version: 1.0
From: Jessica Fitzgerald-McKay <jmfmckay@gmail.com>
Date: Wed, 10 Jul 2019 13:53:41 -0400
Message-ID: <CAM+R6NW1KSf3ziAp8TqnTNwS+a7Y+4TuTDTPVZC8Ae32noXMYA@mail.gmail.com>
To: rats@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003188f5058d575c39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/XcdBlRWeig292FUrwAwYuL_m2Qw>
Subject: [Rats] RATS use cases review
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: Wed, 10 Jul 2019 17:54:29 -0000

Hello, all,

I  took a careful read of the use cases document. I notices that Sections
5.1 - 5.6.2 each are variations on the themes of attesting to a device's:

- identity
- hardware inventory
- software inventory
- firmware
- configuration

Section 5.1 is fairly explicit about that.

Section 5.2 seems to be describing a particularly reslient remediation to
hardware/software vulnerabilities (presumably discovered via a device's
hw/sw attestation?).

Sections 5.3 and 5.4 are concerened with the configuration of a device's
hardware or software TEE.

Section 5.5 describes how these forms of attestation are directly
applicable to critical infrastructure. While I am sure there will be
protocol restrictions for that type of device, the idea of what is being
attested to is the same here as it is for other device types.

Section 5.6.1 seems to be relatively the same as the TEE/ML use cases. And,
5.6.2 admits to being essentially a subsection of the same.

In this light, the right approach is to organize the document around the
information that is being attested (the above list, plus end-user
information (section 5.6.3), geographic attestation (section 5.7), and
connectivity attestation (section 5.8)), with perhaps additional
information on how these types of attestation can be combined in support of
things like, say, critical infrastructure security, etc.

What does the work group think?

Thanks,
Jess