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

Michael Richardson <> Tue, 24 May 2022 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 454F6C15E6F4 for <>; Tue, 24 May 2022 09:34:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.556
X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-1.857, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (public key: not available)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s5RcOPtqeK3A for <>; Tue, 24 May 2022 09:34:46 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 13CAEC14F692 for <>; Tue, 24 May 2022 09:34:31 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2BB238E35; Tue, 24 May 2022 12:48:53 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id EUn88ADS5B7h; Tue, 24 May 2022 12:48:49 -0400 (EDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 52FCA38E2A; Tue, 24 May 2022 12:48:49 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1653410929; bh=A6pabEdIvpZRb//TqL1lHtv2VY2bR4hEjPC1Ghbtl9A=; h=Date:From:Subject:To:References:In-Reply-To:From; b=CVZinsHgT8Z4fuO388dIsK2nJodluyRsO+5UfDVV090Z901b+KOPz9OtgdLKpcnba 4/+fi7/JWH+hAhy7Da+McRRTk4Zyy3HM0TEcAOeJsAOWQWPO2a5jm7JCwyr0rH9okt HwshCXChutODvORTQ+rA+a18KA3DBYK5cD3tm5OHQHBrrFweeGkUy0TQmkvnMGFs5b sztJXjhlYy3ys7M2LUCnjnxnAf4UktY20p0HYuZFp7meH5NgBNQnlqjozQQebunaMJ zk6lEobLfldoIduPqIsOeersB8vogD2rCw6ch6LQpI+Tt8/qXfflhAFV8bjuJNeJTS /LooZMfqUpGfg==
Received: from [] (localhost []) by (Postfix) with ESMTP id 01E303C3; Tue, 24 May 2022 12:34:26 -0400 (EDT)
Message-ID: <>
Date: Tue, 24 May 2022 12:34:25 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1
From: Michael Richardson <>
References: <BN2P110MB110748C2C81E515E5E7277C5DCC09@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <3256.1651680451@localhost>
Content-Language: en-US
In-Reply-To: <3256.1651680451@localhost>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------ejMN0zVTbi676ZrVBHOkC0aw"
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: Tue, 24 May 2022 16:34:51 -0000

Roman, we have published a -16 version as an intermediate reply to the 
issues.  Please see the diff at:

We have closed a few issues with some pull requests, which I will list.
Some other issues we have decided to reply by email only.
I will move the issues which are still open to the end of the email.

On 2022-05-04 12:07, Michael Richardson wrote:
>      > ** Section 8.1.
>      > [Roman's comments on -13]
>      > In the spirit of inclusive terminology please use alternative phrasing
>      > for "man-in-the-middle attackers".
> If only there was some document that proposed more precise, modern
> terminology here.

We have replaced this term with "active on-path attacker", but also 
having noted that the text makes the read/write/modify intention clear.

>> ** Section 10 - Freshness
>> 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.

As demonstrate by two replies from Eric and Thomas, and repeated 
discussions, we think that the WG does need it.    We agree that the 
level of detail is uneven, but that is because other design issues are 
not so easily abstracted.

>> ** Section 12 - Security Considerations

This issue asks about why the Security Considerations seems silent on:

o Endorsers and endorsements?
o Reference values?

so, we noted that in fact the WG is constrained (up to next week) to 
dealing with these issues by charter, and that you noted that at least 
some documents that deal with these issues would have to wait for the 
recharter to finish :-)

We think that there may be other work that we could cite here, 
particularly around the third point:
"What is the implication of combining roles into a single entity as 
described in Section 3.4 and 6. Does this lack of separation present any 
additional issues?"

but, we don't think that there is anything significant we can say in the 
architecture document.  We reluctantly defined endorsers/endorsements 
and reference values, mostly so that we can rule them out of scope for 
this iteration of the architecture.  We did say that an attack on the 
appraisal policies (which includes RV and endorsements) is an attack of 

In the end, we don't think that there is a lot more to say here.

>> ** Section  Editorial.
>      > [Roman's feedback on -13]
>      > The section title of "Integrity Protection" seems narrow given the
>      > content of this section.

We changed the title to _Conceptual Message Protection_

>      > ** Section 12.4.
>      > [Roman's feedback on -13]
>      > Since RFC5280 is being invoked here, is there an expectation that
>      > certificates in RATS would confirm to this profile?

We made a slight text change to make the reference less prescriptive.
This is after all a non-normative, Informational, architecture document.

>> ** Section 5 -- Topological Patterns

We made a few small changes.
You asked:

> Figure 5. Shows the Attester consuming Attestation Results
> Figure 5. Shows the Attester producing Attestation Results

The text is pretty clear that this is not the case.
We introduced a new paragraph break to make this easier to see, which is 

In the passport model, the Attester may well obtain the Attestation 
Results (the "passport"), and may well cache it for sometime and might 
use it repeatedly.  But these Results are signed in some way, and can 
not modified, so they aren't consumed or produced.  We debated putting a 
line through the Attester box, but due to the caching, we decided not to.

> Figure 6: Shows Relying party consuming Evidence
> Figure 6: Shows the Relying Party producing/passing Evidence

In this case, we changed the diagram to show the Evidence passing 
through the RP to get to the Verifier.  We discussed whether the RP 
could in fact cache that Evidence; whether there are cases where the 
Attestation Results might have a shorter lifespan than the Results.
We think that this could sometimes be the case, but we felt that that 
the diagram would best be adjusted anyway.
(Yes, we came up with different answers two what are apparently the same 
problem with the diagram)

>      > ** Section 16.  Can the thinking of this section be explained.  It
>      > seems out of place, and borders on being a solution.  The rest of this
>      > document talks about notional roles and architectures.  This text is
>      > focused on a particular nuance of message flow.  I'm wondering if we
>      > need it.  My thinking was to move this text to
>      > draft-birkholz-rats-epoch-markers.  As an aside, I did notice that
>      > draft-birkholz-rats-epoch-markers is using the amount of text on this
>      > topic in this document to motivate it's existence.

This issue remains open.

> Roman Danyliw <> wrote:
>> ** Section 4.*.  Editorial.

This issue remains open.