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

Ben Schwartz <bemasc@google.com> Thu, 13 May 2021 17:25 UTC

Return-Path: <bemasc@google.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6B73A164F for <dnsop@ietfa.amsl.com>; Thu, 13 May 2021 10:25:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Level:
X-Spam-Status: No, score=-17.6 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbfQjKrJmNCr for <dnsop@ietfa.amsl.com>; Thu, 13 May 2021 10:25:26 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 521AA3A1681 for <dnsop@ietf.org>; Thu, 13 May 2021 10:25:26 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id b19-20020a05600c06d3b029014258a636e8so223737wmn.2 for <dnsop@ietf.org>; Thu, 13 May 2021 10:25:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AidsVoSqO4320ei/yU1HGcZ8U1wvpINDXUeTjA4xvBs=; b=v/ww73qdgt+q9jfU/28CVT40fOiid0BeTv9ITzFEm18nzk6CUfu0NB2yWXrFOEveGR +0rtcsJHpUIZ87HeYvB0sl40XWliWFlIg0gjynOcwXOP0922e8cqniBuWD6dgNbEJqJE 5YDlOXu3FNHfWL3irQTTDccJ90b+WguWqWIy0y+MIqjw3ktqNRP64p3eF9aeb081TE3K rzX3WUNxzi6M2Nt3v6Ti5QPTE0WrD6mGvIHPrVsjmiZkDEKVrilIKOOVRDd+viwGB9jy 7V7Bx1uRToHQ4XfVYLQo4eHtnsCEVdhhPcGmMOqNnpaL4gjSsKc/6KmjgFNghsEgcu4N ZTlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AidsVoSqO4320ei/yU1HGcZ8U1wvpINDXUeTjA4xvBs=; b=MzyTopdZCKMM/bmOtr1Bl5aJAtm1KfNR20m1NJuxbqq1S6MCfZsvmVB+GWnlx3ltA4 q5rCam8ejWQ0/nBztDN0VViR97WgyDqQZTWaEShnc6Vy9Q9dMJUf83NgZKjcd2iP0CfR oobc8KhakhPC0T75FR9EJDOJ+YKa4WMvu3JXhng5qZ9R85aY9/uBJA/Vo6ePK3bvP8Cy 6J/Fl5MUtsKqNlEWc4Dhu+afcZUQMHfzKLGxup9Os3nXQ4ag+CRIyNB/HmgwEGMKl0II 80PvctjGJZD8StwIUQPFfidZrqcNIhDu8Gc0aXXfcbqa6jHQ3l/RvUsA/us1oyEO4PSJ 4ytQ==
X-Gm-Message-State: AOAM532X7YHPIWqCMynS7R5VFia+Cgp843FtMpXf2qGIIW2/eiTNO26b kR05Q/MJQPFFcMasmSEemMtxFP3GHb9+QxBJZboex1bZTxVzxA==
X-Google-Smtp-Source: ABdhPJwlj+9E2jX0ooLHxfCydMbRdefILLqfQY1DxMQKe7/qD0ldfXsCoQ5Mxl76nWaCEOLRjBWhK4aaaDdcJSSctrE=
X-Received: by 2002:a7b:c5d2:: with SMTP id n18mr4870511wmk.97.1620926723647; Thu, 13 May 2021 10:25:23 -0700 (PDT)
MIME-Version: 1.0
References: <7ADF1FB2-97A4-4C49-8F25-8BF03BE01640@hopcount.ca> <20210512213903.D5F1F7AA827@ary.qy> <CAMOjQcFJjcsvaREF0fr+2GTY4zTy5CxSxR16BEp=Nc-K9WJ0Tg@mail.gmail.com> <CAH1iCipAVKVCuH2ME=+YpeJyijrKCtzJaU3bRFyy1f48EB33iw@mail.gmail.com> <CAHbrMsCjWgV7nc575L_qdvr7HdoEVKqkXRwLdXA2L5NiCgdvwA@mail.gmail.com> <CAH1iCipW_-BSMQZ-S+m18pyzfxTGsCrmG9Pc-b35_VRiLhxh4w@mail.gmail.com>
In-Reply-To: <CAH1iCipW_-BSMQZ-S+m18pyzfxTGsCrmG9Pc-b35_VRiLhxh4w@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Thu, 13 May 2021 10:25:11 -0700
Message-ID: <CAHbrMsDvEkYAxee4xjW5LsQmr0PgBf+UmMAuME-_UvRMg4jJeA@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: Eric Orth <ericorth=40google.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>, John Levine <johnl@taugh.com>, Joe Abley <jabley@hopcount.ca>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000097bdcb05c2396951"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/q01T3O2l7pxjJQDyzIiRd-y0oWk>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2021 17:25:29 -0000

On Thu, May 13, 2021 at 12:51 AM Brian Dickson <
brian.peter.dickson@gmail.com> wrote:

>
>
> On Wed, May 12, 2021 at 9:33 PM Ben Schwartz <bemasc@google.com> wrote:
>
>> On Wed, May 12, 2021 at 7:14 PM Brian Dickson <
>> brian.peter.dickson@gmail.com> wrote:
>>
>>> 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.
>>
>
> This is an apples/oranges argument, the parsing complexity I'm referring
> to (I thought explicitly, but I guess that is too far up-thread) is the
> presentation (aka zone file) format.
>

Ah, so you were comparing the difficulty of a complex parser (at the
authority) to combining data from RRs (on the client).

The initial opinions (not just mine) were that the format, while maybe
> familiar to HTTP implementers, is very un-DNS-like, and the proposition was
> that the complexity was not strictly necessary.
>

SVCB's key=value zone-file format is borrowed straight from DNS-SD (RFC
6763); it is not new to DNS users.

While combining multiple simple records into a complex record, in wire
> format, would not be difficult, it is not what DNS authority servers do,
> and is not what resolvers do.
>

It is not, at present, what any components do, and the current draft is
designed to keep it that way.


> 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.
>>
>
> It is a simple table join using a single key. It was unabashedly ripped
> off from the RDBMS field of programming. Or actually COBOL, from the early
> 1980's. It's a hack, slightly clever maybe, but extremely simple and
> reliable.
> The requirement that each SvcParameter occur only once,
>

This is not the current draft's requirement.  The requirement is that each
key appear only once, to avoid conflicting values.

This also vastly simplifies the encoding/decoding of unknown RDATA, since
> the priority, enum, and key are numeric values of fixed size, leaving a
> single "value" component.
>

I don't see any simplification.  The length of each value is explicit in
the TLV, so unknown keys are equally straightforward to handle.


> The enumerator is the key (for the table join). The client does not need
> to check parameter uniqueness. It only needs to match up the enums to
> recreate the JSON of the objects in the array of structures (or regroup
> them into the OPT RR wire format if you prefer).
>

The SVCB draft makes no mention of JSON, but I presume you mean any
application-specific representation of the service binding.  I understand
that it would be possible to reconstruct bindings from labeled records
spread across the RRSet in the way you're describing, but simply encoding
each binding into a record seems much more straightforward.


> This is the absolute simplest thing to code
>

Breaking the binding into pieces creates many new opportunities for error,
such as having multiple TargetNames in a single binding.  It corresponds to
a multimap datastructure instead of a standard map.  Every attribute of
each binding would naturally be an unordered collection, which is a bad fit
for attributes that are required to be singular, or an ordered list, or
anything other than a set.

Switching to a zone file format that is simpler to parse would go a long
> way to improving those.
>

Separating the binding into separate records transfers complexity from zone
file implementors to zone file authors, who must express a simple key=value
map by writing multiple records using explicit binding indexes.  For a
human reading a zone file, it is particularly difficult: a single binding
could be broken up into records separated across the zone file, with
surprising consequences if you forget to clean one up, typo a binding
index, or accidentally create an index collision between two bindings.

I continue to prefer the draft's current format.  It hews closer to DNS
tradition (wire format from OPT, zone file format from DNS-SD).  It avoids
the novel paradigm of cross-RR reconstruction.  It is not speculative,
having now been validated by at least a dozen full-production
implementations.  It is more efficient on the wire.

Considering alternative formats is an intriguing exercise, but I do not
think it is likely to result in improvements to SVCB.

>