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

Roman Danyliw <rdd@cert.org> Sun, 24 July 2022 22:23 UTC

Return-Path: <rdd@cert.org>
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 B0627C1A5D19 for <rats@ietfa.amsl.com>; Sun, 24 Jul 2022 15:23:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seicmu.onmicrosoft.com
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 MHZAvoWY8V27 for <rats@ietfa.amsl.com>; Sun, 24 Jul 2022 15:23:49 -0700 (PDT)
Received: from USG02-CY1-obe.outbound.protection.office365.us (mail-cy1usg02on0126.outbound.protection.office365.us [23.103.209.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C7AC1A5D1D for <rats@ietf.org>; Sun, 24 Jul 2022 15:23:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=Li3S4viiEKh9TQhNWrn1n8WsE2oupuZBPwIcoI+gvue8vB0oU0A6isa/r5LBNg3gQP2PwHttNaH0ys4Ua/V5gGrrukQK6jjU3VnI7yKf2ZJDIz738SZ4t266pXSQYGPNNVSByxIxV1HQHDd1/AyqI60O9okY9PvmC2kq1HnZPAmt63tSGbAq1G9CTxQ7FKrrN84vPLmcIqQWkKkU9VCMgOtzgyN36h9+qv2WKwTGApf4FBpMjpxAedBD0qbSUsoMQYM5FyQYpkKNY93mXjZLkmPXi8oWCIJLPFtZdlitWMbTSWEgKjaCnBWDjBtHdVxsBOu/H2ummwJXTJVSIUwPMQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QodzmN0v5tH1sqeehuh0oaYVgNrF1pbYaclNFMIGAnI=; b=tjzMzdffv7Wc8ZgPGskzACSZDj6r61VXsB5qcfqTwnFOd3HpTkW++SYELufSHULqed+2h4tDbhOTAwxGNVidlQXU3+/YJSP9YFidL5i6BJM06M7TnVoCTF4Lh9RKzDziykvtUPyM6eh8N83b8mUcerASLkz0d/Rni2pOU8v2ZZ74wK1gYa3wV4DHQ/zywO1We5K/lR2/BeW3HNcE3aY8K3bK8ZI4vmaRKWyZ8DdJ9jz89vOzb2++8bMFes/+cPE5AALpLmLP5d6zb2gjxPAzxv5PGkk3FqHycEECz9l+onJJccQkTUABskNkOgyXoda5b95aeqfTSQgoYkGAYSSK2Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cert.org; dmarc=pass action=none header.from=cert.org; dkim=pass header.d=cert.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seicmu.onmicrosoft.com; s=selector1-seicmu-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QodzmN0v5tH1sqeehuh0oaYVgNrF1pbYaclNFMIGAnI=; b=agK3SIjnYsKF/jL1n3x21k6iv6SgKUHuMBeNSOZ0xosGRWWa4ITtLn84oxegGmIew5KOFXs34cBLrklQXybxR0CqGKdb7BtXXDs0iLm4L86xkViilGIwwGtoxJ1z/HgeGfveO532SICgLyumpO/WUgS4ySvIk6saecdzfobG/Jk=
Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:168::11) by BN2P110MB1221.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:179::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5458.21; Sun, 24 Jul 2022 22:22:45 +0000
Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::61c5:afc3:7804:7d27]) by BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::61c5:afc3:7804:7d27%3]) with mapi id 15.20.5458.024; Sun, 24 Jul 2022 22:22:45 +0000
From: Roman Danyliw <rdd@cert.org>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] AD Review of draft-ietf-rats-architecture-15
Thread-Index: AdhfNo/YbgZCs0OMSiqFXlqIAvRN0wAmn8KAA+7EkoALbMRJ0ACavhjQ
Date: Sun, 24 Jul 2022 22:22:45 +0000
Message-ID: <BN2P110MB1107D533EBAB156534BBC590DC929@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>
In-Reply-To: <BN2P110MB11077E3694C78ACBA39F2F3ADC919@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cert.org;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 429e66d6-5030-4d56-cb81-08da6dc3087c
x-ms-traffictypediagnostic: BN2P110MB1221:EE_
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Li64iBWagvNFSqbHmsWbgoQSeMZL53mNfOnFdkmoD71O240F+9QU4ByoKjuyv3ij8Lb/6AhT/sOkSfo9rB8LxnEJRVknrHc2xy9YpEaalEEgYf+cD4JplOFfr/mm4ww1L/Mg9RbcNP98MLBcusHwJbM7BtLAUeanIRC4L85+JKxJrkT35wUiX1hOfDU+DSQ3BL3zv75KXrLRuA+yvJLqr4HUuI3dnbDFT4oeMqzKmGR0D1em90x+n9zF6UmRPNuYTMlTA5JUQQNG5eNFx2kH3F+CDkshubMb7ThtsRYT9tG10mDEtSkWWhrDTd+ef1r0c952JHaFeH9akQxnymWCv1On8mEv4fvrf1ooiNSst9iBlHwKugkBmROWuFktNcLkkX98MKVtTD1jQ1JMK+kEGWMvjewkQXxt1fKhqTCSsgO5+BIqdaeeTrfnu7I3cKydGQ92++Dm8HMNFXyFYpkWrQtCsCVSfV8JpwiUffvvFtBVCel5cCWulr4oE31khOVGUMvM58GSvto5KRc7mm7egb5qRq3CpsAVL+lPFNG9jhDK5YsdumVEkUq3b4nwkyshX4ZDQYY/HXKHi5xV4pLv7VOWHG/kHOp5uQOXBQQ+SGTKu5WR/w3UTtFZ2+Nx33dM2SUSgFb1EBVtd5QFiZgw65lNyL+D/50NFWED4LWD6no47Ou8659Cou6xidJNNfCEAiE8FiTdVzlXUVJXKYDazDvgJ8CiywBT638pdYuAf2JgyeBTrYUE36yrCU6AwyN9l0bi2no9RwK/Td5ZjNddeSh4adIemXuEL68O1ucc9NXWjYiMBW38Nv0BcuaeFsc0
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230016)(366004)(122000001)(55016003)(82960400001)(186003)(38100700002)(38070700005)(8676002)(64756008)(66446008)(110136005)(76116006)(66476007)(66556008)(66946007)(6506007)(7696005)(33656002)(71200400001)(966005)(86362001)(2906002)(9686003)(26005)(53546011)(83380400001)(5660300002)(52536014)(8936002)(498600001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: TrOrMMEdQOQK0cpOKkq4sU+KNQCGVoTgQU39FKADNbZVm9GXOTJOy+AzLDqXPmhApUXb/s7z2Az3nlg6gJyvbvjPfBnYsOQO4fVRY3Lzzlb+SQklgiZCwkwriV99L7lRuIOEtQAg0E27SIN3GaQizyM0/4dTe9pa+SgeK/KdnGNW1D7ZIz6d1yQD/A4P6Q6kG6X9r+v8FwOXr+MyPlgQqVL5iE7+E20H0XRg0vcNT4rDCBXUSzslLMA+oMTm9B5AhizWwBk5JjSpuNDeHlSIoEC0VQh/EibER2K4U6ETerlkpLBWLAEfTnF3fMqJ/W3Rd1LnkldeaPgbWe5hDxhPOlK4gRTCJb+oyI4vvOnFNfTzyyIFSzpKon87vpOjLujYIYFuCYcM/4hgOZ/XhE9KSeci+Oj4IrnNbRdqMEOor74pb0vhYUcgIH93l8nY4W67uJA39rDOTWRHCswNmBIJGnthW2cLg4MHytZn0/k4uGa6JVgM2OSJkgjUXc9RyEBhedeRuZkbrKjvK6SbcI/Za1rwdvds/Xj1tdAntoqZkUyfvg7s9a1HW/h8FMrs32egTNX9j0jvHlHG87yYcEEQQqMwsZFnDmTOpmjXM4Swb+6nRsYneznlT6TCU8v0GTd7TIdCfm+6iHA7YyGWPEHnmo+GVT0lcOT7ifkZrynZTlb8uAUl6a8dtZz899sIfJZg44Uk+VN1lxT99izVJf0MOupYjsc4Rco7aQYBBvHwzGRuYSw1PsXJPnz8r9qvrFbJPjQCeKrqjoG1i0pQIUFHkxRTEXBD15H1WPqOfO0rQ1R6w4OoaQ3xATZ+NTUgol9vwL3BEjKmFVlbhhxoWED3ZJ5TmI0Vd0HHpdWttBHsYLTpQ87xnReo3szymMW4b8x01abeWPxWEesevDGU/v1iFiMcCIm9Aoxnxp+yk0Lrxx0rYj/UZTZzC0SwntC6p2HxihQFTHqImAQ01lXK++/3FbCYEZC4QOqzhXfD61ItrDFpQt5ORsbjyFV0c9WuaQaSuQi6AR+dNSmtvo7Yo3bFKs/JKnzYVFJMoxaBKLMBoJdOBBNFUiz3iOtS67S6N/Rtcf8OlwE8hUGyrXVL9JMbhDXYsRD06VZw3pB0+ZSjIO8rP2WQU4yTDJ2IrWvJ1L3E973QWOWawUSq5lQgnWif4IE6c5BtKFxdSS0jNIgxLCG/NawkpIb4EWdgiECR9aFl8oXGcTLTx5j5CR/0PpY+ggKxMVX2NkL0lj2s0aq/CHE823jELS1fIa8zCN5CDIsB5czh19tuKR9HbYtjGzmTY22gl7NzY5HejSL3K01OP1mtJMkDNU3ZuAAr8u1b1ueXU856xh1PsL5RAq+hSeQfg4CRngvMC7EegAcfuGqXP9eCv5b2p1lCcGDLPszdADEmH6kc4RS5TFrXTjrfGphw2BZLI5J5TKaKpIasDfB8YhIiD6CvJb5BEcHIbE0m5mGArGsQxqiCBbS4Y/hil1O5+f+82d/7y0NA7EUpWbMTUuI=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cert.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 429e66d6-5030-4d56-cb81-08da6dc3087c
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2022 22:22:45.4480 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN2P110MB1221
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/A1hYQepSuEVcV44ufMCz09UPJEo>
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: Sun, 24 Jul 2022 22:23:50 -0000

Hi!
	
Thanks for publishing -19.  More inline ...

> -----Original Message-----
> From: Roman Danyliw
> Sent: Thursday, July 21, 2022 5:20 PM
> To: Michael Richardson <mcr+ietf@sandelman.ca>; rats@ietf.org
> Subject: RE: [Rats] AD Review of draft-ietf-rats-architecture-15
> 
> Hi!
> 
> Thanks for the updates in -16 to -18.
> 
> I'm putting together multiple threads and github comments in one place below
> ...
> 
> > -----Original Message-----
> > From: Michael Richardson <mcr+ietf@sandelman.ca>
> > Sent: Tuesday, May 24, 2022 12:34 PM
> > To: rats@ietf.org; Roman Danyliw <rdd@cert.org>
> > Subject: Re: [Rats] AD Review of draft-ietf-rats-architecture-15
> [snip]
> 
> >
> > On 2022-05-04 12:07, Michael Richardson wrote:
> 
> [snip]
> 
> > >> ** Section 5 -- Topological Patterns
> > >
> > > https://github.com/ietf-rats-wg/architecture/issues/404
> >
> > 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
> > at:
> > https://www.ietf.org/archive/id/draft-ietf-rats-architecture-16.html#s
> > ection-
> > 5.1-3
> >
> > 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)
> >
> > https://github.com/ietf-rats-wg/architecture/pull/414/files
> 
> Thanks for clarifying.
> 
> What I'm getting from this text is that there is "producing" and "consuming"
> per Section 4.  I took those terms to be describing/constraining information
> flow -- what information can comes and go among the various architectural
> elements.  It appears that Section 5 is introducing a new behavior which is
> "accepting" (receiving but not processing) and "passing" (sending but not
> processing).  There also appear to be element specific behavior of "caching".
> 
> I see no conflict with these four behaviors.  My concern is that these nuances in
> behavior were not explicitly stated.  They should be.  Furthermore, just as
> certain architectural elements are defined by what they can produce or
> consume, I'm wondering if the same is true for the "accepting"/"passing"
> behavior?

I believe we are going to talk about this at the meeting tomorrow.

> > > -- The overall Section 12 seems silent on:
> > >
> > > o 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?
> 
> [github said: https://github.com/ietf-rats-wg/architecture/issues/407]
> ==[ snip ]==
> We need to acknowledge that there is a deep hole (not infinitely deep, but not
> trivial) where we need to look at integrity of all of the different platforms.
> The way that the compositions are composed is a bit tricky, and the results are
> sometimes different than other people would naively assume.
> Are there references here to other papers that we should include?
> ==[ snip ]==
> 
> I completely agree, that's why I mentioned it.  Composition is hard and can
> alter the security assumptions of the individual components and introduce
> emergent risk.
> 
> I don't think it can be solved generically.  However, we do need cautionary text
> here.  Perhaps:
> 
> NEW (roughly)
> 
> The RATS architecture allows for an entity to function in multiple roles (Section
> 6) and for composite devices (Section 3.3).  Implementers need to evaluate
> their designs to ensure that the assumed security properties of the individual
> components and roles still holds despite the lack of separation, and that
> emergent risk is not introduced.  The specifics of this evaluation will depend on
> the implementation and use case is out of scope for this document.
> 
> > ** Section 16.  Can the thinking of this section be explained.
> [snip]
> 
> Thanks for explaining the thinking.  I do not agree that this text is appropriate
> given it's uneven treatment, but will support the desire of the WG to keep it.
> 
> One editorial matter that got introduced somewhere after -15, please make
> this a proper appendix.  It's currently " 16.  Appendix A: Time Considerations",
> that is, Section 16 with word "appendix" in the title.  Perhaps this is a rendering
> issue.

Thanks for making the above changes.

Regards,
Roman