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

Brian Dickson <> Tue, 18 May 2021 22:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D16523A1139 for <>; Tue, 18 May 2021 15:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EQjC6CvtGY3K for <>; Tue, 18 May 2021 15:06:46 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E4BB63A1142 for <>; Tue, 18 May 2021 15:06:45 -0700 (PDT)
Received: by with SMTP id q7so14731467lfr.6 for <>; Tue, 18 May 2021 15:06:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yF5N7Xhi9LeAFKpH2BEBpQQhxNAQULSTfAY+7wvE8TA=; b=YsIYNH6KnTiu84C5V+EjbykTFPsaMs9/Br4rizdZxI8Jtnqjb9+NTz6HigkynujS0N 0EvLxUPpWBnTacqYdOvr8yE7KlTtc3UWKjOYfT1ibk1c1IGhSW/lLvUQtvDAKX+fjTdR Yq/56z5LO4I99ULbYZ7/8ST8yf1Ak4oVuXjxexR4l/vak2BP+nOYjz5gZAA53Y+QLQZJ D/jTjLYTZ7bfHFafySGxYy9NL8ZH6I1ixo/Ob9f3BDHTfKiLvxXbaAMk1b/hSD0oNV1O VOAYJwFX7OX2Jo7E+CWRyxPf2REmxZD5BHwnfLFTojeVyKxXktaTFfWyvy6J+Ue9wgPs rZ/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yF5N7Xhi9LeAFKpH2BEBpQQhxNAQULSTfAY+7wvE8TA=; b=PBs6p1+BgXWzLw/oA/pnp+WkMv7rMvaX00SR5kynDisaK3sH9O89qozPbKuWm7nFb3 9mUsjNZbtcuhkLBtnsSV/YL6rviZpudAurdTkIZJgtSi99raiep5a4sFYaZHbhTdONye d9NcdHaRMNBf8gqRv3BnmzDHu+6Ccnjp8ifTpvHnZ/SYbvoTZsoCHFCuOjLTnLf30sM3 ZHCsp7qE38GFprQDHhoSXaQTHwHlEbYiviQrDimFqyTkJ+CgJ3VqNcLcCGXaj7wMZAX3 IZOUKMtSfExGu4MZMNdw+xJ8FvYCIx1QRXjDQPkPiYtOcFZwMRO6l7umwV7KpBYnY0JS rXwg==
X-Gm-Message-State: AOAM532BvnwHR/HFzWpPOng/4OqJNefWW3YpJvk2UJNsbO25j8yoK0i1 PRKk/iVX21R93mFMaDg8BOrjFjukdjedrg13sRA=
X-Google-Smtp-Source: ABdhPJxxmNBLPj6Ge7Xwp+Oot6QFpFDlJRLQD73qR2bC1MG5Qcm4izQUUDsNpG92Ui8CrEI1gGjUWD3lMItxjMJp1jQ=
X-Received: by 2002:a05:6512:118c:: with SMTP id g12mr5631825lfr.316.1621375598837; Tue, 18 May 2021 15:06:38 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Tue, 18 May 2021 15:06:27 -0700
Message-ID: <>
To: Paul Wouters <>
Cc: Ben Schwartz <>, dnsop <>
Content-Type: multipart/alternative; boundary="0000000000009dc77b05c2a1ec13"
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 22:06:48 -0000

On Tue, May 18, 2021 at 2:35 PM Paul Wouters <> wrote:

> 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..."
> or:
>         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)
> harder.
> > 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
> matter.
I should have given the numbers as well as percentages.
The original encoding for the response, including EDNS, was 191 bytes.
The new encoding (continuing to use 16-bit values for SvcPriority, all the
subtype values, and lengths, was 268 bytes.
Trimming the SvcPriority and subtype sizes to 8 bits (for comparison
purposes), but leaving lengths at 16 bits, the original encoding became 185
Trimming SvcPriority, subtype, and length on the new encoding (because
there won't be any single fields >250 bytes, assuming ALPN isn't insane),
becomes 249 bytes.

So, the differences are either 77 bytes, or 66 bytes. For a host with a
1Gbps link (not uncommon), this is about 0.5 microseconds of extra
serialization delay, or 1/2000th of a millisecond.
Editing zone files and checking their accuracy/consistency is more trivial
if the parsing is simpler and completely unambiguous. Most errors relate to
syntax, not semantics.
Providing a simple UI-like tool to either provide an input mechanism (to
allow the user to fill in fields, and produce the DNS records) is pretty
basic stuff, and reporting tools to output the associated elements (the
reverse of the UI tool) is also extremely simple.

Nothing on the wire will ever be a sorted list, modulo sorting of elements
within a record. The client will always have to sort records itself.
Sorting to do grouping is no different and no more complex than it is for
handling the SvcPriority (which it must).

And, in either encoding scheme, no matter how many records there are in the
(unsorted) RRset, the DNSSEC RRSIG will be the same size: one record per
All the records combined are less than 256B, so there is no difference in
efficiency for SHA256 (which requires padding).
So, basically, all of the differences are for practical purposes below the
noise floor.

The benefits should be considered on the merits proposed, not any issues
with the resulting wire format. IMNSHO.