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

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 23 July 2022 19:33 UTC

Return-Path: <mcr@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 3413BC157B54 for <rats@ietfa.amsl.com>; Sat, 23 Jul 2022 12:33:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 70QCoN2zWTPZ for <rats@ietfa.amsl.com>; Sat, 23 Jul 2022 12:33:01 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 6528CC157B4F for <rats@ietf.org>; Sat, 23 Jul 2022 12:33:00 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:370:128:8273:5eb7:1d0c:7402]) by relay.sandelman.ca (Postfix) with ESMTPS id BC8EE1F459; Sat, 23 Jul 2022 19:32:58 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 377B61A0383; Sat, 23 Jul 2022 15:32:57 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Roman Danyliw <rdd@cert.org>, "rats@ietf.org" <rats@ietf.org>
In-reply-to: <BN2P110MB11077E3694C78ACBA39F2F3ADC919@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
References: <BN2P110MB110748C2C81E515E5E7277C5DCC09@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <3256.1651680451@localhost> <dabb272d-1e69-8a0e-ba91-4d5d85cfb8ab@sandelman.ca> <BN2P110MB11077E3694C78ACBA39F2F3ADC919@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
Comments: In-reply-to Roman Danyliw <rdd@cert.org> message dated "Thu, 21 Jul 2022 21:20:03 -0000."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 23 Jul 2022 15:32:57 -0400
Message-ID: <33343.1658604777@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/2Zbo91Yn2GMGxcW1DiNk4phWPto>
Subject: Re: [Rats] AD Review of draft-ietf-rats-architecture-15
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 23 Jul 2022 19:33:03 -0000

    Roman> What I'm getting from this text is that there is "producing" and
    Roman> "consuming" per Section 4.  I took those terms to be
    Roman> describing/constraining information flow -- what information can
    Roman> comes and go among the various architectural elements.  It appears
    Roman> that Section 5 is introducing a new behavior which is "accepting"
    Roman> (receiving but not processing) and "passing" (sending but not
    Roman> processing).  There also appear to be element specific behavior of
    Roman> "caching".

    Roman> I see no conflict with these four behaviors.  My concern is that
    Roman> these nuances in behavior were not explicitly stated.  They should
    Roman> be.  Furthermore, just as certain architectural elements are
    Roman> defined by what they can produce or consume, I'm wondering if the
    Roman> same is true for the "accepting"/"passing" behavior?

I'm having a lot of problems dealing with this comment.
I've discussed this around the design team that is here at the hackathon, and
we are really not sure what to do here.  In the terminology section, have a
pattern like:

   Verifier:  A role performed ...
      Consumes: Evidence, ...
      Produces: Attestation ...

It isn't clear to me if you'd like us to add Passing:, Caching: and Accepting:
to the terminology section.   I think that we don't really want to do that,
because it really only applies in two cases (the RP when Background check),
and the Attester in passport model.

I really don't think section 5 is that mysterious that it needs more introduction.
I would really like some more opinions from the WG.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-