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

Brian Dickson <brian.peter.dickson@gmail.com> Mon, 17 May 2021 21:46 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 A905B3A4639 for <dnsop@ietfa.amsl.com>; Mon, 17 May 2021 14:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=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 hLFhKEgK5xW9 for <dnsop@ietfa.amsl.com>; Mon, 17 May 2021 14:46:28 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 55E383A4636 for <dnsop@ietf.org>; Mon, 17 May 2021 14:46:28 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id w4so9029440ljw.9 for <dnsop@ietf.org>; Mon, 17 May 2021 14:46: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=os0NHabPem7HCZFdQRJ1qzIe943eOxhqXNsgpK5r40M=; b=FfiP7KD9H3EoOb4P4U0u22uBFPFI+yJiYaIm6L8VvC/wEULMGbdUStacbh6Qi21d5G r90UqRsoAnGA86j7K9CoGSmlYKRcA60urJCSStfnBj+RBeb6n0A6hQKeXYy4D0ySJCPg NuQZf1EcCFyphBEIWZS9TPDkPwObgG/CwqK//8J5oD/VaTRZ0kJfzsmAog/CKsbJDGtY IJ6zwGmDG0CbxM5V1Ic1lncIF6JbXODM5z3Yyj1N7VrjUNUQoXhpeZxJlPxTPeilR+CQ WLgJof3gSoOCttyn04pZthIleNBCiRtcreRDX/ZOXis6mJbzzo9i746rXsYjieFgkz/t d68Q==
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=os0NHabPem7HCZFdQRJ1qzIe943eOxhqXNsgpK5r40M=; b=iZqXFvEzUbpOU70yD9hZlr24rqqAdIG7Dajd3cCnu6Kv3YxnILoAdyNgWR6GHd5COh JyrBezVcvCA2UJeVEDNIwOCz+FJk7ZRecyUOlg7PXsvyze6OCY+kS8EzVeScDgBbPEDN v4sty/LoQqtJuV2O6GSfqs3Lv6TX2xtcu3WZrQUoVDriE+df/P/CfYJqxCptiSLc60LX LVu8N0hO1HtaIB0MjKoSP1a8XYM0gll8FJ2MMGsLWCQN+JXEzyerf5MxPGtRY9TY3U4b nFRTnh3d8lUB13Q7ej965Mw4mLf9THMOHvQ36bgYQlSLZNrmt5ZxrbrKN1/3IYzqLLVx gTig==
X-Gm-Message-State: AOAM530YAEgY6QvagXwwFm69KJjjBWaBeOF1ApawtluuZI9HyeM3+Vns thQAqbI40Ju+mdw2vtLa/lK6bSKI+NGbpXcvNVs=
X-Google-Smtp-Source: ABdhPJx6h4RQwpeO4JBh7hy6m3k72zU5tWqjEVTVEDAr5TVqeRP/cbYFn+8rLLHS3m9nShatR99nODqhUFDJ6VroeAE=
X-Received: by 2002:a2e:a492:: with SMTP id h18mr1151363lji.161.1621287986480; Mon, 17 May 2021 14:46: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> <CAH1iCiq4zJZBv5=f7T2EDRWKa7bAZx66SMKkf+AiDsDPTZokhQ@mail.gmail.com>
In-Reply-To: <CAH1iCiq4zJZBv5=f7T2EDRWKa7bAZx66SMKkf+AiDsDPTZokhQ@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 17 May 2021 14:46:13 -0700
Message-ID: <CAH1iCioNgQMjEZSeRdD3OmxPsboybF4XfcdwEC-hEjBLGA88XA@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="0000000000008361bd05c28d861b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9slecckYMr7LlcNTag_RjOkBlo0>
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:46:31 -0000

Here is a slightly deeper dive into this alternative scheme (for zone
file/presentation and wire format), in terms of both the encoding, and the
specification document itself (and as a result, the IANA components).

I re-read (several times) the current -05 version of the draft. I found it
difficult to follow and understand several aspects of the "automatically
mandatory", "mandatory", and mandatory usage in the document, both
syntactically and semantically.
The actual binding specifications also were either incomplete or confusing,
with respect to the mandatory/"mandatory" things.
(Default values for alpn, plus the "alpn" parameter, and "no-default-alpn"
were similarly a bit hard to follow, and/or hard to surmise from only the
binding entry.)
The list of parameters within a binding, versus across bindings, was also
somewhat ambiguous, which for subsequent bindings (e.g. from new RFCs after
this become an RFC) could be confusing or even result in conflicting
bindings.

Here are some specific suggestions, including incorporating the updated
proposed encodings:

   - Use the term MTI (mandatory to implement)
      - MTI parameters would be "alpn", (maybe) "no-default-alpn", and
      (maybe) "port"
      - The IANA table in 14.3.2 really needs an MTI column in addition to
      the other columns
   - For each binding registry, an additional table column specific to that
   registry should be included/added: "non-negotiable", i.e. MTI for this
   binding.
   - Replace the "mandatory" thing, with an "optional" flag to be
   optionally appended to any parameters that are not "non-negotiable".
      - This also removes the need to have a sorted list of mandatory
      attributes
      - Each binding will have a list of non-negotiable attributes, which
      can be used for validating the "optional" flag on both the authority side
      and the client.
      - Any parameter that is not non-negotiable, but does not have the
      optional flag, must be supported by the client for the parent HTTPS/SVCB
      record to be accepted by the client.
   - The binding tables then become lists of parameter sub-types that the
   specific binding uses, marked as optional-allowed or non-negotiable. The
   binding table incorporates all the MTI sub-types as well.
   - The binding tables obviously still need default values (if
   appropriate), e.g. for ALPN.

The HTTPS binding would then consist of:

   - Default ALPN of "http/1.1"
   - MTI of "alpn"
   - NN of "port"
   - NN of "no-default-alpn"
   - Optional of "ecn"
   - Optional of "ip4hint"
   - Optional of "ip6hint"

And an HTTPS referenced record (included by reference from record with
SvcPriority between 1 and 127), would have the following rules:

   - Any "optional" parameter MUST be implemented by the client, UNLESS the
   "optional" flag is present in the HTTPS referenced record
   - This rule applies to "ecn", "ip4hint", and "ip6hint" records (each has
   its own "optional" flag, and that flag is only applicable to the parameter
   associated with the main HTTPS record linking to the parameter).

I'll follow up with examples, that correspond to the examples in the
original document.

Brian

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