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

Erik Nygren <erik+ietf@nygren.org> Thu, 20 May 2021 00:15 UTC

Return-Path: <nygren@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 48C063A250E for <dnsop@ietfa.amsl.com>; Wed, 19 May 2021 17:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 sT_w3-PYtFG4 for <dnsop@ietfa.amsl.com>; Wed, 19 May 2021 17:15:45 -0700 (PDT)
Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (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 B2F313A250D for <dnsop@ietf.org>; Wed, 19 May 2021 17:15:45 -0700 (PDT)
Received: by mail-wr1-f52.google.com with SMTP id p7so12015561wru.10 for <dnsop@ietf.org>; Wed, 19 May 2021 17:15:45 -0700 (PDT)
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=WoQ9+GTq6wiDfwn9UFFFASxyYeHCSvqbdq7q9w1qR+s=; b=lvcy87JiLDSiWvYnEpxmOyr49q3UypYWnsKVowo8HaY/xnB/66/WBYWWgCwlMjQSDq aomwU4ijWd+NweBPjKgMvDOIKFqrKoRt3HGaqjnAufU361qJOHgTUTuDPiJGTwigT2TZ IhKDH7CPZQASkN2NpGcF4J0eSkxg+HTZS5/zfRspOcMFbG3sIluF3BSRvuV7CsXgQzHb nZ+R5MNhSu5s8o/2wellRaC6NKszPQ+6JdMPhnPANobZc6chhIUf0J1jgc67lvcsetgy VqdBJz0bbzBSTtMPkNLsQLnruHvozM+3PSYJfhz/4Mq709Iavhsdv6JiwWcxTQEoONJY IbUg==
X-Gm-Message-State: AOAM532kidNr9jU26BDWglIzPl0Kkmim2vf6YwN1OKWYz1s9lTKZrRva dALQexZ/HKWUyGRHTzKvGFpwH8/oarb7/MXZYDc=
X-Google-Smtp-Source: ABdhPJwpYp2MU1AyME+gF/GgaaHbphaScFo6UJ3xqRnRhg3wRFOO+1jjiM9Xw4ZnJBs0CWEjkrVB+/62HCJqpZRibeY=
X-Received: by 2002:adf:e38c:: with SMTP id e12mr1390819wrm.128.1621469743903; Wed, 19 May 2021 17:15:43 -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> <CAH1iCiqSFk0XP_We+cUfe0xFvmDMusPc3weHxSK-e5CLT6jLwg@mail.gmail.com>
In-Reply-To: <CAH1iCiqSFk0XP_We+cUfe0xFvmDMusPc3weHxSK-e5CLT6jLwg@mail.gmail.com>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Wed, 19 May 2021 20:15:32 -0400
Message-ID: <CAKC-DJhH=OK_mraWK1pVEx6a_hiPSPF-KQwd+mDy_2mg_a17CQ@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: Paul Hoffman <paul.hoffman@icann.org>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000019780b05c2b7d83c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/yUaH389K3WHP4B8YSFQvSpRl70I>
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, 20 May 2021 00:15:50 -0000

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

>
>
> 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.
>
>
Unless I'm missing something, this appears to remove the ability for
extensibility by adding additional
SvcParams in the future?  That is a major feature and "selling point" of
HTTPS and SVCB records
(and is even why "mandatory" exists) so I would not be in-favor of a
proposal that removes the ability for future extensibility.

Best, Erik