Re: [core] ALPN "coap" for DTLS

Christian Amsüss <> Fri, 23 February 2024 15:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 188F0C14F5F9 for <>; Fri, 23 Feb 2024 07:09:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.907
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3j6rie3FTEfY for <>; Fri, 23 Feb 2024 07:09:10 -0800 (PST)
Received: from ( [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 (Postfix) with ESMTPS id E0DF3C14F5F2 for <>; Fri, 23 Feb 2024 07:09:07 -0800 (PST)
Received: from ([IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by (8.17.1/8.17.1) with ESMTPS id 41NF95od048721 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <>; Fri, 23 Feb 2024 16:09:05 +0100 (CET) (envelope-from
X-Authentication-Warning: Host [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd] claimed to be
Received: from (hermes.lan []) by (Postfix) with ESMTP id 5B83533E99 for <>; Fri, 23 Feb 2024 16:09:04 +0100 (CET)
Received: from (unknown [IPv6:2a02:61:a2::907]) by (Postfix) with ESMTPSA id B78603100E for <>; 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 <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="i+vTTpKqNvKZPg9F"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [core] ALPN "coap" for DTLS
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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" (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


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