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