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

Carl Wallace <carl@redhoundsoftware.com> Tue, 16 July 2019 10:14 UTC

Return-Path: <carl@redhoundsoftware.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 F10121201EF for <rats@ietfa.amsl.com>; Tue, 16 Jul 2019 03:14:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 DLWY0IpVr86c for <rats@ietfa.amsl.com>; Tue, 16 Jul 2019 03:13:58 -0700 (PDT)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 D89A6120229 for <rats@ietf.org>; Tue, 16 Jul 2019 03:13:57 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id 44so18851852qtg.11 for <rats@ietf.org>; Tue, 16 Jul 2019 03:13:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=ZizdiZbu1wda5I3ybBjygw08EMYLX7NAE5ZYvQARbl4=; b=FQc3fzTqyDQNJH2GjJz5I4KJdjGC+hISbOmzIgnyZLVhJWdgXatNnF/jWl0pTqDT4n 8DUZDkhWiMYFnQq6j6ULJ2fr9YmVAzuVnm6VbgGmxASKLLjO0iDWo0xmL2xWtFB/M2H+ rufhbfpzWgF6nXgeRMJyIHB8KIG2hLOV+yADY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=ZizdiZbu1wda5I3ybBjygw08EMYLX7NAE5ZYvQARbl4=; b=YTB4dU45EqGQXKhdRqUVgX/EPBaR3Tu+L54JhwSxRX8U/nmke7O1Y5Vb6PJy0OyodC X3pdjR1AhAdRDCCh7EiOUqCDuoAoGZ1MkU1mie4MmoMvJ5Q9K1dyM/P4Bsfft1gcoVQk 7zbTQwNk6/84aQ2H6H0eZQpj9TjtkYu41Wj7LITVdDP+r0x7CHnU5o1GkCW+xjWn0pOV WWsb+r23czO6lJUJgL/9Fi1FxrxkPox6Bsexeu1W6M+i+cwLHKUkf6z92I2ygpwiVR2P exIT1lntKo+4LODBbJnniJV+USINhcHcmE0flkNOqhXDtHBNcfZt1nYmZIcMsRqvqMbr D8Cg==
X-Gm-Message-State: APjAAAXneHLPudhGN59Z5AM5efjBgvNcxGVlxTg93qOopUeE9RvY1iuh baRYKN1GvFeZ7mU5s8E+Luc=
X-Google-Smtp-Source: APXvYqx/ki69C1isjuD+u0ApoQkRliU2wvFQYUF1XT5Qa2sXtovTY598XuUKr7hcvJnWoSGP+SLvog==
X-Received: by 2002:ac8:2409:: with SMTP id c9mr22174006qtc.145.1563272036819; Tue, 16 Jul 2019 03:13:56 -0700 (PDT)
Received: from [192.168.2.105] (pool-96-255-231-27.washdc.fios.verizon.net. [96.255.231.27]) by smtp.googlemail.com with ESMTPSA id p59sm10019817qtd.75.2019.07.16.03.13.54 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 16 Jul 2019 03:13:56 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.7.6.170621
Date: Tue, 16 Jul 2019 06:13:48 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Laurence Lundblade <lgl@island-resort.com>
CC: "rats@ietf.org" <rats@ietf.org>
Message-ID: <D95316BE.E2E33%carl@redhoundsoftware.com>
Thread-Topic: [Rats] Review of draft-ietf-rats-eat-01
References: <D95268DC.E2D3B%carl@redhoundsoftware.com> <5CBB3ED3-0CD6-443D-B80F-EE426F7905C3@island-resort.com>
In-Reply-To: <5CBB3ED3-0CD6-443D-B80F-EE426F7905C3@island-resort.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3646102436_33229903"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/IMVUCg2-d0MvW8eQmKMh5NrsDrU>
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 10:14:01 -0000


From:  Laurence Lundblade <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.
> 
>> Section 2 feels incomplete without a definition of claim (as in JWT and
>> CWT, which include similar definitions as here plus claim) and attestation
>> (given definition of Attestation Key Material). CWT Claims Set should
>> probably be renamed Claims Set given expansion to include JWT.
> 
> Since an EAT is just a CWT or JWT now, I was thinking the definition from CWT
> and JWT just carries over.

The other three were in one or both as well. The absence of claim felt like
a gap, but it's obviously not a big deal either way
> 
> <snip>
>> 
>> 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?

> 
> 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.
> 
>> 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:-)
>> 
>> In 4.4.2, are nested EATs allowed to make different encoding choices?
> 
> Yes
> 
> 
>> 
>> Throughout the draft, should and must are used in many places where SHOULD
>> or MUST is probably applicable. Examples include:
>> 
>> - In section 3.1, the should should be SHOULD
>> - In section 3.6, the must instances in bullets 3 and 4 could be MUSTs
>> - In section 3.11, the must should be MUST
>> - In section 4.3.2, the must instances in bullets 3 and 4 should be MUSTs
>> - In section 4.4.2, the must in the last sentence of the second paragraph
>> should be a MUST (and it may be helpful to enumerate 'all' here)
>> - Throughout 4.4.2, there are several instances of 'the server must'.
>> These must instances should probably be MUSTs and 'the server' should
>> probably the 'the relying party'.
>> - In 5.1, the should should be SHOULD
> 
> You must use the word should and should use the word must as many times as
> possible in a sentence. :-)
> 
> I’ve heard different philosophies on this and tended to the more mellow ones
> that imply. I’ve filed an
> Issue to resolve this.

I always thought this was drawn along points where interop was relevant and
I tried to limit the places I cited to those.

> <snip>
>> Typos
>> - In the intro change "very small IoT device" to "very small IoT devices”
> 
> That is from the -00 draft. It is not in the -01 draft.
Yes, I started reading the wrong one. I'm surprised I only missed this
comment when I realized I started with the wrong draft.
>> - 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:-)
> 
> LL
> 
> 
> 
> 
>> 
>> 
>> _______________________________________________
>> RATS mailing list
>> RATS@ietf.org
>> https://www.ietf.org/mailman/listinfo/rats
>> 
>