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

Benjamin Schwartz <> Sun, 26 March 2023 21:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C38DC14CE45; Sun, 26 Mar 2023 14:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.552
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Blwj6AE-QzqE; Sun, 26 Mar 2023 14:35:32 -0700 (PDT)
Received: from ( []) (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 (Postfix) with ESMTPS id 8E834C14CF0C; Sun, 26 Mar 2023 14:35:32 -0700 (PDT)
Received: by 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;; 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 ( []) by with ESMTPSA id r12-20020a50c00c000000b00501d2f10d19sm9499592edb.20.2023. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Mar 2023 14:35:30 -0700 (PDT)
Received: by 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: <>
In-Reply-To: <>
From: Benjamin Schwartz <>
Date: Sun, 26 Mar 2023 17:35:17 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Christian Amsüss <>
Content-Type: multipart/alternative; boundary="000000000000c1e52005f7d46765"
Archived-At: <>
Subject: Re: [core] [Add] DNR: Mandatory ALPN indication and non-TLS protocols (eg. OSCORE)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <>

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