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

Brian Dickson <brian.peter.dickson@gmail.com> Sat, 15 May 2021 19:48 UTC

Return-Path: <brian.peter.dickson@gmail.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 391CC3A19A4 for <dnsop@ietfa.amsl.com>; Sat, 15 May 2021 12:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 koDFY7FlFVEG for <dnsop@ietfa.amsl.com>; Sat, 15 May 2021 12:48:29 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 57D5A3A19A2 for <dnsop@ietf.org>; Sat, 15 May 2021 12:48:29 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id f12so2481910ljp.2 for <dnsop@ietf.org>; Sat, 15 May 2021 12:48:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7kcuS71cjydtUng1bmybcC+2jWllbwXXzvm8RwYE0zA=; b=lfvFkTulxIOP71UMDt9qrm3fXvAICnM7GYHtUaNcIK/oIwxONfbEHvT/jgiSM0EEFJ 6foHH2iosC41mQHfne0f1pvAPp5+BCIiugFBsi2j6J8Mg31chws9ckoSQmWzQz2Jl3a/ rOOihWjwB8swYTYQCj4NU+sd+wPp5roUCzc5Pmpf45Et8JQ21Ic5u3PCafLeRyEFqx53 MlpDx8tBghCz601i+nkW67wjhMucvP4EmBeoG1Phw8w+XnJlTGDtRCylMK3BYIVJTkxI nRkgAqp/vXlx6vwbPH/g2i7kBXZIA3ef0w8Qv+ggnmunDfEcaoastQ2sz6jaG9nG6+IE F9WA==
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=7kcuS71cjydtUng1bmybcC+2jWllbwXXzvm8RwYE0zA=; b=QQubRMP1Z2cKFGJT4QtQNcCLDDsVIMLHoB6ny/B31JD9Ig+alpZufrV1jsu/10SWc5 riVOIa5cgVMAMl42xIU3LgdinF/SgvPc9+k4I/csOfxW4qT9ho/YLC9tSIPCq1d4/V2B CfUN8BTFlbkFCfeB50x+6ewip2jFPknPAqDlNQbVYp8ce/7SqVYuiJOjvGlwm1mFMPEC HLu4g7q77HRe/02fgwFDpxDC6QELHYrLO8HsYG6R8P4w0zC2ULnIpkgIzbbxHCgCUPRz SPneZ+wTlEH4tVhQlap1/uZ0crUcF6+V3G3Gf++xrihEwR8jq02nFDwz1RiV+e3Jp9E/ vr1w==
X-Gm-Message-State: AOAM532R9US614LP78SsThSgb6Ze/AmWY5yxGOobU/w/FBRsGo8P9JVC Eti33UzBB713J1KknqfVCfa3hSgxlxDWmZHgyn6gzB91t10=
X-Google-Smtp-Source: ABdhPJzFQvyyXp6ScCm9KtNjNDce39g26qSG/wzFTBON25kisRe5T/CuRHm4u0s2EfgtqCP4N2b0iN3JLNvCMx+F84E=
X-Received: by 2002:a2e:a492:: with SMTP id h18mr43509549lji.161.1621108106859; Sat, 15 May 2021 12:48:26 -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> <CAHbrMsDvEkYAxee4xjW5LsQmr0PgBf+UmMAuME-_UvRMg4jJeA@mail.gmail.com>
In-Reply-To: <CAHbrMsDvEkYAxee4xjW5LsQmr0PgBf+UmMAuME-_UvRMg4jJeA@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Sat, 15 May 2021 12:48:14 -0700
Message-ID: <CAH1iCiq4zJZBv5=f7T2EDRWKa7bAZx66SMKkf+AiDsDPTZokhQ@mail.gmail.com>
To: Ben Schwartz <bemasc@google.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/alternative; boundary="000000000000da16fd05c263a44f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9U_i7jVHwGErwsAz70FrNRtqzHw>
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: Sat, 15 May 2021 19:48:33 -0000

On Thu, May 13, 2021 at 10:25 AM Ben Schwartz <bemasc@google.com> wrote:

>
>
> 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:
>>>
>>
> 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.
>>
>
>
> Considering alternative formats is an intriguing exercise, but I do not
> think it is likely to result in improvements to SVCB.
>

So, my first alternative format (for splitting out key/value pairs)
involved adding another component to the record format, which (as you
noted) allowed for multiple instances of TargetName.
Here it is again for reference:

> Encode everything using the following mechanism:
> Priority Enumeration Key Value
> One of the "Keys" would be Target, with a corresponding Value of FQDN.
> All of the records with the same value for "enumeration" belong together,
> and form a single SvcParameter list.
> For the AliasForm, both the Priority and Enumeration would be 0, and only
> a single Target,Value pair are permitted.
> To take one example from the draft, and re-encode it thusly:
>  $ORIGIN svc.example. ; A hosting provider.
> pool  7200 IN HTTPS 1 h3pool alpn=h2,h3 ech="123..."
>               HTTPS 2 .      alpn=h2 ech="abc..."
> pool   300 IN A        192.0.2.2
>               AAAA     2001:db8::2
> h3pool 300 IN A        192.0.2.3
>               AAAA     2001:db8::3
> This would become (for brevity, encoding just a list of RDATA values for
> all of the "pool HTTPS" records):
> 1 1 target "h3pool"
> 1 1 alpn "h2,h3"
> 1 1 ech "123..."
> 2 2 target "."
> 2 2 alpn "h2"

2 2 ech "abc..."


So, taking your observations about TargetName into account, and borrowing
from the overloading of Priority to signal AliasMode, here's an alternative
that I think addresses most of the concerns.
Priority {AliasTarget | ServiceTarget | KeyName}
{ServiceBindingPriorityValue | Value}
where
Priority == 0 => AliasMode
Priority >0, <128 => ServiceMode
Priority > 128 => ServiceBinding key-value record

The same example would be encoded (again with only RDATA values):

> 1 target "h3pool" 128

> 128 alpn "h2,h3"

> 128 ech "123..."

> 2 target "." 129
129 alpn "h2"
129 ech "abc..."

The Priority values are sortable (as required), and sorting all the records
has the side-effect of grouping the key/value pairs.
If desired, the key/value pairs can be sorted by the first two fields
(priority and key) to check for uniqueness before use.
The look-up of keys and values, or the recombining into some arbitrary
structure (whatever the output of parsing the wire format from the current
proposal is), seems straightforward.
The parsing of each record's presentation (zone) format is as simple as
whatever each individual parameter's format requires/allows.

And, there is no longer any ability to introduce duplicate target names in
a single record reconstruction, as the ServiceMode record is distinct from
the key/value set.

If necessary, the presentation and wire formats for key/value records could
add an extra "." to avoid burning the Code Point already allocated. That
"." would simply be ignored, and add one byte (I think) to the wire format,
plus the other relative inefficiencies already noted.

I think this is sufficiently different from the earlier encoding, to be
worth consideration.

Brian