[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