Re: [Rats] AD Review of draft-ietf-rats-architecture-15

Thomas Fossati <> Mon, 09 May 2022 10:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96845C159823 for <>; Mon, 9 May 2022 03:46:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qCNwUjp7BzPJ for <>; Mon, 9 May 2022 03:46:29 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 37E1EC159821 for <>; Mon, 9 May 2022 03:46:29 -0700 (PDT)
Received: by with SMTP id d15so14552325lfk.5 for <>; Mon, 09 May 2022 03:46:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fC4JmuAwnE2PNu5ICXkL8vcmst6m+jyzuwWDwzazCJA=; b=pXMCYU8mH4mSX+UTHRo6DYHWDyPeiGn0fRiDbImKji/Z45EeG0/DDYG0rQ3U4m5PHB Mj71jzVFCSc8u8/NQLG7YpWNZCoqoglzKWYLlCPEdDC/wsCi7gSgIFzYBsS7/laDFNot TqfnJc4lxgse/Ug5xzIEB9bkj4VLgJK8sJZJWTRFAlH0fZ6fX5UY9capuc3jIsOyxnWb AeB8fClaDPOatzfKQmk4L+P8n9+hIhyU3yeKth4Kh24G9rplLPW76OjJH950EPZ7Ahwp hKMVGJmMrUKEAyeB+1nPYKMuN8dVx6ana2o2zk6tjgjg7yiAdIIeLC7qd+YqC3tdNCcU /Dhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fC4JmuAwnE2PNu5ICXkL8vcmst6m+jyzuwWDwzazCJA=; b=3A0TimwOa8ynLS8JeuQH0Rqzxf1HFn1+Gm0s3Jyp7DkWWjmmAWFU97wWCL/KBVtuvP eNfD+rDUGtdCKEaJL8w5datK9SR9Iu06WFEmrdNmXmBQv9cI1V1hiw0EZ+SlnyhPg+iR KalPMsWgLBrX1KEPupPR6+k0o4UZlHAEfI8MlzsZf44S4mk0EcBWKztq00RKwvg4AnlL 1/2QWb6OjtMFpq953bkyk49fa9gdS2oXU1rm/uozO5sQ5WiYBJ7NweSJSAFotM+ja1zh p6KRiUz9G4kKLNzmzSqpYX9N5ztnskNO4FbYs+suwQQHPHCoqPQGVH4Fo6d81UhVQT1Y ALSw==
X-Gm-Message-State: AOAM530ZC16OkR43IJBEYeqNNuZBfshPp9/rkXgeocMtsFL0PQ9j+9lB OhNN2QCJC2k0TT/s76BYOhfyKZrKa0Vn2mxLCKDQXi4d
X-Google-Smtp-Source: ABdhPJw++7VDLLjQ6TEZTGulVGNKU2eWvikwHVSydn/1yfU7ZE4PjOfS+qYBh5kEydZBhS0kgfWSGJeGARbtI1Yu3iA=
X-Received: by 2002:ac2:4c8c:0:b0:472:80f:bc6c with SMTP id d12-20020ac24c8c000000b00472080fbc6cmr12497753lfl.541.1652093187246; Mon, 09 May 2022 03:46:27 -0700 (PDT)
MIME-Version: 1.0
References: <BN2P110MB110748C2C81E515E5E7277C5DCC09@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
In-Reply-To: <BN2P110MB110748C2C81E515E5E7277C5DCC09@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
From: Thomas Fossati <>
Date: Mon, 09 May 2022 11:46:15 +0100
Message-ID: <>
To: Roman Danyliw <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Rats] AD Review of draft-ietf-rats-architecture-15
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Remote ATtestation procedureS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 May 2022 10:46:29 -0000

Hi Roman,

Thanks a lot for your review.

On one point, since you explicitly ask for WG feedback:

On Tue, May 3, 2022 at 10:54 PM Roman Danyliw <> wrote:
> [Roman's comment on -13]
> I found the level of detail on this section on freshness out of place and inconsistent with the level of abstraction found in the rest of the test.  In most other section, generic interaction of roles, artifacts, their associated topologies, and high level security properties was noted.  This section delves into specific implementation choices.  In particular, is the WG sure that it needs all of the details of Section 10.3.  Even among all of the Section in 10.*, this stands out. It doesn't seem to provide enough detail to be create interoperability but goes beyond simply introducing the concept.
> [Roman's comment on -15] Thanks for the extra paragraph to explain why this section is here.  I will confess that I still don't understand why these details are here and stand by my original comment.  It's much more than I would have expected for an architecture (especially considering the extra material in Section 16/Appendix -- 10 pages/almost 20% of the document is devoted to time issues).  If the WG feels like it needs it, I won't push back.  However, if this is the watermark of the level of detail, let's make sure that there is equal treatment for other security issues too.  See my feedback on Section 12.

Section 10 really helped me understand the role of freshness in
attestation and why it is so fundamental (e.g., WRT updates of the TCB
software, binding attestation to secure channel establishment, etc.)
Besides, the Epoch-Id discussion (including the security
considerations in § 12.3) provides a pretty good introduction to a
concept for which I could not find alternative references.
On the practical side, it has helped me to design better APIs.  So, I
reckon both the content and the level of detail are fine as-is, at
least for me.