Re: [Secret] AD Review of the proposed charter
Roman Danyliw <rdd@cert.org> Thu, 26 May 2022 21:07 UTC
Return-Path: <rdd@cert.org>
X-Original-To: secret@ietfa.amsl.com
Delivered-To: secret@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD703C159492 for <secret@ietfa.amsl.com>; Thu, 26 May 2022 14:07:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 GuXh2B82YXGJ for <secret@ietfa.amsl.com>; Thu, 26 May 2022 14:07:27 -0700 (PDT)
Received: from USG02-CY1-obe.outbound.protection.office365.us (mail-cy1usg02on0121.outbound.protection.office365.us [23.103.209.121]) (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 87E19C159497 for <secret@ietf.org>; Thu, 26 May 2022 14:07:27 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=pnkZma4aL/qRlqkX4hFsBR9xnJ6cy/Xs/L/C7gC3XgdIHOA5bMFY23fnt63j78VfTQvFr0aZ7psdPfftUNPiX1FCqU39Hjf17UR+1VdRlLN2htWGSW6RAbia/Rd0dpHTerYjkHAtAUXf4p8F0zmGpTNpU4Axkd956G2nLPlBA2C3hFqSvGIQT2iSSZImXKnouLmq5lauUQNXShuCJWjpGB/GmxqyDtIDo4EI8ZK+R5meVKCam3ErHqpr2d5EkEnzUCHGBY176DqerBO1C13fCYMLu8ED9a923v7U9YSS1p2WJ+jvixQ6ZNmHD/5X+pXGUvKSJPu1vlhQZtVQxWq+UA==
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=Ugj6dTWHHfELNLwNdRGJaDApA8n38PjPOrEZNmrOeyQ=; b=EjhYpM7EUvsGg632Tf+kvv0sMCwnArmRBu1FRIPvpm5eu6qUY/eJyQQ9imOZVPeoAYFB7W0tjbL3Za9qMy0tNP0SQ1ZFOx0hXl376Gy9FrlHVcttDAO3withfPDEAZDC1hbNe8px7xcYk444aqzL/jJROM5FDcznp13fbkKbxyTi1YX4z07O0D6hdA/U3afk5O5xTJt/cs2FfF70E+PX6FUF8c2PXPGVKlRzU5Qwg61I+HqyrxDRDdzsxtnvGXLmKV/ECiUY0nvjxPeK+BXkeMzLnOr3VN5K7OKpeOTRLNGpUWcEQIKvAKNSzrRz5lCg9y6YZhbXPVWJ3quvBDM+EQ==
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=Ugj6dTWHHfELNLwNdRGJaDApA8n38PjPOrEZNmrOeyQ=; b=IdiMJcMkkxVhgo/qnNsDEnx/bMlulZ7+VlRkgWJMHePtaRnOeZegxRTP5ULGIK9OL380zedfR8dPQWsbiPC8zuiLcRKC6j1PUpkQlBjsc5QSLhnKxe0wBxpKT8dew6KeYU5FI8Ku2AqYxSJghYkbTD+CzuIYeGjMO6hBwUfJajg=
Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:168::11) by BN2P110MB1574.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:178::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5273.22; Thu, 26 May 2022 21:07:22 +0000
Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::557e:44e5:6959:7c65]) by BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::557e:44e5:6959:7c65%4]) with mapi id 15.20.5273.023; Thu, 26 May 2022 21:07:22 +0000
From: Roman Danyliw <rdd@cert.org>
To: "secret@ietf.org" <secret@ietf.org>
Thread-Topic: AD Review of the proposed charter
Thread-Index: AdhcE8MG4VmH+3IOTBi3z1Fo9FWo2QVMEmfA
Date: Thu, 26 May 2022 21:07:22 +0000
Message-ID: <BN2P110MB11071AEE69804E618F4B0D65DCD99@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
References: <PH1P110MB1116CF8D2A885C4E90705ECCDCFC9@PH1P110MB1116.NAMP110.PROD.OUTLOOK.COM>
In-Reply-To: <PH1P110MB1116CF8D2A885C4E90705ECCDCFC9@PH1P110MB1116.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: 2a798a30-0e7e-4284-ed2e-08da3f5bba06
x-ms-traffictypediagnostic: BN2P110MB1574:EE_
x-microsoft-antispam-prvs: <BN2P110MB1574FAA349B7DC5917A8769BDCD99@BN2P110MB1574.NAMP110.PROD.OUTLOOK.COM>
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: T4EuRCtksOHW/T2BRPqgVz0VB1hk5RdwhghSIZFQyMoxUsloeCco5yJUqzdt3nYbEq/Fl6PJv7g9Nr/MoCw3tP2dxsm4XTws8ALkC2nnc5E1dP3P+8+TlvpxAoXz3osEwdcpH/f91DPs80Jn2koOQm0gQEHci2dbnGDpXJKlFU/qAHxjRkD6imLFQcUMg8qw/IV2PG52Fqi+7oS2kKd2peHOQm/vxF+4jw0SGaBeMPiHjFYIR/K1N5UKxsxK0A/1y76Rc0srWBIciozfdvtOxw7og1aqWuIAnTaGlHR6wy04FZtWJ5RaheC45bgA5xqoytSFaFkwpriA45p7fC5KFYKaHcvZSAU705aQIp1jqnaKabA4Yx7N6CB3j8ECw256WuCBDTfuo61MTD6PEGjz47il+pPXqTo1O5Wd9sUEoKRWvvVwZ1K/7cpd1gm4IQuGA8WJeVnf5lR9A4dGEDBqiSGLlf6XqX4I0iCsGqRN+57+Dn1SdZ3/IsngrJssmdQf9ZV2YvSV7U/NDp+xx5kAah2E5DWYpVHp3w0reWNCClxsXyQDdNUalalGKAsSSA+2B4R7OVMa2TmjykN/MER3fy+ftHm3ZBCbDUnbsuxJl1YUQ/VkiewVfo1MqMakUC1THwv3F2HVIa+lc5gtg/YSFNXdXAtJ6hC+SqeEvxKmqPeX75gJQbo9BnqqCY9OxM5+fh7dbsz0cn/rF+ikoCywQQ==
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:(13230001)(366004)(966005)(66476007)(498600001)(83380400001)(6916009)(55016003)(64756008)(66556008)(66946007)(66446008)(76116006)(186003)(122000001)(82960400001)(8676002)(38070700005)(8936002)(52536014)(5660300002)(6506007)(53546011)(33656002)(86362001)(38100700002)(7696005)(30864003)(2906002)(26005)(9686003)(71200400001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: CUHlBRzhhqRQQAmpLoJDE2QQjIMxDb+/ZPugyVrJnapDe4NyLCt9syrFA+dRyaT5wFXhj3072gfvuKo9QpOXNdX1rtSWhCXh2fQaj8ZFMz9ZTuteb7zJAZk4sDD2p7WXM6xJBO6EhQjvJLi3EbyvfxfOBwc2AubS18Amzol5UtKqDrNENHmK5X9CAlXiChmvGan+x9NI9WyVy1zwn8aODEW1KWaINkMxN7OJmenC5bZ9E4YlcNhLcj0RIJa9NWtXDe3X5DiQbkdtW6gzrVthk3oxpkGYnezeEg8qfnV/kVjAyGHaO9DcNoQ9i6K8RlwBHTP6T7tEA61NbIBOEQfKDDbhmm4+8K6I7t6Kw2SBCLvIbGo5JU9h/7dxKPzRcKaUrZuX2mtmy4ALOXa61IpEokbgf03yjZrnBv6WBNVtrJQ=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: 2a798a30-0e7e-4284-ed2e-08da3f5bba06
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2022 21:07:22.1311 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN2P110MB1574
Archived-At: <https://mailarchive.ietf.org/arch/msg/secret/fEuA7InpTHUXrXQMylIj5Cz_ryk>
Subject: Re: [Secret] AD Review of the proposed charter
X-BeenThere: secret@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Secure Credential Transfer <secret.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secret>, <mailto:secret-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secret/>
List-Post: <mailto:secret@ietf.org>
List-Help: <mailto:secret-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secret>, <mailto:secret-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 May 2022 21:07:29 -0000
Hi! Thank you for charter edits at https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.md. (1) Editorial nit. "Anti-replay" --> "anti-replay" (lower case) - in some prior version of the text was upper, then it was lower and it's back to upper. Sorry if I caused the confusion. (2) Can be discussed in parallel to ML conversation - Are there milestones for the charter? ==[ snip ]== ** What are the milestones that this WG plans to make (as a first pass)? These need to be explicitly listed - date + milestone. I would imagine there is the protocol itself (the text says that). Is there a informational architecture or use case document? Any profile for a given vertical? It is fine if the answer is no, but now would be the time to describe it (otherwise it will be out of scope without a recharter). ==[ snip ]== An example of this would be: 2022-12: WG adoption of the secure credential transfer protocol 2023-12: Submit secure credential transfer protocol to the IESG for publication This is a list of the planned deliverables of the WG. Based on my reading, this charter is very narrow - make one protocol specification. If there is a desire for supporting documents now is the time to call them out. No issue if the scope is narrow. The above text could then be used (perhaps with updated dates as I invented them with no basis). (3) Remaining areas of scope discussion: (3.a) "The solution the WG comes up with must: ... The WG will define the enumeration of credential types that could be shared. A subset of these credential types adhere to a public standard (e.g. Car Connectivity Consortium). Editorially, it doesn't parse for me. Please check my understanding. Is a credential type a unique identifier of a particular instance/format+version of a given credential? Put in another way, is this text intending to say that the TIGRESS format must be able to carry an identifier as to what kind of credential it is carrying. Supported credentials type may include those in public standards (e.g., Car Connectivity Consortium) but also proprietary formats. TIGRESS will also define a registry to track (provide code points for) these credential types? To be prescriptive, could the following text replace the above bullet: NEW * Support a variety of types of credentials, to include those adhering to public standards (e.g., Car Connectivity Consortium) and proprietary (i.e., non-public or closed community) formats * Allow opaque message content based on the credential type (3.b) "Out of scope topics for the WG are: ... For proprietary credential types, the protocol the WG aims to establish shall not define the actual format nor content of each field within the Provisioning Information." -- Editorially, this also doesn't flow for me. It's also a double negative (i.e., it is out of scope _not_ to do something) -- "Provisioning Information" is an architectural construct not defined elsewhere in the text (or noted as being in scope). It has to be either defined or dropped. -- (without know what "provisioning information" is) Particular behavior is being said to be out scope for proprietary credentials. This suggest to me that it is in scope for non-propriety credentials but I don't see that in the current text. Regards, Roman > -----Original Message----- > From: Secret <secret-bounces@ietf.org> On Behalf Of Roman Danyliw > Sent: Friday, April 29, 2022 6:11 PM > To: secret@ietf.org > Subject: [Secret] AD Review of the proposed charter > > Hi! > > Congrats on a successful BoF thanks to the preparation of the proponents and > the chairs. The importance of getting both ART and SEC input on this work was > voiced on list and during the BOF. After discussion among the ART-SEC ADs, > the resolution was for this work to be administratively housed in the ART area > with a SEC AD. Hence, I'll be picking up this work as the responsible AD. > > The next step to get a working group started is to have charter that captures all > of the feedback to date. I heard some charter discussion during the BoF and > read more on list. I reviewed the Feb-22 version I found at > https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.md > as the basis for the following comments. It interleaves my own new feedback > and that of the BoF/ML that doesn't appear to be addressed. > > Specific comments on the charter text: > > ** Paragraph 1. "There are many situations in which it is desirable to share a > digital credential with another person. For example, you may want to provide > access to your vehicle to a friend or a family member. You may also want to > provide access to your home to your cat sitter. Or, you may want to share a > hotel key with your spouse. Today, no such standardized method exists in a > cross-platform, multidisciplinary capacity." > > -- (from BoF) Per "There are many situations in which it is desirable to share a > digital credential with another person", there was feedback (Michael > Richardson) that this text creates confusion because the WG is in fact focused > on delegating, not sharing the credential. > > -- (from BoF) The proponents (Matt Byington) in response community feedback > (Stephen Farrell) noted that "multidisciplinary" could be clarified > > ** Paragraph 2. "The WG charter includes the definition and standardization of > a protocol that will facilitate such credential transfers from individual to > individual. The protocol will leverage a "relay server" to transfer data from > sender to recipient. The scope of the transfer is limited to a single origin device > and a single destination device. Note that neither private keys nor secret > symmetric keys present on the sender's device are exchanged during the > transfer operation. In the transfer protocol, the "credential" being sent from > sender to recipient comprises data both necessary and sufficient for the > recipient to exchange with the credential authority for new digital key material > granting the recipient a subset of the sender's capabilities or entitlements." > > -- (from BoF) Ben Kaduk noted that it should be clarified if this is "individual to > individual" or "individual+device" to "individual+device" (or user agent) > > ** Paragraph 3. "Privacy goals include: > o The relay server should not see sensitive details of the share > o The relay server should not be able to provision the credential itself, acting as > an intermediary for the recipient (MiTM) o Aside from potentially the IP > address, the relay server should not learn the identity of the sender or receiver" > > -- In the spirit of inclusive language, please use a different expression than > "MiTM" > > ** Paragraph 4. "Sufficient security measures should be embedded in the > protocol in an effort to: > o Ensure only the intended recipient is able to provision the credential o Ensure > the credential can only be provisioned once (Anti-replay) o Ensure the sender > has intent to share (secure user intent)" > > -- s/Anti-replay/anti-replay/ > > ** Paragraph 5. "The solution the WG comes up with must: ..." > > -- Per "Allow a sender to initiate a share", given that this came up in the BOF > discussion, perhaps append "and define the relay server". > > -- Per "Ensure the sender has intent to share (secure user intent)", it isn't clear > to me what the parenthetical "(secure user intent)" clarifies. > > -- Per "Allow dynamic message formats based on the credential type", it was > clear to me what "dynamic" means here. Are the protocol message formats are > changing based on the credential type? Or is it that the protocol will be > capable of carrying many different types of credentials (they are opaque blobs, > the protocol is agnostic)? > > -- Per "Allow sender device and receiver device to quickly perform multiple > round trip communications", this came up in the BoF too, is there a way to > provide a performance envelope around "quickly". Is the basis for this CCC and > the referenced ISO protocol? > > ** Paragraph 6. "Out of scope topics for the proposed WG are: ..." > > -- s/the proposed WG/the WG/ > > -- Per "Defining the mechanism the receiver will use in order to provision the > credential", I recommend appending "with the credential authority" to > reference the notional architecture defined in paragraph 2 > > -- Per "The WG will define the full set of different credential types that could be > shared. A subset of these credential types adhere to a public standard. For > these credential types, the format of the Provisioning Information shall be > defined by the appropriate standard. Other credential types may be > proprietary. For these credential types, the protocol the WG aims to establish > shall not define the actual format nor content of each field within the > Provisioning Information." > > I stumbled on this paragraph because it's listing assumptions, what the WG will > do and what is out of scope, all in a bulleted list of what the WG will not do. I > recommend unpacking this. > > (a) What does it mean for the WG to "define a full set of different credentials"? > Do you mean that the protocol will have code points? > > (b) There is a significance being attached to the credential types being public > vs. proprietary which I don't follow. This is text is also introducing an > undefined construct of "Provisioning Information" as a discriminator. Aren't > the credential opaque blobs as far as the protocol is concerned? Can this > please be clarified. > > (c) As a proposal for streamlining this text, make this bullet read only about > what's out of scope: "Defining the format and setting the values (? contents?) > of the credential carried by the protocol" > > (d) Perhaps put what the protocol expects in the "The solution of the WG > must" paragraph. I'd like to help wordsmith this but all I can follow is that the > protocol has to support credential standards not defined by this WG. Per (b), > the nuance around "provisioning information" should help with the rest. > > Other more generic charter comments: > > ** (from BoF) There were a few comments about bounding the communication > channel and distinguishing it from a generic tunnel protocol. It was explained > that this protocol will need to work around the constraints of CCC and a > particular ISO spec (I missed which one). I believe there was a commitment to > reference these explicitly. > > ** What are the milestones that this WG plans to make (as a first pass)? These > need to be explicitly listed - date + milestone. I would imagine there is the > protocol itself (the text says that). Is there a informational architecture or use > case document? Any profile for a given vertical? It is fine if the answer is no, > but now would be the time to describe it (otherwise it will be out of scope > without a recharter). > > Other administrative matters: > > ** There is a strong signal, which I agree with, that "SECRET" should not be the > WG name. My working understanding from past BOF chair/proponent > discussion is that TIGRESS ("Transfer dIGital cREdentialS Securely") is the new > proposed WG name. I'm dropping it here on the list to hear if there are strong > objections. I'd beg the group not to bike-shedding here unless this name is > major problem. > > ** There was a question about why different OAuth approaches couldn't be > used. See > https://mailarchive.ietf.org/arch/msg/secret/0VUSVrIRHbRSfEk3uo0BnXJvPpM/ > . It would be good to document that on the list. > > Regards, > Roman > > -- > Secret mailing list > Secret@ietf.org > https://www.ietf.org/mailman/listinfo/secret
- [Secret] AD Review of the proposed charter Roman Danyliw
- Re: [Secret] AD Review of the proposed charter Michael Richardson
- Re: [Secret] AD Review of the proposed charter Roman Danyliw