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

Ben Schwartz <> Thu, 13 May 2021 04:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CF423A2515 for <>; Wed, 12 May 2021 21:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 1aKgjph0y5IA for <>; Wed, 12 May 2021 21:33:19 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFF4F3A2512 for <>; Wed, 12 May 2021 21:33:18 -0700 (PDT)
Received: by with SMTP id n17-20020a7bc5d10000b0290169edfadac9so742943wmk.1 for <>; Wed, 12 May 2021 21:33:18 -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=57e53sxJTcQJx3CvYsvQGz65Y3tIpMIF3MWdz+DYI+Y=; b=pPAY+SrhPj6uygAks+nqYIm3w9tJDFn+9f0UFtApTUR8B42Yokgua353LQWYQtDw20 uY7nadu5dRpTSf9Hku9BYgQI7N/w0KvRvSCHXb3S1SWqnYrxVtJZTncrkt06xHHPUtT6 DYHlER/QgNOTtfzl2Y9ZQkFjVsEJx5g+ZnYLMK//JVIGA29+jypJqDuf/j+ICUxGTSub xT2DcM4FlIEexoWJ12oeszJnXZE7XVod5rOeV1LeeN3s0KlgwGdL/mFKCLbrQRjPGZNx T8f1BJTEd+Vo/Bkau+bzhoaqwTvF/yuYfjkgiiWpH1xdwYkB7ST0MxCTFjmzaajLMXn5 kpiA==
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=57e53sxJTcQJx3CvYsvQGz65Y3tIpMIF3MWdz+DYI+Y=; b=QNGG4s1OLGub5lcC2ZpjepSQLNC3Y1SB0tJxrk5Ektzwot9ncP9yXpp5iUK3bKrF/F 6ZdAZnnGLvoAqSHB0PDUYF9DTnnLH9jIKP1y3BdW3BYddIMJd0WV6dRoNplpuqDeDzSs mG8wgZGGqrEwW+P+zDY7eSZwyby0x2do4h5KmJDng7yVdHr7jafAMCpJk6e18xnPcMK+ qv/K7OflZdzWAFteZf774oLSc/7HkY0SWeEayhp22bGfC95EuNBwG/iH/VMoZxe19U0l b5HQfnHQ78T29xOlB5a4Gp0OX6fRw4P7AYRspu2TnuSfuihJrFzBi6wF+vAnmaBofBkH SiwA==
X-Gm-Message-State: AOAM5336KgYH1Koqe087beW1QSLsxt/CNz9zRYAtxPY/JJpb2YoB8xkz 1xI11eqYoNhwmbMzNSR0ZEiZaHrOz5LPWbk4nPySzw==
X-Google-Smtp-Source: ABdhPJw+iP+jVyxjND2GeB4LEBD0CYZT9WW/VFEimKyYXXu4Cp8/EbegJzJeHlCHlt+lNjm/NL2mGLnh1xnwuxRHOaU=
X-Received: by 2002:a1c:4482:: with SMTP id r124mr1732540wma.42.1620880396189; Wed, 12 May 2021 21:33:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Wed, 12 May 2021 21:33:04 -0700
Message-ID: <>
To: Brian Dickson <>
Cc: Eric Orth <>, dnsop <>, John Levine <>, Joe Abley <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000004276ef05c22ea0e2"
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: Thu, 13 May 2021 04:33:23 -0000

On Wed, May 12, 2021 at 7:14 PM Brian Dickson <>

> It is demonstrably more likely that a complex parser will have problems,
> than something that combines data from simple RRs in simple RRsets will
> have problems.
> (The history of SMTP is, I think, a good poster child for this, with MX,
> A, AAAA, plus DNSSEC and TLSA support in the clients, which are email
> transport things, not merely DNS things.)

The SVCB parameters' wire format is an extremely simple TLV arrangement; I
don't think "a complex parser" is required.  It's also far from a novel
design for DNS; in fact, it's identical to the widely implemented OPT RR
RDATA format from 1999 [1][2].

What you're describing here, an arrangement in which clients partition
RRSets into subsets and then reassemble bindings from those subsets,
strikes me as highly novel, in contrast, and somewhat more complex.

Perhaps complexity is subjective.  The important thing is that the standard
be reasonably implementable.  I hope that the list of published
implementations [3] will serve as convincing evidence that the current
draft is sufficient in that regard.