[Add] DNR: Mandatory ALPN indication and non-TLS protocols (eg. OSCORE)
Christian Amsüss <christian@amsuess.com> Sun, 26 March 2023 10:01 UTC
Return-Path: <christian@amsuess.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE5BC14CE42; Sun, 26 Mar 2023 03:01:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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
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 0eIZv5weNXmD; Sun, 26 Mar 2023 03:01:28 -0700 (PDT)
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 8D720C14CF1B; Sun, 26 Mar 2023 03:01:22 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 32QA1IJ9034698 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 26 Mar 2023 12:01:19 +0200 (CEST) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host 095129206250.cust.akis.net [95.129.206.250] 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 1DA641D995; Sun, 26 Mar 2023 12:01:18 +0200 (CEST)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A307C20028; Sun, 26 Mar 2023 12:01:17 +0200 (CEST)
Received: (nullmailer pid 32227 invoked by uid 1000); Sun, 26 Mar 2023 10:01:17 -0000
Date: Sun, 26 Mar 2023 12:01:17 +0200
From: Christian Amsüss <christian@amsuess.com>
To: draft-ietf-add-dnr@ietf.org
Cc: draft-ietf-core-dns-over-coap@ietf.org, add@ietf.org, core@ietf.org
Message-ID: <ZCAX7fsvkxJsr8+K@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="e3lFA/e0jHTYdmNr"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/zo0vZZg8z6w883pnFKQPStDPagU>
Subject: [Add] DNR: Mandatory ALPN indication and non-TLS protocols (eg. OSCORE)
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Mar 2023 10:01:30 -0000
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]: https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/ [^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
- [Add] DNR: Mandatory ALPN indication and non-TLS … Christian Amsüss
- Re: [Add] DNR: Mandatory ALPN indication and non-… Benjamin Schwartz
- Re: [Add] DNR: Mandatory ALPN indication and non-… Dan Wing
- Re: [Add] [core] DNR: Mandatory ALPN indication a… Christian Amsüss
- Re: [Add] Mandatory ALPN indication and non-TLS p… mohamed.boucadair
- Re: [Add] [core] Mandatory ALPN indication and no… Christian Amsüss
- Re: [Add] [core] Mandatory ALPN indication and no… mohamed.boucadair
- Re: [Add] [core] DNR: Mandatory ALPN indication a… Benjamin Schwartz