Re: [core] ALPN "coap" for DTLS

Christian Amsüss <christian@amsuess.com> Fri, 23 February 2024 15:09 UTC

Return-Path: <christian@amsuess.com>
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 188F0C14F5F9 for <core@ietfa.amsl.com>; Fri, 23 Feb 2024 07:09:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 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, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 3j6rie3FTEfY for <core@ietfa.amsl.com>; Fri, 23 Feb 2024 07:09:10 -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 E0DF3C14F5F2 for <core@ietf.org>; Fri, 23 Feb 2024 07:09:07 -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 41NF95od048721 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <core@ietf.org>; Fri, 23 Feb 2024 16:09:05 +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.lan [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5B83533E99 for <core@ietf.org>; Fri, 23 Feb 2024 16:09:04 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:61:a2::907]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id B78603100E for <core@ietf.org>; Fri, 23 Feb 2024 16:09:03 +0100 (CET)
Received: (nullmailer pid 20859 invoked by uid 1000); Fri, 23 Feb 2024 15:09:01 -0000
Date: Fri, 23 Feb 2024 16:09:01 +0100
From: Christian Amsüss <christian@amsuess.com>
To: core@ietf.org
Message-ID: <Zdi1DaM64AwO6BaV@hephaistos.amsuess.com>
References: <ZCAdXXuvkqmn5eFB@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="i+vTTpKqNvKZPg9F"
Content-Disposition: inline
In-Reply-To: <ZCAdXXuvkqmn5eFB@hephaistos.amsuess.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/MLTkAFXL-Yyo_02Xus7AdgtItaA>
Subject: Re: [core] ALPN "coap" for DTLS
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: Fri, 23 Feb 2024 15:09:14 -0000

Hello CoRE,

tl;dr: I will request an ALPN for CoAP-over-DTLS 5 days from now if
nobody objects.

On Sun, Mar 26, 2023 at 12:24:29PM +0200, Christian Amsüss wrote:
> processing reviews for DNS-over-CoAP[1] showed that while we do have an
> ALPN and usage guidance for CoAP-over-TLS (ALPN "coap"), there is no
> referencable text on whether and how CoAP-over-DTLS can be disambiguated
> in an ALPN. While the general specification situation is a bit dire on
> mixing DTLS with ALPNs[^2], it appears to be readily used[3].

The way ALPNs are used in DNR ([RFC9463]) indicates to me that we'd need
a different ALPN for CoAP-over-DTLS (because otherwise a DNR SVCB
doesn't indicate whether to use TCP or UDP), which is also aligned with
what Ben Schwartz said on the topic[5].

Therefore the next action in this is to request an APLN ID for
CoAP-over-DTLS. The registry is [6], policy is Expert Review, method of
registration is "check with experts on tls-reg-review@ietf.org" (who are
"advised to encourage the inclusion of a reference to a permanent and
readily available specification"). Sounds like we can just ask for that
(RFC7252 can serve as the specification, entering existing RFCs into
expert-review registries is not too uncommon).

So, a brief last check before I send the following to the experts over
there at the end of the month -- any better ideas?

> Dear TLS experts,
> 
> please have the following entry added into the TLS ALPN registry:
> 
> * Protocol: CoAP-over-DTLS
> * Identification sequence: 0x63 0x6f ("co")
> * Reference: RFC7252
>
> RFC7252 did not register this because it predates ALPNs, but there are
> now use cases related to dns-over-coap [7] and SVCB.
>
> Given that the underlying protocol is used in constrained environments
> that are sensitive to message sizes, the short identifier should be
> warranted.
> 
> Note that there is already an entry for "coap", but that refers to
> CoAP-over-TLS.  If possible, please consider updating the "CoAP" (0x63
> 0x6f 0x61 0x70) entry to say "CoAP-over-TLS" to avoid confusion. This
> is following the recommendation at [5] to not attempt reusing the same
> ALPN for both the DTLS and the TLS version of a protocol.

Best regards
Christian

[RFC9463]: https://www.rfc-editor.org/rfc/rfc9463
[5]: https://mailarchive.ietf.org/arch/msg/core/8wdEwrzU2s8xYEvYpzh_tGQxYUY/
[6]: https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
[7]: https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom