Re: [core] [Lake] 🔔 Working Group Last Call (WGLC) of draft-ietf-core-oscore-edhoc-06

Marco Tiloca <marco.tiloca@ri.se> Tue, 14 March 2023 13:53 UTC

Return-Path: <marco.tiloca@ri.se>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E8AC14CE4D; Tue, 14 Mar 2023 06:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se
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 Js2w-q9d4WOK; Tue, 14 Mar 2023 06:53:51 -0700 (PDT)
Received: from MM0P280CU005-vft-obe.outbound.protection.outlook.com (mail-swedensouthazlp170110001.outbound.protection.outlook.com [IPv6:2a01:111:f403:c203::1]) (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 9A0BDC151524; Tue, 14 Mar 2023 06:53:50 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oegIGqemN8/L+mRc7IcWc0S73M6+3u0hNVC5yLvJik5GQfppBquyuHNjZpPCUad0GUgsgIZ/WCxs1XnXsxDIevBIJqiJfHBl0E/B/2HTsms9WfQ92E3Gr8LStFDoWAAmW4fjkFroNhl1V8vAEBQQNlKUupH405W+ZsZapyDOCDqtq2e0HRj0sGiAa1cH8L5tzjbRAerASirTe6Ff5FQxXkCFbA1VYCkogSBTrj4Dad4YKTrhrnIWScsx6fCkOgoWkp7i0RE9VxOskmhnQcaz1AM/ZmhS0Pva7aIiAjfWXCVjVNIqckUJ/Xv6J0XCYNSV0O3ugWFAD/b0mDTfgr1lhA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=Yo5pTSma1nQoN/uiLe4AycNd+oiBF0rofxBXe+nT5DM=; b=mGdVq0PdwS01nqztQe1O7oQeMF1daD1BZFpyJywb+9EIBxJSJBCaT0jW06dUndB0cN0xpz/3vfV4tmo2B85TRKjcIY+C/ow34U//kQ/EpNWY1psh0VDNTxE4hN0MsdM4fqLuqWspvCh0T77ylfLAT7UJ1PQxOrAARzylD0vHMYShb4y2lRr7CYG61zJkGyM4+/NE2/OULLyT99GBF3kON+aDyShrGUdWl+F/M/7tYnca5lh2mxbRmGbXOnKdkhxpKStFBU6cJozmv1ORogGPUxommpbAaLLztP1lZsaqFiWD2kHMF8OfwPAw/pic2N/64QE2qlAWZbEFEDg25W5PNQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yo5pTSma1nQoN/uiLe4AycNd+oiBF0rofxBXe+nT5DM=; b=cvg08JwFSVY2XLxq/G2SQlsiYvVWiat3vZ7qoDY8iOchrXRnlOW21xCQJsdUs85YTXmJ+VRyFfEGZgtxkHQ8znrwklS2cFv9zZ+VIQhR0JJQz5UT1st/E1VUm/eJx6TTosUE9e6opvTSivQDLpujNWqTHuJuN7ZqqtmT4ab0Xi4=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se;
Received: from GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:37::17) by GVYP280MB0078.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:31::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.26; Tue, 14 Mar 2023 13:53:44 +0000
Received: from GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM ([fe80::5435:d7bc:5f10:99df]) by GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM ([fe80::5435:d7bc:5f10:99df%6]) with mapi id 15.20.6178.026; Tue, 14 Mar 2023 13:53:44 +0000
Message-ID: <5366eb7b-5429-bc74-88c9-86ac65afc452@ri.se>
Date: Tue, 14 Mar 2023 14:53:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0
Content-Language: en-US
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, Carsten Bormann <cabo@tzi.org>, Christian Amsüss <christian@amsuess.com>
Cc: "core@ietf.org" <core@ietf.org>, "lake@ietf.org" <lake@ietf.org>
References: <F02C5E48-A196-45EC-8576-6BC67EC26AD3@tzi.org> <Y+1b4qX6Ya7BCbvk@hephaistos.amsuess.com> <7A07B432-3DD7-4517-B22D-C5C58E9910E6@tzi.org> <HE1PR0701MB3050C70FC1FE5487A9F4D8A489A99@HE1PR0701MB3050.eurprd07.prod.outlook.com> <HE1PR0701MB30503D6232C3FCAA94C9327089AC9@HE1PR0701MB3050.eurprd07.prod.outlook.com>
From: Marco Tiloca <marco.tiloca@ri.se>
In-Reply-To: <HE1PR0701MB30503D6232C3FCAA94C9327089AC9@HE1PR0701MB3050.eurprd07.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------0sViGSCY7YF6N3CNUX4G3dKK"
X-ClientProxiedBy: GVX0EPF000013E0.SWEP280.PROD.OUTLOOK.COM (2603:10a6:144:1::8) To GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:37::17)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: GVYP280MB0464:EE_|GVYP280MB0078:EE_
X-MS-Office365-Filtering-Correlation-Id: 02b5c2db-2ebd-429a-2794-08db249386c4
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: pvlAlanHUNFB0yzi0kF2ycE9dOOGsGMuaptcJ4mgPFqCuXgHtbsjlh0FVVK4QqoWCrLXjby4IBiXsByTfWDRBk0i/R6DxuwMWZ+Sd7Guq/6b2VIgAUvCKK0b5HURKVBWiaLJxUk7ftrQsRh8jbyhQx/CS0PkOX2i1B+fjHaKeHE8TrC2SCPJXDBHyYfvtLIQL9B1Yotf+2pB3jrswXV+8/+roDNDjPPjPi/FF//7/mTQPLYgI+fq4F4goJ+jIxn3mIjF1VIVrOpfRZqKTIAQ0BXqX/a5PpTqtE7i4I7/Mki/VsbjzI9w56L6Wjer9eQFXR3sTFt7V9jc3vzobv7aMuwJI2hXWPL2Gw2mfBqAQzFpwjV02Eut+0EZrE2x+BdKHgZJxOvEF9OXz1k5nxWe05LYPclF/k7SsjlEfX0ThYCPrDrWFzs+Lnxu8GdbX6at+HzWJFrH1uHNhvXz88pMutIAEIuGekUsYi/G8YzHTlHY+70D5gRD5J+VnG2oWzHYjsf0PxFUZAz/ob1LghW2GNFfP1kcN32Kkrx+PKEdUsYHJM+g5HLM5Q2Pu0R4mxyNLOW3N3T0F/1+oP5BMoRj+Yddmt30aUyhPTwu67KyK+MitUL8G5kjNfCOSITXZTKAdeV4V5MjL2HOjrBUjdS5Og1dwftJwHy8slVdj0TIIaauOlVYANNhIVsUs9L3uiHP2LF/DD75xsWC9dR5RarMo0DiCSESYr5zZwGWWDDzmzc=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230025)(4636009)(136003)(376002)(346002)(39860400002)(396003)(366004)(451199018)(478600001)(83380400001)(45080400002)(41300700001)(66476007)(66556008)(66946007)(54906003)(4326008)(316002)(110136005)(8936002)(2616005)(6512007)(6506007)(53546011)(26005)(33964004)(21480400003)(31696002)(86362001)(186003)(31686004)(2906002)(36756003)(5660300002)(235185007)(30864003)(66574015)(44832011)(6486002)(966005)(166002)(38100700002)(43740500002)(45980500001); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: W7+u22HoMaqps0OYVxX24C5VYXFcBWQqvvjMfqvQtypFTr658CilUNnD1Mr1dxWSKpwpv9rakdg2mQWAKVTVM37W1868EleU25aNrLHjMobpJ2u9nJmDuyqGbxnurooPIzcnqbkPpmZsNjHYdxgMw2636GccfEEJIoavD4DiasRcf/DH2T/jEDnVhO7+LZ1p87Y1jLHTNIQYwNY0WJSGqrnasF8wavhdIPxzZLqx8Mj9hDL7k2ooQoTOKF7cFn3IqcB6LLykkBiKsIg32hK2g6CI97mSZK5yuNiHeqk202RFbN76+xcAHgUKxqr5EwF58sUsYRh6UY+VMHNpOz4vDhMGC9kwYjv+oyCTf9CfAyX8rPhg6tvx2EnBklVyLyZmNdp6y/L2eyIZrFB8JvHcIR2g7amkJewxQVlOKKBmnrR51CUFevW4ONGhMBJkwlZTzEUKTQDUuldSGl/VXptpSe5MY8PcbvTm5yXfQxbkW0kXSyxVkEjnpnVCf03fm2ouN+ZD+LfA3TrTauR1inpw3pRzzxY8BB/Fef6STATCe6t589IAAgMKsQC9mCoDzRG7ULaZ1ciHuGEAvfA8VJhYR5mI+R3wAYzXQVJj+xcVAogJ9t4GJ2gNrfJ8E7uGDqoWw7JQoGXaonXX4JHIU0sQvozAj4GZi1wvkZyOZ+Wi/FsJl40BZCkiuvTzAykvechi91qoEc/5BLYJ4EFjoU6LvrlZQLGZL8g8Zj8DrB32XvEmnBFV9kSXtYUJEu7t87dtFq9gFwHoPaUk56ZHa4jQoj300zhqHm/E6BuslL3GckEeyRKoMnztq8/47NdRAF8Znv60gn8188GwmYYtDG4CGyevZbM5A4eMstrq63stncf95uWH8Enawpc+W8JyT+qj/+yWC/vWUZUFhMPBTemwyD/mo91m5EDmaCtBV9TTo/U1RiVRWghsGSpb18Khwn3tCQHedYgIBsOY3nnjVgvuBKruPIRBROXpfig4+yS+Wfz+wX4udOpIS9qBzJgNeLmkwj7EPizwtl/S/eJ/Cj2qPmiq7O6mQ2IsWLt/OL6AptPM9mWKkDQXrUy736WgWOXFNN6t02ctVvfLxwpiIHs42nWk3S4T5O5hFY9cFyzsvYzwj+2SmTv7LrLY+D0g78N7la1UT8bH4vdSjlRkhmAmvAZDUKrucoAXHFuuXwxmiGH0FsPQOCC+TjSft8W1D0OqCuBTddZ5hyyVYFyQxi0bc8ax6WrgaBOUswTqmu19/eI6EsPwywTzNxL5LAVFkfPMv6Ng7hCbAY8L8Pz4cHUDm5EnboQUzjnIZp7vXI/HAClzvrQLRQyOLnqp3sIbCYczR1ZlwRT7Ww7/rWKTGN5FdPPqANBBTqibTMt4FteW/Zh7+L+uc1lanB6m7sw/nmqmyfWcylTqDOjDAy/+gAWXwEwIVbXjaLazxLNP/rmpr5LyiVWm3YkZ/uzU1u5URwP4S/aMNTZOuIlQLp0tNroHhdrFkgPlBvFGnVo+KgTEZeAl6m3fKYiLtYsNhD15/VzIoL0ff302BYZlzKRnPNlE9FAMcC8OxKFTbXMTY5dLOKLQNT6a/F9Q7Oug0OsF09z8
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 02b5c2db-2ebd-429a-2794-08db249386c4
X-MS-Exchange-CrossTenant-AuthSource: GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2023 13:53:44.3984 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: lHjbqycSAfZnPodZGtLC+zgN7YKjz/N6iG0cjy/FbqmPlar3uWUbAqTwjtKPTAIZp6FDIDUVeb+wgiACUm9sZA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVYP280MB0078
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/IFjDFuZqvDZobKKRpIt2JFXz5uA>
Subject: Re: [core] [Lake] 🔔 Working Group Last Call (WGLC) of draft-ietf-core-oscore-edhoc-06
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2023 13:53:56 -0000

Hi John,

On 2023-02-28 12:57, John Mattsson wrote:
>
> One more comment:
>
> *  'cred-t', specifying a type of authentication credential supported
>
> by the server.  This parameter MUST specify a single value, and
>
> possible values are: "x509", for X.509 certificate [RFC5280];
>
> "c509", for C509 certificate [I-D.ietf-cose-cbor-encoded-cert];
>
> "cwt" for CWT [RFC8392]; "ccs" for CWT Claims Set (CCS) [RFC8392].
>
> This parameter MAY occur multiple times, with each occurrence
>
> specifying a different authentication credential type.
>
>
> I think this should be made into an IANA registry under "Ephemeral 
> Diffie-Hellman Over COSE (EDHOC)". The registry could be created by 
> the EDHOC document or draft-ietf-core-oscore-edhoc.
>

==>MT
Based on some recent discussions and avoiding to perturb 
draft-ietf-lake-edhoc at its advanced stage, version -07 of this 
document has defined the new IANA registry that you mention, see 
Sections 8.3 and 8.4.

Section 6 has also been updated accordingly, by revising the definition 
of the target attribute (now called ed-cred-t) and its use in the Web 
Link example of Figure 6.

Thanks,
/Marco
<==

>
> Cheers,
>
> John
>
> *From: *Lake <lake-bounces@ietf.org> on behalf of John Mattsson 
> <john.mattsson=40ericsson.com@dmarc.ietf.org>
> *Date: *Saturday, 25 February 2023 at 18:22
> *To: *Carsten Bormann <cabo@tzi.org>, Christian Amsüss 
> <christian@amsuess.com>
> *Cc: *core@ietf.org <core@ietf.org>, lake@ietf.org <lake@ietf.org>
> *Subject: *Re: [Lake] [core] 🔔Working Group Last Call (WGLC) of 
> draft-ietf-core-oscore-edhoc-06
>
> Hi,
>
> I have reviewed draft-ietf-core-oscore-edhoc-06. I think it is ready 
> with issues.
>
> - "Profiling EDHOC for CoAP and OSCORE"
>
>   Not sure this is a suitable name. It does not really profile EDHOC.
>
> - OLD "first subsequent OSCORE transaction" (several occurences)
>
> - NEW "first OSCORE transaction"
>
>   it is not subsequent anymore
>
> - "CoAP [RFC7252], CBOR [RFC8949], CBOR sequences [RFC8742], OSCORE
>
> [RFC8613] and EDHOC [I-D.ietf-lake-edhoc]."
>
>   IETF uses the Oxford comma. (Probably several occurences).
>
> - "may be set to application/cid-edhoc+cbor-seq." (several occurences)
>
>   Any reason this is not a normative MAY, also what is the reason for 
> not have SHOULD or SHALL? I don’t have a strong opinion.
>
> - OLD "not transported precisely in the request payload."
>
> - NEW "not transported in the request payload."
>
> But probably better to just say "as specified in Section 3.2, C_R is 
> transported in the OSCORE Option."
>
> - "using the new OSCORE Security Context established after receiving 
> EDHOC message_2."
>
> I think this should be "after creating EDHOC message_3"The context 
> depends on message_3.
>
> - "Check that the EDHOC + OSCORE request includes the OSCORE option
>
>    and that the request payload is a CBOR sequence composed of two
>
>    CBOR byte strings."
>
> Should check for the EDHOC option as well
>
> - The document is not clear on if you can send back an EDHOC error 
> over OSCORE or not. Itshould be.
>
> - As discussed in LAKE you can get 128-bit authenticatation security 
> by combinging two 64 bit tags. Has this been discussedin CORE? Ifthe 
> mechanism gives this propertyfor either peeris should be mentioned.
>
> - Is is clear what happens if the EDHOC + OSCORE Request is retransmitted?
>
> - "where the ID Context has zero-length."
>
> This seems wrong. There is nothing special with the zero-length ID 
> Context.
>
> This should be "where the ID Context is not present"
>
> - 'ead1', 'ead2', 'ead3' and 'ead4'
>
>   This makes no sense to me. Either you support EAD or not. Also 
> knowing that the other party support EAD is useless. You need to know 
> what kind of EAD. I stongly think this should use values from the 
> EDHOC External Authorization Data Registry.
>
> Cheers,
>
> John
>
> *From: *core <core-bounces@ietf.org> on behalf of Carsten Bormann 
> <cabo@tzi.org>
> *Date: *Wednesday, 15 February 2023 at 23:39
> *To: *Christian Amsüss <christian@amsuess.com>
> *Cc: *core@ietf.org <core@ietf.org>, lake@ietf.org <lake@ietf.org>
> *Subject: *Re: [core] [Lake] 🔔Working Group Last Call (WGLC) of 
> draft-ietf-core-oscore-edhoc-06
>
> On 15. Feb 2023, at 23:25, Christian Amsüss <christian@amsuess.com> wrote:
> >
> > * 3.2 step 3: "The first CBOR byte string is the EDHOC message_3
>
> Ah.
>
> We are using the term “byte string” to describe the generic data model 
> data item with that name (using major type 2 and enclosing a sequence 
> of bytes into a single data item).
>
> We are using the term “encoded CBOR data item” to describe the 
> sequence of bytes that results from encoding a CBOR data item (any 
> CBOR data item of course, not just a byte string).
>
> So where the byte string is h’010203’, the encoded CBOR data item 
> encoding that data item is 43010203 hex.
> The latter, of course, can be carried in another byte string 
> h’43010203’, which would then be encoded as 4443010203 hex.
> So it is really important not to confuse “CBOR byte string” with 
> “encoded CBOR data item”.
>
> (Of course, this distinction applies to any representation format that 
> can carry its own encodings, as in the JSON text
>
>     “{\”a\”: 1, \”b\”: 2}”
>
> which is obviously not the same as the JSON text
>
>     {“a”: 1, “b”: 2}
>
> In JSON this kind of embedding is rather expensive and thus done less 
> often, while in CBOR embedding encoded data items in byte strings is a 
> rather natural way to carry certain kinds of information.)
>
> Grüße, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core 
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cb66eec26b61d4cd7f8f708db1982fa09%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638131822569540872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2Bv2mnGOUTtKuwfeKkOknKwhEAC5n2RRzWCcquNeWdKc%3D&reserved=0>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: +46 (0)70 60 46 501

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se