Re: [Rats] Call for adoption (after draft rename) for Yang module draft

Laurence Lundblade <lgl@island-resort.com> Sun, 10 November 2019 22:44 UTC

Return-Path: <lgl@island-resort.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 CDC361200FD for <rats@ietfa.amsl.com>; Sun, 10 Nov 2019 14:44:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 eAbVAj_f4BbA for <rats@ietfa.amsl.com>; Sun, 10 Nov 2019 14:44:32 -0800 (PST)
Received: from p3plsmtpa08-04.prod.phx3.secureserver.net (p3plsmtpa08-04.prod.phx3.secureserver.net [173.201.193.105]) (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 73B54120044 for <rats@ietf.org>; Sun, 10 Nov 2019 14:44:32 -0800 (PST)
Received: from [192.168.1.80] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id TvwdiEP0sPReBTvwdiHQBZ; Sun, 10 Nov 2019 15:44:32 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <1C8A1884-A37D-45E3-8C11-2FC5A083B245@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6241C201-BAE3-4BE2-84CB-E0E55579358A"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Sun, 10 Nov 2019 14:44:31 -0800
In-Reply-To: <C3AE2645-49C8-4313-BCED-02FEB576B614@cisco.com>
Cc: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "rats@ietf.org" <rats@ietf.org>
To: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
References: <8B173958-FC2A-4D1D-A81C-F324AB632CD7@cisco.com> <147F9159-6055-4E55-ABDC-43DFE3498BF1@island-resort.com> <ce5f8206-74dc-36bb-0093-a93045d5c67f@sit.fraunhofer.de> <0A7E3A4F-8534-4E98-BCB7-1454E07699F4@island-resort.com> <C3AE2645-49C8-4313-BCED-02FEB576B614@cisco.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfJGV1EwpNeq54NlHJ9zcbuxeem7xcHoT/ALikSufl9KqPY3jfCwYATkpYXryOva6Wk4javCNhXifrHpdc3n9Uce8lPV+3BTbyWoSGmz9L2JxmEjaH9Q+ 30VwGLOR5o/r97SFjZYiSZwKseMpSm4c6aq6M3/FAX+EeDpDu6uv7/PDhy0yuPs9RcZgIc0PQXGUs/V+/HSQO6ZqtFq2KzUwo4QAJ/c80N3nIcixAS9upd43 KifrDZc3WQdpG6P2CPwocA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/UdojChWVUHfO0lZFzF0aWQjUKjE>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft
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: Sun, 10 Nov 2019 22:44:34 -0000

> On Nov 10, 2019, at 2:20 PM, Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com>; wrote:
> 
> So, Laurence, are you still OK with the adoption of the current draft with a rename for now?
> Thanks, Nancy

I think the value add to the larger RATS effort of adding EAT support to this YANG protocol is really high. It a core thing to do that helps bring together the two attestation worlds and make the TPM and EAT work here less like ships in the night.

Remote TPM attestations are useful and necessary the short run, but are of very limited capability. I believe that EAT will replace TPM attestations in the long run (maybe decades) because they are far more expressive. I know others believe that too. 

If we don’t include EAT in the YANG mode it is sort of like defining HTTP to only convey HTML to the exclusion of PDF. We’re defining an attestation protocol that can only move one kind of attestation even though we have consensus on what the other one looks like.

It seems relatively simple to add EAT support (or promise to add EAT support). Pretty sure I heard Henk agree to add it.

Thus, I am opposed to adoption with the current TPM-only draft. I’d be OK with the current draft and a promise to add EAT to it.

LL