Re: [core] Mandatory ALPN indication and non-TLS protocols (eg. OSCORE) Wed, 29 March 2023 00:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1634EC15171B; Tue, 28 Mar 2023 17:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.604
X-Spam-Status: No, score=0.604 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, FSL_HAS_TINYURL=2.699, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OwXN9MkEfiyS; Tue, 28 Mar 2023 17:55:20 -0700 (PDT)
Received: from ( []) (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 B1868C1524AA; Tue, 28 Mar 2023 17:55:19 -0700 (PDT)
Received: from (unknown [xx.xx.xx.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4PmSl94l38z2xx9; Wed, 29 Mar 2023 02:55:17 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1680051317; bh=x5541czBFjexVbsbDw4g9+j8RDPWgho5sh/f3pcblX8=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=MElvkcaZ3ozPd1L+fdSiYShqOa4g9HC1cGI5T/T8kDhP6XmyVXLai2DSF2GcDjiI7 RSD5UFmrF0YrYEhj7ymGgL/dEf6bTZoIqLwKKk40QCKVc+zclIdR0oUGWcAySUXAh7 bPfbwhx/ESJrNkPZI2BJQuT+F33BaFWRMBcvxKQ1oAWhAtMWtD87jMsKS47Gr262gI 2SPLl7Z46I/zrE3B+F8R9iukWjDzdvcftVsS9Cf3qfcHZcQBgplWpUmexoMpsX3Yvs S97r0L2zYspIkhOHmKXJLwtROwV0sAexBgsHr7J50+zETF/1moOwheHd1HnGPxqwdW VI3euhDf38Naw==
To: Christian Amsüss <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Mandatory ALPN indication and non-TLS protocols (eg. OSCORE)
Date: Wed, 29 Mar 2023 00:55:17 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2023-03-28T08:34:42Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=1e1ebd89-3b57-44ce-a868-ceffe1ebb33c; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [core] Mandatory ALPN indication and non-TLS protocols (eg. OSCORE)
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: Wed, 29 Mar 2023 00:55:24 -0000

Hi Christian, 

Thank you for raising this point.

I think that you have a reasonable exception case where alpn may not be present. So, rather than "MUST alpn or ..." you proposed, I suggest the candidate changes at:

Please check and let me know if this works for you. Thanks.


> -----Message d'origine-----
> De : Christian Amsüss <>
> Envoyé : dimanche 26 mars 2023 19:01
> À :
> Cc :;;
> Objet : DNR: Mandatory ALPN indication and non-TLS protocols (eg.
> Hello DNR authors and -group,
> hello CoRE group (as this mainly affects OSCORE based protocols),
> (Context)
> A protocol of the CoRE group, DNS-over-CoAP[1], when used with
> encryption (as is recommended), can use either of two security
> mechanisms: DTLS and OSCORE, with some expectations that the latter
> will be used a lot.
> Following DNSOP suggestions in for draft-ietf-core-dns-over-coap,
> I've looked at the DNR draft from the point of view of advertising
> DNS-over-CoAP services. While announcing DNS-over-CoAP-over-DTLS
> would be straightforward[^2], there is no clear path yet about how
> OSCORE protected services would be announced. This path is about to
> be explored, with no apparent need for ADD interaction -- except for
> one
> detail:
> (Proposal)
> DNR currently mandates that the SvcParams field 'MUST include at
> least "alpn" SvcParam"'. Given that ALPN is specific to TLS at least
> since RFC8447, that mandate rules out any advertisement of secure
> communication that is not TLS based.
> I suggest to say
> > This field MUST include at least "alpn" SvcParam (...), *or an
> > SvcParam that indicates some other security and disambiguation
> mechanism*.
> Depending on the requirements that led to the "MUST" in the first
> place, it may be necessary to add that
> > In the latter case, that SvcParam MUST be included in the
> "mandatory"
> > SvcParam.
> Please let me know if this is the preferred way to support non-TLS
> protocols, and the change is motivated sufficiently in this mail. I'm
> confident we paint a more concrete picture of how this would play out
> in collaboration with the OSCORE and EDHOC authors, but that activity
> is just getting started after having been made aware of SVCB through
> DNR, so it may take until after the current meeting to provide the
> additional motivation.
> Best regards
> Christian
> [1]:
> [^2]: This will need some text somewhere stating how it extends on
> the CoAP-over-TLS ALPN, but nothing major.
> --
> I shouldn't have written all those tank programs.
>   -- Kevin Flynn


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.