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

Benjamin Schwartz <ietf@bemasc.net> Sun, 26 March 2023 21:35 UTC

Return-Path: <benjamin.m.schwartz@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 1C38DC14CE45; Sun, 26 Mar 2023 14:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.552
X-Spam-Level:
X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.096, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 Blwj6AE-QzqE; Sun, 26 Mar 2023 14:35:32 -0700 (PDT)
Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (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 8E834C14CF0C; Sun, 26 Mar 2023 14:35:32 -0700 (PDT)
Received: by mail-ed1-f41.google.com with SMTP id b20so28351270edd.1; Sun, 26 Mar 2023 14:35:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679866531; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CDtoAOJOBJaEHehQe9KY4YDP8JRbOXhCf4/kdbrOtcY=; b=YSzBH36eXJtLbDspKK1rPSSU3l5uHRkShRdkTwa2heGKYHHnHPmXv2SwhFfisZZr7t Oe/wLKbdaMd2PdoSHmlGIY1wH2orWKfI3+nZ81Aj/TP234DO2kygRZpxtNP0IcHkonrN FxrpzlCBjSAb32C+gpAx1ZlpwzCwn5EF6vf3M3hj5nT4fXPmFYqT3H00sOQAa2Xtnw8x 3lLAk9gBs7rUuxZqenMS45EvfIkH2lA2GeO6KqxoOAq1/MuDp0V6h+zfdXcT3s/Q2YYF imdNzdfl6cxNyF1FQpNKIbaN31rOK1DBQvX8txfZ82fZ3t3B00Lc+CseFS/JKxW4+csx +qLQ==
X-Gm-Message-State: AAQBX9cVXct/PyUm0kpotZs5M22QNSyiWBl8r9skaZD/O1Nq7+EmqrxM fVJM5gX9t+MFoZ/DpYcjqOf2TB6JYRIB2Q==
X-Google-Smtp-Source: AKy350bSNxpvDt4snuZ2nS7Jqq43ux/ZKs2oaseGl4J9KHpUcb3pQ619fF9s2KrApDNt3Y6v+yfkoA==
X-Received: by 2002:a17:906:94cc:b0:930:b130:b7b with SMTP id d12-20020a17090694cc00b00930b1300b7bmr10540552ejy.6.1679866530428; Sun, 26 Mar 2023 14:35:30 -0700 (PDT)
Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com. [209.85.128.54]) by smtp.gmail.com with ESMTPSA id r12-20020a50c00c000000b00501d2f10d19sm9499592edb.20.2023.03.26.14.35.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Mar 2023 14:35:30 -0700 (PDT)
Received: by mail-wm1-f54.google.com with SMTP id i5-20020a05600c354500b003edd24054e0so6163743wmq.4; Sun, 26 Mar 2023 14:35:29 -0700 (PDT)
X-Received: by 2002:a05:600c:21c1:b0:3eb:3104:efef with SMTP id x1-20020a05600c21c100b003eb3104efefmr7776421wmj.31.1679866529438; Sun, 26 Mar 2023 14:35:29 -0700 (PDT)
MIME-Version: 1.0
References: <ZCAX7fsvkxJsr8+K@hephaistos.amsuess.com>
In-Reply-To: <ZCAX7fsvkxJsr8+K@hephaistos.amsuess.com>
From: Benjamin Schwartz <ietf@bemasc.net>
Date: Sun, 26 Mar 2023 17:35:17 -0400
X-Gmail-Original-Message-ID: <CAJF-iTRoANDJjdrX5v6GcS4n3nuDFgMZpeof3R-j8F-GNp7w9w@mail.gmail.com>
Message-ID: <CAJF-iTRoANDJjdrX5v6GcS4n3nuDFgMZpeof3R-j8F-GNp7w9w@mail.gmail.com>
To: Christian Amsüss <christian@amsuess.com>
Cc: draft-ietf-add-dnr@ietf.org, draft-ietf-core-dns-over-coap@ietf.org, add@ietf.org, core@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c1e52005f7d46765"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Rm6GY0BSsySoBAL3R_qPe2RzjTI>
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: Sun, 26 Mar 2023 21:35:35 -0000

On Sun, Mar 26, 2023 at 6:01 AM Christian Amsüss <christian@amsuess.com>
wrote:
...

> (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*.
>

This seems like a reasonable change to me.

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.
>

I don't think we need this.  Instead, we can simply say that SVCB-DNS has
no default protocol, so a SVCB record without any recognized SvcParam
indicating the protocol is not "compatible" and MUST be ignored.

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 don't think there has been much design work to figure out how SVCB should
support non-TLS protocols, but a separate SvcParam similar to "alpn" for
each non-TLS security layer seems like a reasonable possibility.