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

Dick Franks <> Mon, 10 May 2021 11:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BA8D3A1855 for <>; Mon, 10 May 2021 04:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hy7HmTS8Z2BX for <>; Mon, 10 May 2021 04:02:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 876BD3A1852 for <>; Mon, 10 May 2021 04:02:50 -0700 (PDT)
Received: by with SMTP id i7so6866911ioa.12 for <>; Mon, 10 May 2021 04:02:50 -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:content-transfer-encoding; bh=CW0eAqqupM2QQNx19loFqlHXycFWMH7W6bY2td2bmxo=; b=Xk/MxA5Mfl1DujqMZii+Nez9ths1bQof/DflKkguaY9oX/sXbmgZJv50TNjW5MOTPz 5vA5i4DyC5cW2d7JisXuD6EHmCdF1L6ihDi6lFfdwWTdpem/W7bZs39Ye1fYta5E0a7g /aq7skq6gPOAjMTfCGjdS2n7m/z0qDaUfHOMSaHSZw3UL7d0FzxW8gipdSOBCKhKAl5r vYtUR20UFNKi/dfscmCAoW/5hQYMKF+IUh+USWo6uFyfnZDm9qIdebqwJTBcv2NZvbEk oQSyZxqFAhvx/nCveAGW5iRiLVjwTQXDocwpqKZL9sDHsYhQ4WEuzTRwV8MohFa78j8x 9AGg==
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:content-transfer-encoding; bh=CW0eAqqupM2QQNx19loFqlHXycFWMH7W6bY2td2bmxo=; b=UkBWJtII9ZKrN45KZ+YL1+E2+u6awF9IHneUASx3LlWmmIAy5TRM/0IUiBWF2ae4FK RV5hYrovgf3XYL9iqdmXzzI37I0jiqPD6ufrmqD3WBJ9OSHkBrqq2fo4Dv8IOJ861Ubm GuUnvwzN2jHE3O8AeUGDMp2cQbSDB4Ck/sUsKafyb8/1RmdPZ91Lq7CJEkH7T+kmxTPm vMlnkU9CC/S8SAz3/1Ffs9zSScZPGGVkid0go4vfKPNalfy34BhhkWV1Hn9ehqf8eFS0 KvkHtPpOUDgv410Ki4q5uDDulfpA+Q9RAUTjdKTs5Tl9oxU32lA8hQnySAtdBd3mP7+9 pKyA==
X-Gm-Message-State: AOAM531GkM9eCjrh6rPeqeh9AdIZciUcHY7E6aLFkoBW+Ey+8XEJJa3M yHBC2IiLbCUeu160HSyWyBC5eGnIDj7X0i1NGLk=
X-Google-Smtp-Source: ABdhPJwxHu1L4W0gQh5h2PZ0tLqlpJ2+ok+ryEkNJzEtt3LvRJxjBhKFLwLH9U4C0ah50/zVccoA8Vm6JTIa59k1fgE=
X-Received: by 2002:a05:6638:3fc:: with SMTP id s28mr21286388jaq.117.1620644569116; Mon, 10 May 2021 04:02:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Dick Franks <>
Date: Mon, 10 May 2021 12:02:12 +0100
Message-ID: <>
To: Paul Hoffman <>, Ben Schwartz <>
Cc: dnsop <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Mon, 10 May 2021 11:02:55 -0000

On Mon, 10 May 2021 at 00:28, Paul Hoffman <> wrote:
> On May 9, 2021, at 11:26 AM, Paul Wouters <> wrote:
> > This is all pretty terrible. I agree with Tim that we should not inflict this onto the users. Or perhaps we can already pre-allocate some CVE numbers for the security issues this will generate.
> >
> > Keep the record simple, we are not going for Turing complete here. I recommend to authors take this discussion as advise to improve / simplify this aspect of the draft.
> I don't think this request is actually doable. The requirements for the SVCB Rdata are:
> 1. Must be entered by the zone operator as ASCII text (not all a jumble of hex values)
> 2. Is a list of key/value pairs
> 3. Values are likely to be a list of items

It is very much doable.
BIND, NSD, and PowerDNS can already parse values containing '\,'
escapes, and each of these has a substantial installed base.

My objections can be entirely satisfied by modest changes to reconcile
the document with RFC1035.

> Given these three things, it seems that there will *always* be an escaping problem for the item delimiter in #3. In the current draft, the item delimiter is a comma, so there has to be a way to escape a comma that is in an item. Few types of items would ever need a comma in their values. If a different character is chosen for the item delimiter, it too will need to be escaped.
> If I'm wrong about this being as good as it can be, there must be an item delimiter that is better than a comma. I am not thinking creatively enough to figure out what might be better than a comma. I'd be happy to hear proposals for a better item delimiter.

My objection is narrowly focussed on the escape mechanism, nothing
more.  Changing the delimiter is neither necessary nor relevant.

I am happy to contribute the necessary words.