Re: [Rats] Review of draft-ietf-rats-eat-01

Laurence Lundblade <lgl@island-resort.com> Tue, 16 July 2019 17:33 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 4370B120A90 for <rats@ietfa.amsl.com>; Tue, 16 Jul 2019 10:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 YrXz_EoeNq89 for <rats@ietfa.amsl.com>; Tue, 16 Jul 2019 10:33:09 -0700 (PDT)
Received: from p3plsmtpa12-06.prod.phx3.secureserver.net (p3plsmtpa12-06.prod.phx3.secureserver.net [68.178.252.235]) (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 BBD7B120112 for <rats@ietf.org>; Tue, 16 Jul 2019 10:33:09 -0700 (PDT)
Received: from [192.168.0.107] ([67.237.247.208]) by :SMTPAUTH: with ESMTPSA id nRK8hzF5QDaIgnRK8hT7Wt; Tue, 16 Jul 2019 10:33:09 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <D8B4A43F-8654-468F-8A93-9D8E44236784@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7F84049E-674B-4FAD-83B3-32A506F78281"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 16 Jul 2019 10:33:07 -0700
In-Reply-To: <D95316BE.E2E33%carl@redhoundsoftware.com>
Cc: "rats@ietf.org" <rats@ietf.org>
To: Carl Wallace <carl@redhoundsoftware.com>
References: <D95268DC.E2D3B%carl@redhoundsoftware.com> <5CBB3ED3-0CD6-443D-B80F-EE426F7905C3@island-resort.com> <D95316BE.E2E33%carl@redhoundsoftware.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfLJa4nGqteWsCBugl/ECsF/MbH9d0ExQK5ciW/6L9jd+h1T49qySng8I0xDbJp61COYprf1QCvodbxvo5tkpKAlMyqccJamFNy9w0d0z+ksYct8Tm1mq Vy+ZyTI4JXqweiYEwQCqitRikDg1pQPtzfW8Ze8jR6QAm+Pmbp0ogbs/V/VgC11ip+Z+SlDvtoQLryToDx7iKs3l9Zv2SjgTuaM=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/vx6isrQl4Ctv8l3DMhRU4gsKHhY>
Subject: Re: [Rats] Review of draft-ietf-rats-eat-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: Tue, 16 Jul 2019 17:33:12 -0000

below...

> On Jul 16, 2019, at 3:13 AM, Carl Wallace <carl@redhoundsoftware.com> wrote:
> 
> 
> From: Laurence Lundblade <lgl@island-resort.com <mailto:lgl@island-resort.com>>
> Subject: Re: [Rats] Review of draft-ietf-rats-eat-01
> 
>> <snip>
>>> Section 1.4.2 claims to not standardize the "end-end process of
>>> establishing signing attestation key material in the entity, signing the
>>> EAT, and verifying it". However, the election of COSE, for example, does
>>> standardize signing and verifying (see section 4.4 of RFC 8152). Also, the
>>> language here needs to reflect expansion to include JWT.
>> 
>> COSE, EAT and CWT do not mandate support for specific algorithms to the degree the interop is guaranteed. For example an entity could implement ECDSA and the relying party could implement the Edwards Curves. This is the intent of this sentence. 
>> 
>> I believe it is up to profile documents to lock this down for guaranteed interop
>> 
> 
> If the intent is to say algorithms are not specified, say that. This snip reads much more open ended to me than I think is intended. Not specifying algorithms is common.

It is also how the public key is obtained and trust in it is established. We have lots of choices including X.509 hierarchies, some web service, some new service… For example there are extensions to COSE in the works for X.509 now.


>>> Should 3.11 be 'nested EATs' or 'aggregated EATs'. In other words, are
>>> these really nested (like signed then encrypted or signed then
>>> countersigned) or are they aggregated into an array then signed? Should
>>> these be wrapped as a bstr (at least for CBOR)?
>> 
>> They really are nested. It says:
>> 
>>    The contents of the "eat" claim must be a fully signed, optionally
>>    encrypted, EAT token.
>> 
>> The nesting is really powerful as it allows multiple subsystems to make EAT tokens (a modern cell phone has lots of CPUs, often well isolated from each other) and for them to be combined and bound to each other.
> 
> 
> I understand that nesting is powerful and that encryption or other signatures can be applied later. However, the language here reads like aggregation of EATs from various subsystems into a larger composition. Is nesting really what we want there (vs nesting where additional cryptographic services are applied)? Even if nesting is appropriate here, is aggregation something we also want in the toolbox?

I think we want both aggregation and nesting.

To be sure it is clear, nesting means you take a fully formed and signed EAT token and put it in another fully formed and signed EAT token. One of the reasons this might happen is that a device (e.g. a car) is assembled out of multiple components that can’t be modified by the end manufacturer. Subcomponents are capable of generating EATs. Some final component (controlled by the car maker) puts them all together in one token for the car the signature of which binds all the sub tokens together.

The submods claim is the proposed way to do aggregation of claims where the subcomponent set of claims is not separately signed.


>> My thought is that they do not need bstr wrapping. It’s only inputs to hash functions that need that because of the way CBOR decoders work.
>> 
>> If you still think it needs bstr wrapping, please file a GitHub issue.
>> 
> 
> I'd like to hear from others as my consumption of CBOR is limited (but I did see some interop problems related to bstr usage). Given there are integrity checks in the embedded pieces, capturing as a bstr seems like the safe play to me, especially given the potential for differing encoding choices. It could be that all things that need to be bstr are already handled though. 

Yes, I think all things that need bstr are wrapped through compliance with COSE.


>>> In 4.4.1, suggest table presentation a la COSE spec.
>> 
>> That is CDDL. It should not be a table.
>> 
>> But latitude and such should have an “=“. I’ve filed an issue for that. 
> 
> 
> This is what caught my eye, but I like the COSE presentation better:-)

CDDL was not published when COSE was created so the CDDL in the COSE spec is non-normative. 

I am trying to do differently here and make the CDDL normative to specify the information model and allow the data model to be derived for CBOE and JSON.

I’ve fixed the missing “=“. Thanks for catching it.


> 
>>> - In section 3 fix formatting of bullets
>> 
>> The CDDL section header was wrong in 3.3.. Is that what you meant?
> 
> 
> I meant: "Note also: * Any claim defined for CWT or JWT may be used in an EAT
>    including those in the CWT [IANA.CWT.Claims <https://tools.ietf.org/html/draft-ietf-rats-eat-01#ref-IANA.CWT.Claims>] and JWT IANA
>    [IANA.JWT.Claims <https://tools.ietf.org/html/draft-ietf-rats-eat-01#ref-IANA.JWT.Claims>] claims registries.  * All claims are optional * No
>    claims are mandatory * All claims that are not understood by
>    implementations MUST be ignored"
> 
> Maybe it's presented this way to entice the reader to read it in a super fast legalese voice:-)

I’ve fixed this.

LL