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

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 19 May 2021 23:00 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 5E2B83A228D for <dnsop@ietfa.amsl.com>; Wed, 19 May 2021 16:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, URIBL_BLOCKED=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 HnFB2wU0jShh for <dnsop@ietfa.amsl.com>; Wed, 19 May 2021 16:00:42 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 5C98C3A228C for <dnsop@ietf.org>; Wed, 19 May 2021 16:00:42 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id e11so17428435ljn.13 for <dnsop@ietf.org>; Wed, 19 May 2021 16:00:42 -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=wPY8BeSyOHMGuKqv7ziZRyqL6tYHZpoObxPcloGP8Jo=; b=ODaoZA7lPgD0f+O5TcfzNH336d+r9LswF9HcA6AelkhJYWOkbkEAGPGt66XuIBAL1I TmpjYp3fwjTquowMKVmqBmfFye/4IC6fF9OASF5JTW0dbL0GWPiRt+4cjAYTS3XU/01U uTE6/yALETQALELxvbaGBc8uZkcXa3gMWC61A/8mVZmi1Om81VLmoeQUSV0dkImetD2f HBpIIFnljwlHX0snH2R0pDQo4JHtuDeIt+KOrctfXRmVqJs9dd+iS/n5oVR5Rfk3E1zd PtNV0fdnsUKPca0pDU5RCy6fGBgylp6LwoNKgoiGxxp7/qYyGal5UY7YHqogS3R4zSs5 UANQ==
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=wPY8BeSyOHMGuKqv7ziZRyqL6tYHZpoObxPcloGP8Jo=; b=Om/7i1HRzkX6cC5SAGkmxcnojg2CszSP6aSsdkBJkWJ3MDzwzDatpuYrJUALCtu08d vZ5j19aSvUy8XA7Jnij1Ln49aDF/8tLwB7CUhvsuft4JKYcJveY0CpODZDslP2vRUdP/ e9PNCPBhEamhpabGL/ls17VAhqOkr/CVd+L1dhnCELw2Szdprv4dPEq5dENfLyQ87RRG iRneisOxhmiGtP1z/Fkq6IVvcTGCUwyGxczTslj0ZgTqc9k8T92LEj5sDIKl78CPJ8qB l6KHnVWAoC+/1zCQ3KSEYhvbDVDt1m5SYquxsAWvcS1rrmQp1JYfa2F7kIBXmsMK+tKy nIYA==
X-Gm-Message-State: AOAM533wNmOaG1jpnmJfBJhhA6xLpWAl8p+hzDCdRhnCbGGxkCnzwray ZtrczjxhsxkfAl/OK3Iv0DSVFbuAOPpNxhnvbhIsrtopfDk=
X-Google-Smtp-Source: ABdhPJxNBMsXQRi7O6miVY+stMDikYkLo2GmSOOs0/cCzNN9X5sIGjUr/TBbZUJzn/WtEYuaxU7CKJJluFpyTxIfjg8=
X-Received: by 2002:a2e:8717:: with SMTP id m23mr1043997lji.161.1621465239927; Wed, 19 May 2021 16:00:39 -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> <CAHbrMsAW_wtKmRDYKZVUrFLZYuM_DqoS-8VRMf-O0Z8WpPBfbg@mail.gmail.com> <CAKC-DJj3nPAZp=qpwjBJ_3yG_EO-q-bcJbaizUNw9uq6deVZjg@mail.gmail.com> <C3734365-D5F7-4F9A-A463-5EFBB841A583@apple.com> <CAH1iCiod61M5aHnF_qrpP6=Oc3nBL+McaSui5NUnLd1GbS=okw@mail.gmail.com> <CAH1iCipcjnHdBcc7VCpLr9rP6vbbTHKYPHtqBkQu_achzpohcg@mail.gmail.com> <D10F7DCD-71AE-4AFC-9835-C9E1F03D831F@icann.org> <CAH1iCiphr71C0MjhP-amR4S5FpDzKc4qkDvsU3qMXhdLNhiwyw@mail.gmail.com>
In-Reply-To: <CAH1iCiphr71C0MjhP-amR4S5FpDzKc4qkDvsU3qMXhdLNhiwyw@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 19 May 2021 16:00:28 -0700
Message-ID: <CAH1iCiqSFk0XP_We+cUfe0xFvmDMusPc3weHxSK-e5CLT6jLwg@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a43f7f05c2b6cb94"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/SSIURmZ0Um5vMa99k46DVtDKAL4>
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: Wed, 19 May 2021 23:00:47 -0000

On Wed, May 19, 2021 at 3:00 PM Brian Dickson <brian.peter.dickson@gmail.com>
wrote:

>
>
> On Wed, May 19, 2021 at 2:50 PM Paul Hoffman <paul.hoffman@icann.org>
> wrote:
>
>> Are these still just idle ideas you are tossing out (as you indicated
>> earlier), or meant to be serious proposals? If the latter, what is the
>> significant improvement over the current draft? I ask because it feels like
>> you are suggesting moving the inherent complexity of the semantics of SCVB
>> around, but not noticeably reducing it overall. Unless there is a
>> significant reduction in complexity, I don't see the value of grinding on
>> this further. (I say this as someone who is not happy with the current
>> level of complexity of the semantics, but don't see a way to reduce it.)
>>
>> --Paul Hoffman
>
>
> It is meant to be a serious proposal.
> The improvement is in the clarity and parse-ability of the HTTPS record in
> zone file format, including reducing the complexity of the HTTPS-specific
> semantics, without changing the actual wire format semantics or complexity
> per se.
>
> I'm working on the details of that, but it will necessarily be its own
> work-in-progress. I hope to get something stable based on feedback... I
> don't expect to get it 100% right on the first pass.
>
> The first pass should hopefully illustrate the benefits at least, and
> justify keeping list activity ongoing.
>

Here is a very very brief version of HTTPS (call it HTTPS RRTYPE version 2
pre-alpha-1, I suppose) ServiceForm RDATA (following the SvcPriority and
TargetName):

   - Make the "mandatory" field a derived (calculated) value, not an actual
   component of the zone format
   - no-default-alpn is a flag and excluded from the derived "mandatory
   set" (i.e. automatically mandatory) - no change, semantically
   - port is numeric, if present, and excluded from the derived "mandatory
   set" (i.e. automatically mandatory) - no change, semantically
   - ech, ipv4hint, and ipv6hint are string values (space separated list of
   values for *hint), and additionally marked as either mandatory or optional
   (syntax TBD) - conditionally added to "mandatory set"
   - alpn is a space-separated list of string values, and additionally
   marked as either mandatory or optional - conditionally added to "mandatory
   set".
   - The HTTPS RDATA itself is an ordered sequence of values, with
   placeholder empty values occupying the respective position, using the empty
   string ( "" ) if a parameter is not used
   - Thus, the RDATA is positional in nature, very similar to the SOA zone
   file format, and does not require any use of "key=" components at all
   - The sequence of values in the RDATA is "no-default-alpn", "port",
   "ech", "ipv4hint", "ipv6hint", "alpn"
   - The placement of alpn as the last element of the RDATA allows it to be
   a list of an arbitrary number of strings, rather than a singleton, which
   avoids the escaping characters issue.
   - The zone file format and parsing are deterministic and bidirectionally
   congruent.
   - The proposed marker(s) for either "optional" or "mandatory" are "~"
   for optional, and "+" for mandatory (similar to usage in SPF)

Note that, similar to the SOA record, most hand-editing of zone files would
involve copying the commented blank form, and changing whatever needs to be
specified according to the actual intention of the domain owner.

Here are some of the examples from the original draft, re-imagined with the
new zone file encoding.
NB: new zone format,  but representing identical corresponding wire formats
to the original examples:

alpn=h2,h3-19 mandatory=ipv4hint,alpn ipv4hint=192.0.2.1
( "" ; no-default-alpn is "no" aka not-present
  "" ; port - not present
  "" ; ech - not present
  "192.0.2.1" ; ipv4hint, mandatory (not marked with "~")
  "" ; ipv6hint - not present
  "h2" "h3-19" ; list of alpn values, mandatory (not marked with "~")
)

alpn="f\\\\oo\\,bar,h2"
( "" ; no-default-alpn is "no" aka not-present
  "" ; port - not present
  "" ; ech - not present
  "" ; ipv4hint - not present
  "" ; ipv6hint - not present
  "~foo,bar" "h2" ; list of alpn values, optional (marked with "~" on first
string meaning optional)
)

ipv6hint="2001:db8::1,2001:db8::53:1"
( "" ; no-default-alpn is "no" aka not-present
  "" ; port - not present
  "" ; ech - not present
  "" ; ipv4hint - not present
  "~2001:db8::1,2001:db8::53:1" ; ipv6hint, optional (per initial "~")
  "" ; alpn - not present
)

port=53
( "" ; no-default-alpn is "no" aka not-present
  "53" ; port
  "" ; ech - not present
  "" ; ipv4hint - not present
  "" ; ipv6hint - not present
  "" ; alpn - not present
)

(No parameters other than priority and target)
( "" ; no-default-alpn is "no" aka not-present
  "" ; port - not present
  "" ; ech - not present
  "" ; ipv4hint - not present
  "" ; ipv6hint - not present
  "" ; alpn - not present
)

alpn=h2,h3 ech="123..."
( "" ; no-default-alpn is "no" aka not-present
  "" ; port - not present
  "~123..." ; ech, not mandatory (marked with "~"
  "" ; ipv4hint - not present
  "" ; ipv6hint - not present
  "~h2" "h3" ; list of alpn values, optional (marked with "~")
)

alpn=h2 ech="abc..."
( "" ; no-default-alpn is "no" aka not-present
  "" ; port - not present
  "~abc..." ; ech, optional (not marked with "~")
  "" ; ipv4hint - not present
  "" ; ipv6hint - not present
  "~h2" ; (list of) alpn value(s), optional (marked with "~")
)

ech="111..." ipv6hint=2001:db8::1 port=1234
( "" ; no-default-alpn is "no" aka not-present
  "1234" ; port
  "111..." ; ech, optional (not marked with "~")
  "" ; ipv4hint - not present
  "~2001:db8::1" ; ipv6hint, optional (marked with "~")
  "" ; alpn - not present
)

port=8002 ech="..."
( "" ; no-default-alpn is "no" aka not-present
  "8002" ; port
  "~..." ; ech, optional (marked with "~")
  "" ; ipv4hint - not present
  "" ; ipv6hint - not present
  "" ; alpn - not present
)

Compactness in a zone file format is not a feature, it is (IMNSHO) a bug.
Clarity and unambiguous parsing, and round-trip (zone->wire->zone) identity
are attributes that should be major considerations.

Brian