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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 04 May 2022 16:07 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 9E484C1594A0 for <rats@ietfa.amsl.com>; Wed, 4 May 2022 09:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwzYZ_vHAge3 for <rats@ietfa.amsl.com>; Wed, 4 May 2022 09:07:35 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A763AC15948A for <rats@ietf.org>; Wed, 4 May 2022 09:07:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 76DDF38B3C; Wed, 4 May 2022 12:20:41 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NosvHciTDSA0; Wed, 4 May 2022 12:20:40 -0400 (EDT)
Received: from sandelman.ca (unknown [172.30.2.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2B71B38B35; Wed, 4 May 2022 12:20:40 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C448A600; Wed, 4 May 2022 12:07:31 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Roman Danyliw <rdd@cert.org>, "rats@ietf.org" <rats@ietf.org>
In-Reply-To: <BN2P110MB110748C2C81E515E5E7277C5DCC09@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
References: <BN2P110MB110748C2C81E515E5E7277C5DCC09@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 04 May 2022 12:07:31 -0400
Message-ID: <3256.1651680451@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/5IyJAUrQMIT4Pjz9NVkv-PQFSM0>
Subject: Re: [Rats] AD Review of draft-ietf-rats-architecture-15
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.34
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: Wed, 04 May 2022 16:07:37 -0000

Thank you Roman for your revised review.
It's been over 6 months since your original points, and I wish that we had
been able to use the time to respond to you.

I think that it's difficult for all of us to pull context back out over that
amount of time.   Tell me how we can shorten the review cycle.

That could mean:
a) tagging on your github issues so that you'll see things faster by direct
github messages.
b) issuing updated drafts as soon as issues are resolved
c) splitting issues into specific (new) email threads so both WG and you can see
d) something else?


Roman Danyliw <rdd@cert.org> wrote:
> ** Section 4.*.  Editorial.

https://github.com/ietf-rats-wg/architecture/issues/403

> ** Section 5 -- Topological Patterns

https://github.com/ietf-rats-wg/architecture/issues/404

    > ** Section 8.1.

    > [Roman's comments on -13]
    > In the spirit of inclusive terminology please use alternative phrasing
    > for "man-in-the-middle attackers".

https://github.com/ietf-rats-wg/architecture/pull/405
If only there was some document that proposed more precise, modern
terminology here.

> ** Section 10 - Freshness

https://github.com/ietf-rats-wg/architecture/issues/406

> 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 12 - Security Considerations

https://github.com/ietf-rats-wg/architecture/issues/407

> ** Section 12.1.2.1.  Editorial.

https://github.com/ietf-rats-wg/architecture/pull/408

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

https://github.com/ietf-rats-wg/architecture/issues/409

    > ** 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?

https://github.com/ietf-rats-wg/architecture/issues/410

    > ** 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.

https://github.com/ietf-rats-wg/architecture/issues/411


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide