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

Eric Orth <ericorth@google.com> Thu, 13 May 2021 15:29 UTC

Return-Path: <ericorth@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 A91FF3A105E for <dnsop@ietfa.amsl.com>; Thu, 13 May 2021 08:29:23 -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, 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 QPFai5hDD5ot for <dnsop@ietfa.amsl.com>; Thu, 13 May 2021 08:29:21 -0700 (PDT)
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 550DB3A105C for <dnsop@ietf.org>; Thu, 13 May 2021 08:29:21 -0700 (PDT)
Received: by mail-yb1-xb35.google.com with SMTP id i4so35226475ybe.2 for <dnsop@ietf.org>; Thu, 13 May 2021 08:29:21 -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=+Ll9hCW4vzXCsEYD3gVUYMtnR1heUngGq7cc+kPF3Aw=; b=Go/83T5Xggxz9fIddtbg8KA2J/fRFcftNy3Un2FJF3x24nLo3DAtnKf1Yn0m+eGBgy ghz1QZ19G0+DSQ5nt/u2O72knMVjOc/cZabOW/XoKpmkoptBdH0U4ewnVQg6x32qHKf+ yhhJgvedyPPLX+mFMBHwJO+XL3cQ/m7EBA4YGKB6HOwg/Fa2AU1KL/deLWNit4Ptd3sd HuLMBzlj8IgS39GTktn+wDvw2aX2+KSN0pKA1s7onxfwaxvr9dH+YPpYOUJo50er8END zF+qIncle0U3MP8jQ7+ui5l9I9KZ+vlpCVEw5NxwVDzh2lAxMQqNXm3EhIkJGYzX/TKd 4D4w==
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=+Ll9hCW4vzXCsEYD3gVUYMtnR1heUngGq7cc+kPF3Aw=; b=P7b12z/llRYh5s7a7+Eks5M2e29Ifxbdsmir53DnM167hqOFRNFpZEVnONvrE6w4bj hCfm2Na+BpPGjDS8q9juj5JP3NcOWzs+kBGpCgrRzD/U1nm6p8/U9tir6mI8TJj70asF Wbsf1gaLronzBaoT7AtkLjbOraWeVEpiT++xm5ZwS9q0TGrTVd04kIXVTe8BSyRDfM8B JIgcybD1QTwX7Aqoexpgulqz/4igTKdq4MAk9fxigjj+txB3c0OLgGYm1NMBaacbTsU4 K3g41bmf1y88OiP5QgkCgq9TqPIoIeGl/bvn43X+nTBL2i19ACmvMhbJFD5d82ajP88u POuA==
X-Gm-Message-State: AOAM530GJ1AQ4qw0eOsbE3dROnTHA9QUfftvCmEHB7rYyRDzHRrPXJa3 SZ/nWytLBHs+JUva6KCMWFCXmSBcRtEI6TPt1ty51w==
X-Google-Smtp-Source: ABdhPJwirtvLpiLKsKXLxKqEhX/m/trJyN/Y4xJsnyl2fIYNhRxWZ0pcir6jEYEVDm6RbdsDO+Zxtziy3xrBtWBO+K4=
X-Received: by 2002:a25:9745:: with SMTP id h5mr31610917ybo.36.1620919759653; Thu, 13 May 2021 08:29:19 -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: Eric Orth <ericorth@google.com>
Date: Thu, 13 May 2021 11:29:07 -0400
Message-ID: <CAMOjQcG+DSa8ibWRsu6YJKTAJFahg_PnszmL81Oz97hkcN8oFA@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: Ben Schwartz <bemasc@google.com>, dnsop <dnsop@ietf.org>, John Levine <johnl@taugh.com>, Joe Abley <jabley@hopcount.ca>
Content-Type: multipart/alternative; boundary="0000000000007c39de05c237ca4d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hT0FoulNdVycABwpZCzkeUyEeOs>
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 15:29:24 -0000

On Thu, May 13, 2021 at 3: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.
> 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.
>
> 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.
>
> But, the _wire format_ of the original proposed record is not at issue,
> and never has been, so I don't understand why you bring that up.
>

A lot of the recent debate here has delved into the fundamental structuring
of how SVCB info is divided into records.  That very much affects both
presentation and wire format.

I really prefer the current wire format over most of the suggestions in
this thread, but I don't really have any strong opinions regarding
presentation format.  Making presentation format split things into multiple
"records" but stitching it up into a single wire record isn't a reasonable
option, right?


>
>
>> 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].
>>
>
> That is actually an interesting point, for one very important reason: NONE
> of the OPT RR elements are zone file constructs. They are all metadata,
> typically established by the configurations of various implementations of
> DNS clients and servers (including authority servers and resolvers).
>

> So, you are actually making the point for me, that the wire format of
> something that isn't a zone file component, can be complex and trivial to
> parse. We agree on this completely. The TLV aspect is well understood, and
> a component of many protocols (e.g. BGP, another protocol I'm actively
> involved in via the IDR WG).
>
> Having complex records in zone files is unwise, if it is not strictly
> required.
>
> The question was raised, as to whether that format is strictly required,
> and I think the consensus is that it is not.
>
>
>>
>> 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, is actually
> enforced directly via the 4-tuple uniquess criteria for DNS: owner, class,
> type, RDATA. If the RDATA consists of priority, enum, key, value pair, DNS
> enforces the uniqueness automatically.
> (This technically makes the semantic component of what would otherwise be
> a complex parser moot, and the syntactic part, the easy part, is all that
> needs to be implemented.)
> 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.
>
> 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).
> This is the absolute simplest thing to code, and the absolute furthest
> thing from "novel". Its use as an encoding in DNS might be new, but it is
> the kind of thing that unit tests can handle trivially.
>
> So, to be clear, I'm only explaining the what and how, and maybe some
> parts of the why. I'm not in particular advocating strongly for using it,
> only presenting it as a viable option, for other folks to discuss the
> merits of.
>
>
>>
>> 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.
>>
>
> Implementable isn't the same as maintainable or simple to debug, or to
> confirm interoperability. This is particularly a concern across situations
> of zone file export, copy, and subsequent import on all of the other
> implementations. You may be underestimating the number of implementations.
> Switching to a zone file format that is simpler to parse would go a long
> way to improving those.
>
> Brian
>