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

Dan Wing <danwing@gmail.com> Sun, 26 March 2023 23:39 UTC

Return-Path: <danwing@gmail.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 C4ABDC151548; Sun, 26 Mar 2023 16:39:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.551
X-Spam-Level:
X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Uvbp6JqmqdAQ; Sun, 26 Mar 2023 16:39:30 -0700 (PDT)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 0860FC14CF0C; Sun, 26 Mar 2023 16:39:30 -0700 (PDT)
Received: by mail-pl1-x633.google.com with SMTP id le6so6772374plb.12; Sun, 26 Mar 2023 16:39:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679873969; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=5Gl3PW9P2iJMcZh1+40Ld/CEqWVz2yG66I32Pu3/Buo=; b=IHanmbuLA8oV3Ib8kdmxgH2GAxk4Lraxy/OW82Fc9mKIgsUfz+rCawV+OF5ldixhqS 9gPNHZ+q3IClT7Kqtv8VX/0fKxxIuOD7aoRYaoiZJCvlagKFNvCZnjIx8oNo83cvj/oR CpvsXN276cleLGP72d222u1FlE2nq6AiRXldKioX4K7TkXTy+EHtvJ87GVoDIndhND4W Gbr/hXWK+UwcOG+njqt09IsBxpQDLtqvvsgE4N72aKSANrGkWVF+0R41pMWehYHVwaE0 l+H5TTHfkzcltSlPjUtyJ2i1KuFrMuTW9/reXaprgaFumIFTnk1w7Uxc004MN5KB84r7 F6lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679873969; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5Gl3PW9P2iJMcZh1+40Ld/CEqWVz2yG66I32Pu3/Buo=; b=N3r28Bcs6SYtjYqnYRm6iN8UfPh+nKP9QrTtEPokOf6wpbl5JCxw98IKq9UjbaQKiR E+DIpTx4XrIVaOf9V1dbv6nPi1YUUYNLbKk8sojvaMxIE825ggp3YSF57nt7sl3b+kyw N19d9tzRk+dWN5b1dcTu0SRkjPEeBwMOgEC5rQC2lqA/QCdVhHZFzvfmsM+Db7LlWOpB N7tVjR0weEZeYJQnjs1p8rqpQkMJsMS36kePu+TOSMuAQsPVZVrV6Y/8ky3i1JuuuUei 5NPXIWQTbuHHP29fSSqgtQDQdUhuYBihq8HLrXRtXoRBiZhp64AwcA1Mtd9Ldv0vZTsE Qe2g==
X-Gm-Message-State: AAQBX9dEgDU0fX/hX2XiL/hV96mVovKQ/6TH3xIGaBHO9OqJZfMM2A83 1G9a1N3eymx0qOLD2JGypnpjTZxHc4I=
X-Google-Smtp-Source: AKy350ZmfqsB3uAHwNclnPcLNOSdoKsd9s4WD+LHH554OEffRAAdib+5wtt9ooLr4jc9OwW+UP1Btg==
X-Received: by 2002:a17:902:d48a:b0:19f:3617:e9e9 with SMTP id c10-20020a170902d48a00b0019f3617e9e9mr13787371plg.43.1679873968968; Sun, 26 Mar 2023 16:39:28 -0700 (PDT)
Received: from smtpclient.apple ([2600:1010:b0e7:c284:f98c:a88d:6278:24fe]) by smtp.gmail.com with ESMTPSA id 2-20020a170902c20200b00186a2274382sm17817840pll.76.2023.03.26.16.39.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Mar 2023 16:39:28 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Dan Wing <danwing@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 26 Mar 2023 14:01:01 +0100
Message-Id: <7C5E08FC-B362-49B5-A65A-E8F5BD48D5DA@gmail.com>
References: <ZCAX7fsvkxJsr8+K@hephaistos.amsuess.com>
Cc: draft-ietf-add-dnr@ietf.org, draft-ietf-core-dns-over-coap@ietf.org, add@ietf.org, core@ietf.org
In-Reply-To: <ZCAX7fsvkxJsr8+K@hephaistos.amsuess.com>
To: Christian Amsüss <christian@amsuess.com>
X-Mailer: iPhone Mail (20D67)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/kGrwJGNqjdkky2z170ErmzQJgno>
Subject: Re: [core] 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: Sun, 26 Mar 2023 23:39:33 -0000

Sounds reasonable to me. 

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.

-d

> On Mar 26, 2023, at 11:11 AM, Christian Amsüss <christian@amsuess.com> wrote:
> 
> 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