Re: [Lake] [core] 🔔 Working Group Last Call (WGLC) of draft-ietf-core-oscore-edhoc-06
Christian Amsüss <christian@amsuess.com> Wed, 15 February 2023 22:25 UTC
Return-Path: <christian@amsuess.com>
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 9FD5AC1782AE; Wed, 15 Feb 2023 14:25:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ZTk6DPuWZrgX; Wed, 15 Feb 2023 14:25:47 -0800 (PST)
Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C1FC16B5D4; Wed, 15 Feb 2023 14:25:43 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com ([IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 31FMPe0h052196 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Feb 2023 23:25:40 +0100 (CET) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 2BD9C1B329; Wed, 15 Feb 2023 23:25:39 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::907]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id DA2501D8D1; Wed, 15 Feb 2023 23:25:38 +0100 (CET)
Received: (nullmailer pid 5729 invoked by uid 1000); Wed, 15 Feb 2023 22:25:38 -0000
Date: Wed, 15 Feb 2023 23:25:38 +0100
From: Christian Amsüss <christian@amsuess.com>
To: core@ietf.org
Cc: lake@ietf.org
Message-ID: <Y+1b4qX6Ya7BCbvk@hephaistos.amsuess.com>
References: <F02C5E48-A196-45EC-8576-6BC67EC26AD3@tzi.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="RMuuWhOJCwzv4CcY"
Content-Disposition: inline
In-Reply-To: <F02C5E48-A196-45EC-8576-6BC67EC26AD3@tzi.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/keujZ1nJ3ydJA37hZtvppZ3pvL0>
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: Wed, 15 Feb 2023 22:25:49 -0000
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. * Figure 4 (full coAP message): * There might also be CoAP options before the EDHOC option, in particular Observe. * 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. * 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). * 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). * 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? * 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. * "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). * "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). * 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). * 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. * 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. (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). * 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 * Figure 6 The Web Link: None of the values in here need quotation marks around them. * 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. * 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? BR Christian -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
- [Lake] 🔔 Working Group Last Call (WGLC) of draft-… Carsten Bormann
- Re: [Lake] [core] 🔔 Working Group Last Call (WGLC… Christian Amsüss
- Re: [Lake] [core] 🔔 Working Group Last Call (WGLC… Carsten Bormann
- Re: [Lake] [core] 🔔 Working Group Last Call (WGLC… John Mattsson
- Re: [Lake] [core] 🔔 Working Group Last Call (WGLC… Christian Amsüss
- Re: [Lake] [core] 🔔 Working Group Last Call (WGLC… John Mattsson
- Re: [Lake] [core] 🔔 Working Group Last Call (WGLC… John Mattsson
- Re: [Lake] [core] 🔔 Working Group Last Call (WGLC… Christian Amsüss
- Re: [Lake] [core] 🔔 Working Group Last Call (WGLC… John Mattsson
- Re: [Lake] [core] 🔔 Working Group Last Call (WGLC… Christian Amsüss
- Re: [Lake] [core] 🔔 Working Group Last Call (WGLC… Marco Tiloca
- Re: [Lake] [core] 🔔 Working Group Last Call (WGLC… Marco Tiloca
- Re: [Lake] [core] 🔔 Working Group Last Call (WGLC… Marco Tiloca
- Re: [Lake] [core] 🔔 Working Group Last Call (WGLC… Christian Amsüss