Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Paul Wouters <> Tue, 18 May 2021 21:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FF763A0FF0 for <>; Tue, 18 May 2021 14:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FJKQR58FbpTR for <>; Tue, 18 May 2021 14:35:46 -0700 (PDT)
Received: from ( [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 608613A0FDD for <>; Tue, 18 May 2021 14:35:46 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4Fl8SH52KkzKML; Tue, 18 May 2021 23:35:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1621373743; bh=MeozaclTHWdcruwMOgsp8cFpJNBs0CLrrDzCf46KJVs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UKvnc8qhdf0Wv7PVEFzRja+BJQUWZEq7SY7x0o1EdyehMcgzu30SMDGwNZc+Ig9Ib +SwVul99nL2VDC+KefgtKuPL2xvam8ydWsDYA7i9uActYTmQYcjblecZclpBHp34P6 PX4Luc5wyqyP7rOBD9/U4UtHX8zJArWs5e0jnWZA=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id S6pL8wB0XFc9; Tue, 18 May 2021 23:35:42 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Tue, 18 May 2021 23:35:42 +0200 (CEST)
Received: by (Postfix, from userid 1000) id C82C75AF1F; Tue, 18 May 2021 17:35:40 -0400 (EDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEB975AF1E; Tue, 18 May 2021 17:35:40 -0400 (EDT)
Date: Tue, 18 May 2021 17:35:39 -0400 (EDT)
From: Paul Wouters <>
To: Ben Schwartz <>
cc: Brian Dickson <>, dnsop <>
In-Reply-To: <>
Message-ID: <>
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 May 2021 21:36:03 -0000

On Tue, 18 May 2021, Ben Schwartz wrote:

> That's essentially correct.  A client that only supports the default ALPN has no use for the "alpn" SvcParam.

Does the "default ALPN" mean "no support for the ALPN extension" ? Or
does it mean "Supports ALPN with the default XXXX" ? If so, what is

> My point is that SVCB mappings are IETF documents, complete with guidance, normative language, deviations, exceptions,
> etc.  The summary table in Appendix B is non-normative, and not connected to IANA in any way.  There is no registry of
> mappings.

This really looks like you are creating an IANA registry for keywords
used within SVCB records.

> Here is the same pair of records, using the two different encoding schemes:
> ;; pool HTTPS 1 h3pool alpn=h2,h3 ech="123..."

Why wouldn't this use:

 	pool HTTPS 1 h3pool alpn="h2,h3" ech="123..."


 	pool HTTPS 1 h3pool alpn="h2,h3", ech="123..."

It is a little strange to me that some values are within quotes are
others are not. That really makes parsing (the presentation format)

> It also creates significant complexity for any future value that takes the form of an ordered list.

Security protocols are usually in the form of the initiator represents a
list (in whatever order) and the responder decides which it picks and
prefers from that set and uses that. Putting ordered lists in seems like
something the client in this case would mostly ignore as they will just
pretend not to support that is ordered at a higher preference in a list
in the DNS record?

But I did indicate already before that this RRtype is basically a
"security TXT" free flow record and it will surely lead to issues, yet
it seems unstoppable at this point anyway because of the milliseconds
for the advertisement auction gods.

> I did a quick test implementation, and the wire overhead was not a substantial increase, about 40%. 
> This seems like a considerable increase for a high-traffic record type.

Well, you basically build a security protocol demultiplexer server HELLO
record that's not protected by a Finished message, whose protection
comes from DNSSEC but the people who want to run this at scale don't
want to do DNSSEC. As long as the message size is well within common
EDNS UDP packet size (with RRSIGs), then I think the size does not