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

Ben Schwartz <bemasc@google.com> Mon, 17 May 2021 21:35 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 A6CC03A45DF for <dnsop@ietfa.amsl.com>; Mon, 17 May 2021 14:35:48 -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 DTTxpc8k6JR9 for <dnsop@ietfa.amsl.com>; Mon, 17 May 2021 14:35:46 -0700 (PDT)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 3A7ED3A45DD for <dnsop@ietf.org>; Mon, 17 May 2021 14:35:46 -0700 (PDT)
Received: by mail-wm1-x336.google.com with SMTP id f75-20020a1c1f4e0000b0290171001e7329so357369wmf.1 for <dnsop@ietf.org>; Mon, 17 May 2021 14:35:45 -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=HCRAuOU3U39zxsSy5W0Txphkb2/V9fY6nhknSyQSLfI=; b=khKwQbCfwU/nyhwngtyETMFQoOdzhiBDaqiIBkzS4/3Yafwb9z6nMHl1QkoMzizC1Y 3Bcte6b++gPjKOK+P9el7sO/dg/dqKkHTovP8lyiU+Y7pun24VHP2SxpSNTZbVtpZw6V gf3LWXAHi+BYRFWuVKGBX27KAwpFTtAOfSnfw/9n/TAo3JkIpQ6fJnxCuANsaiF4wBFH ZyxkZLMH+NmrzM6QnfXmAznAXHY4oEW5HJes3kZNv9uNHkL6DbAfTH0HXBKiiwKOiWtl aX5WLl9S0F81cOUQ08dP7HTw2FgMdZ7kXZ98PRS5H0HkdHMYbLaCva+Do7whBIXPiCed llhQ==
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=HCRAuOU3U39zxsSy5W0Txphkb2/V9fY6nhknSyQSLfI=; b=QaCvRtbXCUTQhxJq0fwEcyMvHDC9Bs6I5IYotiTrkL6WTIbrVLuvNSDdkMfp4HtRXB GGYeVQc23JdfdXjS0Lh5KJhKMP0s1ssGwucBvehYn2OW57OSczVKQFkhI2DgWcmiCsoo 7pk/QqWR+XYt42fJudj1EMSN+HQGB0Q/mrXs25ruB14pWdM0BG5NNRNjF+ys88Ij5/i3 HE+aZuVQBPQNLXI2PAkidrWVKqpOEXgTXPa5rBMRqU5ktY1Li5Cc9XqphraWR2i+EG0y EG4I9OmBLGUMrax+OpWMJ46xL+6mypGoplr9VSfT7A4C9qGWCPdXZPuh+Y/9+Yh4cxKX u4bA==
X-Gm-Message-State: AOAM530VcchMvXgDeFtKTR3t5ZwE7BJBzIe1QdoFfeHjcKp2n/RqjRZv nPaW0TZ0p9xzI5m/3MRVpNEVyLn6YGu9qIvNQqZLOg==
X-Google-Smtp-Source: ABdhPJzyYNP33dzHOfbGSSV4D9eOkCT+y4rqxlV13F8WRrffV3yMNM8V72RL1VHX33x6bw5QEyEjd2IOwuyRWlVuPAM=
X-Received: by 2002:a05:600c:3388:: with SMTP id o8mr1033166wmp.101.1621287341772; Mon, 17 May 2021 14:35:41 -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> <CAH1iCiq4zJZBv5=f7T2EDRWKa7bAZx66SMKkf+AiDsDPTZokhQ@mail.gmail.com>
In-Reply-To: <CAH1iCiq4zJZBv5=f7T2EDRWKa7bAZx66SMKkf+AiDsDPTZokhQ@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 17 May 2021 14:35:28 -0700
Message-ID: <CAHbrMsAW_wtKmRDYKZVUrFLZYuM_DqoS-8VRMf-O0Z8WpPBfbg@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="0000000000001d855f05c28d603b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KeukBuA9wDkp0iv1fgvOHWJIdPw>
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: Mon, 17 May 2021 21:35:49 -0000

On Sat, May 15, 2021 at 12:48 PM Brian Dickson <
brian.peter.dickson@gmail.com> wrote:

>
>
> 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:
>>>
>> ...

> 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.
>>
> ...

> 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..."
>

I find this format, with multiple lines and multiple integers per binding,
much more difficult to read or write than the current draft, especially
since the elements of each binding can potentially be spread across a zone
file (perhaps by accident) in arbitrary order.

The Priority values are sortable (as required), and sorting all the records
> has the side-effect of grouping the key/value pairs.
>

Depending on how you choose your priority pairings, it looks like sorting
can actually mis-group the pairs and target-names.

Perhaps this can be sorted out somehow but I don't think this represents an
improvement over the present draft.

...

> The parsing of each record's presentation (zone) format is as simple as
> whatever each individual parameter's format requires/allows.
>

It sounds like you're proposing to use exactly the same type-specific value
parsing as specified in the current draft.  That parsing logic for various
key types represents the majority of the implementation effort.  The only
element this format eliminates is the key=value syntax, which is a small
part of the implementation.


> 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.
>

This is not true.  In this format, two "target" records with different
TargetNames can be written with the same priority, and logic is presumably
needed somewhere to prevent this.

If necessary, the presentation and wire formats for key/value records could
> add an extra "." to avoid burning the Code Point already allocated.
>

The wire format that you've proposed is not meaningfully compatible with
the current SVCB draft, so it would need a separate codepoint regardless.

>