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

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Mon, 11 November 2019 18:23 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 16D2E1208C8 for <rats@ietfa.amsl.com>; Mon, 11 Nov 2019 10:23:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 GdWZ41ETdaaQ for <rats@ietfa.amsl.com>; Mon, 11 Nov 2019 10:23:12 -0800 (PST)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 C25D71208A4 for <rats@ietf.org>; Mon, 11 Nov 2019 10:23:10 -0800 (PST)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id xABIN1CG013895 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Mon, 11 Nov 2019 19:23:02 +0100
Received: from [192.168.16.50] (79.234.112.245) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Mon, 11 Nov 2019 19:22:56 +0100
To: "Smith, Ned" <ned.smith@intel.com>, "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com>, Laurence Lundblade <lgl@island-resort.com>, "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
CC: "rats@ietf.org" <rats@ietf.org>
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> <1C8A1884-A37D-45E3-8C11-2FC5A083B245@island-resort.com> <HE1PR0702MB375366C5F7FE5C497C35D73B8F740@HE1PR0702MB3753.eurprd07.prod.outlook.com> <7106C9D3-8ED1-419E-81F8-4CDA799BEDAE@intel.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <47faa9a4-9bb1-751f-2b5a-71e020659514@sit.fraunhofer.de>
Date: Mon, 11 Nov 2019 19:22:54 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <7106C9D3-8ED1-419E-81F8-4CDA799BEDAE@intel.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.234.112.245]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/24Vo4513flcwd17RmiDpKUoP8RY>
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: Mon, 11 Nov 2019 18:23:16 -0000

Laurence provided options as a basis for discussion a while ago.

He highlighted that CWT must be signed and illustrated pro & con wrt:

* null cipher,
* an "unsigned" flavor of CWT
* an "arbitrary signature"

It might be a valid assumotion that a single "tpm Claim" would have no 
significant added value, but multiple Claims in a message bundle might 
(although this might be a solution looking for a problem?).

Viele Grüße,

Henk

On 11.11.19 19:11, Smith, Ned wrote:
> Right. This implies the RATS “token” should support existing “binary” 
> formats as an encapsulation (signed by a second TA where the TPM is a 
> first TA) or as a conveyance (unsigned?) token. Possibly, the only added 
> value of the latter is a tag that identifies it as a TPM binary format?
> 
> On 11/10/19, 23:21 PM, "RATS on behalf of Oliver, Ian (Nokia - 
> FI/Espoo)" <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org> on 
> behalf of ian.oliver@nokia-bell-labs.com 
> <mailto:ian.oliver@nokia-bell-labs.com>> wrote:
> 
>> 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.
> 
> I would disagree with the statement of "short run" ... TPM is 
> practically the only existing standardised (hardware, software, 
> firmware, measurement - x86 only etc) hardware root of trust in common 
> use, ie: practically all x86 machines,  The attestation mechanisms 
> provided are going to be around for a very long time.
> 
>  From telco experience, 30 years ago we said SS7 would only be around in 
> the short term.
> 
>> 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.
> 
> Agree
> 
> Ian
> 
> -- 
> 
> Dr. Ian Oliver
> 
> Cybersecurity Research
> 
> Distinguished Member of Technical Staff
> 
> Nokia Bell Labs
> 
> +358 50 483 6237
> 
> ------------------------------------------------------------------------
> 
> *From:*Laurence Lundblade <lgl@island-resort.com>;
> *Sent:* 11 November 2019 00:44
> *To:* Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com>;
> *Cc:* Henk Birkholz <henk.birkholz@sit.fraunhofer.de>;; rats@ietf..org 
> <rats@ietf.org>;
> *Subject:* Re: [Rats] Call for adoption (after draft rename) for Yang 
> module draft
> 
>     On Nov 10, 2019, at 2:20 PM, Nancy Cam-Winget (ncamwing)
>     <ncamwing@cisco.com <mailto: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
>