Re: [core] [Add] DNR: Mandatory ALPN indication and non-TLS protocols (eg. OSCORE)

Christian Amsüss <christian@amsuess.com> Tue, 28 March 2023 08:24 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 59AA1C14CE5F; Tue, 28 Mar 2023 01:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 LuDNzgubd2gS; Tue, 28 Mar 2023 01:24:29 -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 5F00EC14CF1C; Tue, 28 Mar 2023 01:24:24 -0700 (PDT)
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 32S8OKI5092404 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Mar 2023 10:24:20 +0200 (CEST) (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.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 485581DB01; Tue, 28 Mar 2023 10:24:20 +0200 (CEST)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::907]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 1830420253; Tue, 28 Mar 2023 10:24:20 +0200 (CEST)
Received: (nullmailer pid 23690 invoked by uid 1000); Tue, 28 Mar 2023 08:24:19 -0000
Date: Tue, 28 Mar 2023 10:24:19 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Benjamin Schwartz <ietf@bemasc.net>, Dan Wing <danwing@gmail.com>
Cc: draft-ietf-add-dnr@ietf.org, draft-ietf-core-dns-over-coap@ietf.org, add@ietf.org, core@ietf.org
Message-ID: <ZCKkM7w6oRDkxxlG@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="noB2twOqEDCTvIy8"
Content-Disposition: inline
In-Reply-To: <7C5E08FC-B362-49B5-A65A-E8F5BD48D5DA@gmail.com> <CAJF-iTRoANDJjdrX5v6GcS4n3nuDFgMZpeof3R-j8F-GNp7w9w@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/lS73qE0b0pec-GS-6trQlRNcPRI>
Subject: Re: [core] [Add] DNR: Mandatory ALPN indication and non-TLS protocols (eg. OSCORE)
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: Tue, 28 Mar 2023 08:24:32 -0000

Hello Dan, Ben,

On Sun, Mar 26, 2023 at 05:35:17PM -0400, Benjamin Schwartz wrote:
> > > This field MUST include at least "alpn" SvcParam (...), *or an SvcParam
> > > that indicates some other security and disambiguation mechanism*.
>
> This seems like a reasonable change to me.

On Sun, Mar 26, 2023 at 02:01:01PM +0100, Dan Wing wrote:
> Sounds reasonable to me. 

Thanks, that will allow us to make more comprehensive use of DNR.

On Sun, Mar 26, 2023 at 02:01:01PM +0100, Dan Wing wrote:
> As you know well, many specs are TLS-specific, too, of course. You’ll
> likely need an over-arching Updates RFC for all of those to IANA
> register OSCORE.

Yes, but many of these are not applicable to the Constrained environment
niche for which OSCORE & co are designed. This one is, because it's sent
in RAs, which are also used in the 6LoWPAN context. I don't plan to
update any of the >800 documents that reference RFC5246 or RFC8446 :-)

BR
Christian