Re: [Rats] using symmetric keys in an Endorsement/Verifier flow
Laurence Lundblade <lgl@island-resort.com> Mon, 08 February 2021 20:35 UTC
Return-Path: <lgl@island-resort.com>
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 6ECBA3A15B1 for <rats@ietfa.amsl.com>; Mon, 8 Feb 2021 12:35:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YU_sob2hbtjh for <rats@ietfa.amsl.com>; Mon, 8 Feb 2021 12:35:50 -0800 (PST)
Received: from p3plsmtpa11-10.prod.phx3.secureserver.net (p3plsmtpa11-10.prod.phx3.secureserver.net [68.178.252.111]) (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 01E9B3A15B0 for <rats@ietf.org>; Mon, 8 Feb 2021 12:35:49 -0800 (PST)
Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 9DG9l7WhX0AU29DG9lpnMR; Mon, 08 Feb 2021 13:35:49 -0700
X-CMAE-Analysis: v=2.4 cv=NJMQR22g c=1 sm=1 tr=0 ts=6021a0a5 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=QyXUC8HyAAAA:8 a=48vgC7mUAAAA:8 a=l70xHGcnAAAA:8 a=0XtbOteLAAAA:20 a=jMHbSble9S-_HX0Ny2AA:9 a=QEXdDO2ut3YA:10 a=h9EYWt3Upm4A:10 a=Q0I0aoeUmHkA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=JtN_ecm89k2WOvw5-HMO:22
X-SECURESERVER-ACCT: lgl@island-resort.com
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <FC34391E-023A-416B-BD43-39371C8A43D2@intel.com>
Date: Mon, 08 Feb 2021 12:35:48 -0800
Cc: Michael Richardson <mcr@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FC9B612B-C045-4287-94E0-314616D97051@island-resort.com>
References: <31999.1612560697@localhost> <1568.1612561139@localhost> <FC34391E-023A-416B-BD43-39371C8A43D2@intel.com>
To: "Smith, Ned" <ned.smith@intel.com>
X-Mailer: Apple Mail (2.3445.104.17)
X-CMAE-Envelope: MS4xfK/iyZVL+iULNsfLRGxBlLme8Qiz+92OwSo0j7hnP2/vguzJbKWBHLt4fjl+FabaKr864hyxhff5jvecPlWxtBAhXgSNkBlNAr8EcHcnb24UMyd3KmDa rEdBqSTVTeUSwR/lj/CY17NTJC4HEWC0jeFt0GiAqONJ+Ig7froWbFexaqfn4RI1OY/NkmnLXviB8EQCOlkyFAgzyKjACk1By0TtMxLAxUB78oxYcjN9rBeZ zmoVyKjUbRqjyX0zJr+dAQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/9NiY-zheHiXygJlt1LTjawRgPyA>
Subject: Re: [Rats] using symmetric keys in an Endorsement/Verifier flow
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 08 Feb 2021 20:35:51 -0000
So the proposal is to say nothing about when/if Endorsements should have confidentially protection in the architecture document, right? This leaves it up to the designer/implementor/user of symmetric verification keys to figure this out on their own. I’m fine with this. (Note that I was only suggesting a security considerations statement like “if endorsements carry symmetric keys for verification the endorsements should have confidentially protection”. Given that the UCCS draft has paragraphs about integrity and confidentially, then a statement like this seems appropriate). I'm happy it is closed. LL > On Feb 8, 2021, at 10:32 AM, Smith, Ned <ned.smith@intel.com> wrote: > > +1 "Endorsements with symmetric verification keys should write another document" > > This is a reason to re-charter. It would allow drafts that address the corner of the diagram that was ruled out of scope during chartering discussion to be written and adopted as a way to clarify content that isn't appropriate to include in an architecture draft. > > -Ned > > On 2/5/21, 1:40 PM, "RATS on behalf of Michael Richardson" <rats-bounces@ietf.org on behalf of mcr@sandelman.ca> wrote: > > > In https://github.com/ietf-rats-wg/architecture/issues/162 it was argued that > we needed to be clear that: > > "Endorsements should have confidentiality protection when carrying > symmetric verification keys. " > > but, many of the Architecture Design Team didn't feel that the architecture > was intended to provide any kind of specification on Endorsements. > Within the dataflow diagram: > https://www.ietf.org/archive/id/draft-ietf-rats-architecture-09.html#dataflow > (attached below, for those who use a fixed-width font) > That only the "Evidence" and "Attestation Results", which are between > solid-lined entities was really in scope. That the rest was for future > documents. > > We felt that this requirement went into the Design Requirements which the > IETF usually tries to stay out of, sticking to Functional Requirements. > Further, we felt that the Functional Requirements in the RATS Architecture > should not even cover Endorsements. > At least, not in this edition of the document. > > The recommendation is that those who need to do Endorsements with symmetric > verifification keys should write another document in which this topic would > get adequately dealt with. > > > > ************ ************* ************ ***************** > * Endorser * * Reference * * Verifier * * Relying Party * > ************ * Value * * Owner * * Owner * > | * Provider * ************ ***************** > | ************* | | > | | | | > |Endorsements |Reference |Appraisal |Appraisal > | |Values |Policy |Policy for > | | |for |Attestation > .-----------. | |Evidence |Results > | | | | > | | | | > v v v | > .---------------------------. | > .----->| Verifier |------. | > | '---------------------------' | | > | | | > | Attestation| | > | Results | | > | Evidence | | > | | | > | v v > .----------. .---------------. > | Attester | | Relying Party | > '----------' '---------------' > > > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats
- [Rats] how does the Verifier work Michael Richardson
- [Rats] using symmetric keys in an Endorsement/Ver… Michael Richardson
- Re: [Rats] how does the Verifier work Henk Birkholz
- Re: [Rats] using symmetric keys in an Endorsement… Smith, Ned
- Re: [Rats] using symmetric keys in an Endorsement… Laurence Lundblade
- Re: [Rats] how does the Verifier work Simon Frost
- Re: [Rats] using symmetric keys in an Endorsement… Russ Housley