Re: [Rats] Review of draft-birkholz-rats-uccs-01

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Mon, 17 August 2020 10:39 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 B6B9B3A0A9D for <rats@ietfa.amsl.com>; Mon, 17 Aug 2020 03:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Level:
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-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 uCkXnMv7rfaV for <rats@ietfa.amsl.com>; Mon, 17 Aug 2020 03:39:03 -0700 (PDT)
Received: from mail-edgeS23.fraunhofer.de (mail-edges23.fraunhofer.de [153.97.7.23]) (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 C35773A0AA8 for <rats@ietf.org>; Mon, 17 Aug 2020 03:39:00 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2FMCQDuXDpf/xwBYJlfHQEBPAEFBQECAQkBFYFMgxiBMwqELZEjnAkLCwEBAQEBAQEBAQYBARgLCgIEAQEChEoCgk0BJDgTAhABAQYBAQEBAQYEAgKGRQyDU4EDAQEBAQEBAQEBAQEBAQEBAQEBARYCQ1USAR8BAQEDAQEhDwEFNhsJAhACBgICJgICJyACDgYBDAYCAQGDIgGCewULkzSbeoEyhVKDS4E6BoEOKgGGUIZMD4FNP4ERJw+CWj6CXAEBhHaCYASSf5I+kEgqB4FbgQqBCQQLmHwFCh6DAIlcBYR/Bo47kjmfPwIEAgkCFYFqgXtNJE+CaVAXAg2XJIVEcjcCBgEJAQEDCXyNbi2BBgGBEAEB
X-IPAS-Result: A2FMCQDuXDpf/xwBYJlfHQEBPAEFBQECAQkBFYFMgxiBMwqELZEjnAkLCwEBAQEBAQEBAQYBARgLCgIEAQEChEoCgk0BJDgTAhABAQYBAQEBAQYEAgKGRQyDU4EDAQEBAQEBAQEBAQEBAQEBAQEBARYCQ1USAR8BAQEDAQEhDwEFNhsJAhACBgICJgICJyACDgYBDAYCAQGDIgGCewULkzSbeoEyhVKDS4E6BoEOKgGGUIZMD4FNP4ERJw+CWj6CXAEBhHaCYASSf5I+kEgqB4FbgQqBCQQLmHwFCh6DAIlcBYR/Bo47kjmfPwIEAgkCFYFqgXtNJE+CaVAXAg2XJIVEcjcCBgEJAQEDCXyNbi2BBgGBEAEB
X-IronPort-AV: E=Sophos;i="5.76,322,1592863200"; d="scan'208";a="19689332"
Received: from mail-mtaka28.fraunhofer.de ([153.96.1.28]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Aug 2020 12:38:58 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DKBgBzXTpf/1lIDI1fgQmDdHADVDAsCoQtkSOcFAsBAwEBAQEBBgEBGAsKAgQBAYRMAoJLAiQ4EwIQAQEFAQEBAgEGBG2FXAyFcgEBBAEBIQ8BBTYbCQIQAgYCAiYCAicgAg4GAQwGAgEBgyIBgwALkyGbeoEyhVKDQIE6BoEOKoZRhkwPgU0/gREnD4JaPoJcAQGEdoJgBJJ/kj6QSCoHgVuBCoEJBAuYfAUKHoMAiVwFhH8GjjuSOZ8/AgQCCQIVgWojgVdNJE+CaVAXAg2XJIVEQTE3AgYBCQEBAwl8jW4tgQYBgRABAQ
X-IronPort-AV: E=Sophos;i="5.76,322,1592863200"; d="scan'208";a="32887733"
Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaKA28.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Aug 2020 12:38:55 +0200
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 07HAcsDc006961 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Mon, 17 Aug 2020 12:38:55 +0200
Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 17 Aug 2020 12:38:49 +0200
To: Russ Housley <housley@vigilsec.com>, "rats@ietf.org" <rats@ietf.org>
References: <F23B6DE1-3343-4553-AF1C-832EA7B7B238@arm.com> <27435.1575305487@localhost> <CAHbuEH7t7qAiDRBOrRL0inqzB4htvyyPBrd-iT3kKcFN1=PdQg@mail.gmail.com> <F7783A24-302A-4D6B-9030-9AFAD71E4597@intel.com> <19794.1575378270@localhost> <6a18b426-b11f-82e5-8758-93f79360b2a4@sit.fraunhofer.de> <40A05013-D12A-4D16-9FE9-2E97D5D8EF90@intel.com> <27974.1575407275@localhost> <BCBEE59A-E4A2-46CA-9A3B-05EC23522524@intel.com> <ACBD1E64-D88B-452C-A045-7841F023F685@vigilsec.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <bfe3d329-f416-c3b7-d357-be95be5e615f@sit.fraunhofer.de>
Date: Mon, 17 Aug 2020 12:38:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <ACBD1E64-D88B-452C-A045-7841F023F685@vigilsec.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.206.156.41]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/vizlvHuBUETKkGBFDVI2tvtdUOE>
Subject: Re: [Rats] Review of draft-birkholz-rats-uccs-01
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, 17 Aug 2020 10:39:07 -0000

Thank Russ!

we will discuss all feedback as soon as we find a time for an author's 
meeting. Sorry for for the latency, I was out-of-office for a while.

Viele Grüße,

Henk

On 30.07.20 22:45, Russ Housley wrote:
> # Major Concerns
> 
> In Section 3.1, the re are two MUST requirements, but they are not presented clearly.  The are:
> 
>     1)  The secure channel MUST authenticate the Verifier to the Attester.
> 
>     2)  The secure channel MUST protect the integrity of the communications from the Verifier to the Attester.
> 
> The way it is written also requires integrity protection in both directions.  Is that really needed?
> 
> In Section 3.1, says:
> 
>     Further, the provider of the UCCS SHOULD be
>     authenticated by the reciever to ensure the channel is truly secured
>     and the sender is validated.
> 
> I do not understand what this is trying to say beyond the MUST requirement above.  Maybe part of the problem is the mixing of the discussion about authentication and integrity.
> 
> In Section 3, when talking about confidentiality, I think that it would be better to say:
> 
>        If confidentiality is also required, the secure channel SHOULD mutually authenticate Verifier and the Attester.
> 
> 
> # Minor concerns
> 
> In section 1, the phrase "Secure Channel provides the correct properties" is a bit troublesome.  The properties are not difficult to explain in a sentence or two, so they should just be stated here.  Also, the sentences that follow can be omitted if you simply include in the summary of the "correct properties" that the party sending the UCCS is authenticated.
> 
> In Section 1.1, please add Verifier and Attester the the terms that are defined.
> 
> 
> # Nits
> 
> General: Why are Claim and Secure Chanel capitalized?
> 
> In section 1.1, please add a reference for the CWT Claims Registry.
> 
> In section 2, please add a reference for a device's trusted execution environment (probably the TEEP architecture draft).
> 
> 
> Russ
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>