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

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

Return-Path: <marco.tiloca@ri.se>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C57C15152E; Tue, 14 Mar 2023 06:33:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, NICE_REPLY_A=-0.001, 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=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 DzrhEMHoOkj5; Tue, 14 Mar 2023 06:33:31 -0700 (PDT)
Received: from GVZP280CU001-vft-obe.outbound.protection.outlook.com (mail-swedencentralazlp170110002.outbound.protection.outlook.com [IPv6:2a01:111:f403:c202::2]) (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 CDB4AC152577; Tue, 14 Mar 2023 06:33:30 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S3NZ8lbOERmbec8tXcTVVL3WLGFTrGB3dHYC7hAcO4KoeypRfcNjowVpi5gPF1gK1z4L5oSlLLd/gXgrUSrjfNW1QbwXqgMiJGust2jiiGzQHs52PGxvIkZjIgIsKGKHyLZfxFi9OFxyfIjXeUaBSAETuTht7lKOmwNIieenRcMcGq1xpWy+S8ELtEiw5xQlyn1CBZg6nw6AzIw7fscUJN3Xhoj5Gv943b3S3uSmK1DJL+DkiHAwO3Awmqtp0ajPrhuX9xSXGn4ma68o1+LRwk0ADrg59mpoF+SrfvtK9cGaDXTSXixalRuZS2hn/WJg0Ueg7OQfHk/SCk5fBiy3jA==
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=UWoHQXy5Gp4Lcp0L7Ws5FUgCThUv6HhvleGXEPw0XX0=; b=SxNIlYjVEH8jZ8YH/I1HQxCN6eFG5CebvzW39aZzIlALA8PaBppakM50r/r/UmY06yp/mrGsQaKdtfm1caQb0dI94xlp7zTZo9SXw9qy+VyCprHadA+SMTw2+22K+bs40mLlI3XP6NOEZkLY9gpWAYQ43KQ1ORGPSn20hWPZwOYXPvYVfE35oUbnOKWihJOj6LkCsWUrolnVoq8gP5KGGes0TOyYvQYOHpCoRh36j4W9AfbSWduG112vMFk7+Hts9MXE8UTtNcj3xwM7rrppphfmEmEilbcsX6sZD2JvIWR6EAh/UCI2hfjyPt0WcDgG1e4K7XyqrEc2isV/BqBX4Q==
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=UWoHQXy5Gp4Lcp0L7Ws5FUgCThUv6HhvleGXEPw0XX0=; b=iHxHLSFyHAtAk1RqfZX1HLSI3IGWY+FNLljq0P+8pUR4ZMHVyHW2OZW6Q4CHBRUEDMK0oItAg36JtA4lyFMLLvBRRsX0pSHrC5/IOkBmmZ8Jr5H61jkX9Y1y+tH5RVZQY6a6gMfvgm2ZepVcNjZEmcg4j22qMJhK7jq1b3RRjdk=
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 GVZP280MB0170.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:42::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:33:25 +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:33:25 +0000
Message-ID: <1d38ecf9-4a70-046d-fa47-05b75ebb2feb@ri.se>
Date: Tue, 14 Mar 2023 14:33:23 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0
Content-Language: en-US
To: Christian Amsüss <christian@amsuess.com>, core@ietf.org
Cc: lake@ietf.org
References: <F02C5E48-A196-45EC-8576-6BC67EC26AD3@tzi.org> <Y+1b4qX6Ya7BCbvk@hephaistos.amsuess.com>
From: Marco Tiloca <marco.tiloca@ri.se>
In-Reply-To: <Y+1b4qX6Ya7BCbvk@hephaistos.amsuess.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------TRU9ySj7nV7hXIY2292ux1gU"
X-ClientProxiedBy: GV3P280CA0053.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:9::21) To GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:37::17)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: GVYP280MB0464:EE_|GVZP280MB0170:EE_
X-MS-Office365-Filtering-Correlation-Id: 7d748b59-129c-4fdf-c1b9-08db2490afbf
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: bza8JGVf31zfy0Yyf2NrrYpUJtjpW1Des5yhPqCx+C7oUByjyxnI8jKB9CGgLbqcAq1mLXWOpiGblshVn+RH7F9Lqltx4tUgXeFoZi/Fw+/cFJojBO5D9J03BLVRqc5JiOe1YJwmt52N7MVOakS395CsaBhtf7kvIfDUK+eYUXlujgFxnkvY8Ma9KRv/k0Sl77faWDZGCPtMTChqdV5XkIjqeUSxpwGI++lx4a3Ak5AYRHRYDtXNnhGxZFFrjWi+IEUrj8uHmrv40I9+wpKfexMJypLOJ7mwZdi0rTZfJBH7q3LMb/OT6h1oFOdYhOklkrPTSUBArnhMBU/P8+BN/2X4qfhggml7pc8Ju7Xm71Y721IqrjSCga5Ebo2276b28spq/4k24njJ1X+XLotQx3JU+DIi8HG8/FxbstAKt+U5gLdHDr/llnuhbdl7kt3GKU7riBYeAYQ6z6Tj0l2mdOiG/LROU+mxoCVVBP/V2haibyTYQrd+V22p54B5Np/H/X77x4pN6ebmT9CAgHyEK7+YIeuPv7gyuJkZn+IcQ2cyvbcMfp+5gK2l6g8phUh3RrARvL7vOJtLgGD4nMWYQIr0ekgeaZD+vCDqpEjVOD8YbVew+P4CEiDWdlMRfs59wtVf8ETPjRlc0I779Buh0Q/08pe79FqOUfduwDJBb3QlNqPwIJenOUfm6UI5jX/MNaw4n7hZxxDlIGQaBgwfJTscoT2xKT+6qjl3zHk5T3w=
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)(346002)(376002)(396003)(39860400002)(366004)(451199018)(30864003)(5660300002)(235185007)(478600001)(2616005)(2906002)(53546011)(6506007)(33964004)(6512007)(26005)(6486002)(966005)(36756003)(21480400003)(186003)(44832011)(86362001)(66574015)(31696002)(166002)(41300700001)(38100700002)(4326008)(31686004)(66556008)(66476007)(66899018)(8936002)(66946007)(316002)(83380400001)(43740500002)(45980500001); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 2NJ5tZ8n72CQam8RP0oSayD0QnWe9J7Phu4vOg1LYXCfgMKYEil9+oNq82lKueOxdvXNonr/487Y7mY+z01yYHZ9lOAmNb6oDVzJyMZMZpxxBc8v1TxJ5tFGHslvBKPV4HLEGfTLJdfURyiuS8e2sbNEnP7YHFUA6Znk6Z56kNGs7gwxYeWYYuAiDDBPlcYeavCyokBQa3GaWgTv2tyK13dKP+uJfefFfAbsX3+FnNX0IZ+eyjMIhjgoGdnqWUUvHcKz0K9MENtLTvCMHGHTMOQSVNIYaFLMl4Q45Fc6fcYgckugAl3+9e9e/diZ2BmGvmSxueNftjlioTENj4UbyziAU0CMjb7IT2cRlb37eYcOaVn6NMjQe91xIs20U+1vTG+JZZa/XQYYnNdkqth5huKRV0SU6LyjKoC6OKyxac7j1IZjO+NsaTKQESEyzbYOOrCNMOIPq8s/IyKaIPsIshDlYFv4u+s2pl3HnS79uIL6CXBQMjwTQpHNlyuk8H2LJMcY5r3FQ59lPhh5zKA6Ztjy8Fo1LQavFE6kjqaLLSnDnsibMsbd7e86XGtmcYw1/fQ36ZwIWFzkBJJC8DenGxtlJ/6+H6Mcka4M59PyuSMM7llbQbuZ05rnRQDzL0CXwJP9GqRL3EwgNXqK3pjaaSvfpIyBdmPWS0FRjmLr0mz9retrA9IBBuslBNNDjOTbrXyu+YA83KDgIGQV5GTroPM2KSZ767E13xP0rQjxJ5laj8ZA37BZ3+2N673O41uHdFIRPZvN8Hf13UXmsPEoI5THXAZud/ODDuwlrB5P1qUxBxIXxYNgZIHpCVJD+MkWpzblvR7m3OPJ4aGMuXJynUvMPzTYB3fJPeMfcQpQJcpwnIExR0bvRGkE0lQ1ZqWeADQa9wb2+o5ksV5y/Ts++k0k7ePMRh0wueHD7mzoNIdqfbWntokLBpQLMmCFckytNLrUeeWx2gxkMYeJjF8nJp01fSB8l2EZWUvA9vAYfZwoyM7cKWhrshoFrvgitNfgBXLDkUtWIUnwrGZ34VMIy1trG2pPFD4dSrXvG2XSOIiQiELgBg1BtVFfymp98pHt4hcxoaedyvfz0Va/6DIFN7QPvzxn6ERYCu3w9F1nZ7Rx7iSmxNc9iwc8nzU/w2fbz7B8dQS0wlcoKUb6g3ckFNTOEbxDbfXydVeUCHwRPVkm/H/4XpRB1qKbyBsZbdKttVZleKyXlYqDO1ccAurnSoNG3+7jIk9atbaMHkri6eLKpx5+k33PubEi89WYtS9NFaFcagsLyOX+on39+X3XXyuQhfeSEca7EI1DlznupRXwFPxXoXqgnSwPPI8tCAfk1ob+06+LEDQ+0t8Y0T6clHtvCXupQESiu6k18bRaUv09B4HTe9SruQPW5BosN4NTudOv432wGJOiaxlE7SmL0z1JQFtLBw2JFQ6wtsjn8LBtU5lBGfsxm36KVE+FfuVl26JbNZrrb4Y3LzZiBYSRgIhY9BE8vGtXdQV4HmIOoon48GRdlbGNodJ7KKMDF6ES7Ch8qQMsSLhNd2w92G9wYzWAZi7T/yvnLkdUBtneRNBPvTI9JXn0L4IdR+bQMNkH
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 7d748b59-129c-4fdf-c1b9-08db2490afbf
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:33:25.1776 (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: FqsagNE/CeRwZnCINVnL8wlCJg5Vi/fA8fLE32wMc6hNEgWndNIwkn6baop9mfK2Ph0kYj1ISm0t9EOD5Iy3fQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVZP280MB0170
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/pt97FWsxN_GpGPlLae8_BtL6kiM>
Subject: Re: [Lake] [core] 🔔 Working Group Last Call (WGLC) of draft-ietf-core-oscore-edhoc-06
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2023 13:33:35 -0000

Hi Christian,

Thanks a lot for your review! We have addressed your comments in the new 
version -07.

Please find detailed answers in line.

Best,
/Marco

On 2023-02-15 23:25, Christian Amsüss wrote:
> Hello,
>
> I have a few comments and questions on the document. They'r in linear
> sequence; I hope to not reiterate too much on points that have been
> discussed exhaustively (as I'm not up to date on all threads pertaining
> to the document).
>
> None are particularly critical (AIU it's the chairs' call whether
> something blocks a WGLC anyway, I think most outcomes can be addressed
> post-WGLC), although I'd like to see at least the Section 6 example
> addressed.
>
>
> * Section 2 might profit from an introductory line along the lines of
>
>    | This section (is not normative and?) summarizes what is specified in
>    | [I-D.ietf-lake-edhoc], in particular its Appendix A.2, and thus
>    | provides a base-line for the enhancements in the subsequent
>    | sections.

==>MT
Added with minor editing, i.e.:

     "This section is not normative and summarizes what is specified in 
[I-D.ietf-lake-edhoc], in particular its Appendix A.2. Thus, it provides 
a baseline for the enhancements in the subsequent sections."
<==

>
> * Figure 4 (full coAP message):
>
>    * There might also be CoAP options before the EDHOC option, in
>      particular Observe.

==>MT
Right; we've redrawn the figure to also show the presence of an outer 
Observe option.

The text introducing the figure as well as its caption has also been 
edited in order to stress that this is just an example.
<==

>
>    * Could you add something about "example" in here? Such a message
>      could be sent over any transport, such as CoAP-over-TCP, and then
>      some of that figure doesn't apply.

==>MT
We have expanded the introductory text and the caption of both Figures 4 
and 5 (see Sections 3.1 and 3.4) to stress that this is just an example 
considering specifically CoAP over UDP.
<==

>
> * 3.2 Client processing: This speaks of an "original CoAP message". I
>    know from context what is meant, but the term could be more
>    descriptive. Maybe "Encrypt the first application CoAP request as an
>    original message per Section 8.1"?
>
>    (The term reappears in 3.2.1 Supporting Block-wise).

==>MT
Rephrased as you suggest in Section 3.2.0 and 3.2.1.
<==

>
> * 3.2 step 3: "The first CBOR byte string is the EDHOC message_3
>    resulting from step 1." could tempt an implementer to encode the
>    message_3 into a bstr; I take it that the intention is to send
>    CIPHERTEXT_3 in only one layer of byte strings.
>
>    I therefore suggest the wording:
>
>    | [...] composed of two CBOR items in the following order.
>    |
>    | The first CBOR item is the single item of EDHOC_message_3 (which is
>    | CIPHERTEXT_3, a byte string).

==>MT
We have revised the text in Sections 3.2 and 3.3 to properly use "CBOR 
data item" and "CBOR byte string" where appropriate.
<==

>
> * 3.2 step 3: I missed that at some point in the evolution of this
>    protocol, prefixing the (non-CBOR) OSCORE message with a CBOR stream.
>
>    This seems unnecessary to me, given that the previosu EDHOC_message_3
>    is well delimited, and the OSCORE message can well be the bytes to the
>    end (a concept for which has been taken up in RFC9277 for CBOR-labeled
>    non-CBOR data), and will typically waste 2-3 bytes (rarely 1 -- for
>    that, the full OSCORE message needs to fit in 24 bytes).
>
>    Was there a particular reason for this change?

==>MT
That was actually the original design choice from the start :-)

We have now changed the payload format as you suggest. This resulted in 
updating:

- Steps 2 and 3 in Section 3.2 "Client Processing"
- Steps 1, 2 and 6 in Section 3.3 "Server Processing"
- The example shown in Figure 5 of Section 3.4.

<==

>
> * 3.2.1 item A is quite a mouth-ful to say that "On Inner Block-wise,
>    3.2 only applies to the first block", but I see that given how the
>    rest is phrased, it is unavoidable.
>
>    Maybe using the term "first application CoAP request" suggested above
>    opens an avenue for making this easier to comprehend.

==>MT
Yes, we have rephrased as you suggest.
<==

>   
> * "If the decrypted request includes an EDHOC option but it does not
>    include an OSCORE option, the server MUST stop processing the request
>    and MUST reply with a 4.00 (Bad Request) error response."
>
>    My understanding of this sentence is that EDHOC's criticality applies
>    after decryption again, and a server must not silently ignore an inner
>    EDHOC option without a matching OSCORE option.
>
>    While this is in the right scope for a message it processes as an
>    end-to-end message, it is out of scope if we're in a oscore-proxies
>    situation (which of course we don't have normatively yet, but I don't
>    want this to bite us later -- it could bite if, for example, the inner
>    OSCORE connection with the origin server used some OSCORE-version-2
>    with a dedicated option that our proxy doesn't need to know).
>
>    I suggest the following wording instead:
>
>    | When the decrypted request is checked for any critical options (as
>    | it is during regular CoAP processing), the presence of an EDHOC
>    | option MUST be regarded as an unprocessed critical option, unless it
>    | is processed by some further mechanism.
>
>    (The current phrasing implies that an inner OSCORE option could be
>    processed, which is currently still forbidden; this wording avoids
>    that while leaving the door open).

==>MT
Great point! We have added your suggested text as is.
<==

>
> * "The EDHOC option is registered with CoAP option number 21.": This
>    line could take a note that the RFC editor should remove this line (as
>    at time of publication, this will be a registered fact and not an
>    assumption).

==>MT
We have added a note to the RFC Editor in Section 3.4.
<==

>
> * 4.1. Additional Processing of EDHOC Messages: So far, this document
>    offers an additional mechanism; now suddenly we get universal
>    normative requirements. When do these apply? My assumption is that
>
>    | When using EDHOC to establish an OSCORE context, client and server
>    | MUST perform additional steps during EDHOC, extending Section 5 of
>    | EDHOC:
>
>    (They feel much more like a "needs to" to me, because they all stem
>    from requirements in the cited documents, but this sounds like a
>    "MUST" that someone insisted on at some point, which I won't fight).

==>MT
Rephrased as you suggest, with minor editing, i.e.:

     "When using EDHOC to establish an OSCORE Security Context, the 
client and server MUST perform the following additional steps during an 
EDHOC execution, thus extending Section 5 of [I-D.ietf-lake-edhoc]."
<==

>
> * 4.1.1: This reads needlessly imperative to me -- what does the looping
>    process give that a simple
>
>    | The initiator MUST choose a C_I that is neither used in any current
>    | EDHOC exchange as this party's identifier, nor the Recipient ID in
>    | a current OSCORE context whose ID Context is zero-length. The chosen
>    | C_I SHOULD not be the Recipient ID of any current OSCORE context.
>
>    does not give?
>
>    Same goes for section 4.1.2, where the "neither" group gains the C_I
>    as an extra clause.
>
>    (The concept of atomicity is not really needed when phrasing it as a
>    closed expression rather than an imperative program).
>
>    By the way, there is a subtle error that the above text would fix
>    compared to the current text: "If ID* is already used as EDHOC
>    Connection Identifier C_I," is only looking at our C_I, but it'd need
>    to also look at our C_R for the host can concurrently be in an EDHOC
>    exchange where roles are reversed.

==>MT
Thanks! We have greatly simplified Sections 4.1.1 and 4.1.2 building on 
your suggestion.
<==

>
> * Section 6: I would not expect to have much need of that content, but
>    trust that thought went into potential use cases.
>
>    A property that I'd be missing if I wanted to plan a complete EDHOC
>    exchange ahead is whether or not the forward or the reverse message
>    flow is supported.

==>MT
As concluded at the 2023-03-01 CoRE interim meeting, in Section 6 we 
have defined the two target attributes ed-i and ed-r, which indicate at 
once both the supported role and the supported message flow.
<==

>
>    (If I used things that way I'd also want to know, for the cred-t=cwt
>    case, which AS's tokens the server would accept, but that's probably
>    for the ACE EDHOC profile).
>
>    EDHOC treats application profiles like something that is defined by an
>    application (be it as in some-piece-of-software or as in
>    some-SDO-protocol), where the set of acceptable methods etc. follows
>    from what that application says. Wouldn't it make more sense to guide
>    those who define application protocols to how to make the
>    application-protocol-as-a-whole discoverable (maybe by declaring
>    rt="core.edhoc my-sdo.edhocprofile", or using a dedicated attribute)
>    rather than detailing out every single property that profile has?
>
>    I wouldn't expect a device to just go around willy-nilly attempting to
>    use any profile where the shoe fits. I'd expect it to know what it
>    wants to do (which profile it wants to use), and then search precisely
>    for a resource that'll do that profile (and expect the peer to heed
>    what's specified in there).

==>MT
As concluded at the 2023-03-01 CoRE interim meeting, it would be better 
if it is draft-ietf-lake-edhoc (or any follow-up work) possibly defining 
a new IANA registry for EDHOC application profiles and their identifiers.

When that happens, it would be useful to have a target attribute such as 
"ed-prof", with value the name of an EDHOC application profile that the 
server supports. The document defining the registry can define the 
target attribute as well.

So, no action taken here.
<==

> * Figure 6 (The Web Link) gives an example with multiple EDHOC
>    resources, without giving any plausible reason for why different
>    profiles would be in place. (Note that a single EDHOC resource should
>    very well be capable of serving even two different application
>    profiles).
>
>    This kind of example has a tendency to be copied over into people's
>    setups without much thought, so the thought needs to go in now.
>
>    I suggest taking one of two routes:
>
>    * Explain why there would be two distinct EDHOC resources, or
>    * preferred: just describe the /.well-known/edhoc resource

==>MT
As agreed at the 2023-03-01 CoRE interim meeting, we reverted the 
example to be like it was until version -02, i.e., to use 
/.well-known/edhoc instead.

The example has also been overall revised to use new target attribute 
names prefixed with "ed-", as well as "ed-cred-t" now taking value from 
a new IANA registry that John suggested to define in his review.
<==

> * Figure 6 The Web Link: None of the values in here need quotation marks
>    around them.

==>MT
Fixed.
<==

>
> * Appendix A: Sorry, didn't check this one.
>
>    Frankly, I think this is a bit excessive, and would be more suitable
>    for an LWIG document, or the detailed documentation of an EDHOC
>    library.

==>MT
We have removed the appendix, and added the following statement at the 
end of Section 3.2.1 "Supporting Block-wise":

     "The performance advantage of using the EDHOC + OSCORE request can 
be lost, when used in combination with Block-wise transfers that rely on 
specific parameter values and block sizes."
<==

>
> * General: I'm not sure whether it would make sense to define a general
>    application profile for "Let's talk OSCORE over CoAP", that allows
>    everything that works for EDHOC-OSCORE, and is what /.well-known/edhoc
>    would default to.
>
>    Users don't need to do an application profiles when using DTLS
>    "web-PKI-style", so why should they here? Or is this a distinction
>    mark, because we *don't* expect "web-PKI-style" to be the implied
>    default in EDHOC?

==>MT
As concluded at the 2023-03-01 CoRE interim meeting, it would be better 
if it is draft-ietf-lake-edhoc (or any follow-up work) that possibly 
defines a well-known EDHOC application profile.

So, no action taken here.

Thanks a lot again!
<==

>
> BR
> Christian
>
>
> _______________________________________________
> 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