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

Tim Wicinski <tjw.ietf@gmail.com> Fri, 21 May 2021 18:58 UTC

Return-Path: <tjw.ietf@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 5782C3A1B70 for <dnsop@ietfa.amsl.com>; Fri, 21 May 2021 11:58:03 -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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 A-I7TgeL_evj for <dnsop@ietfa.amsl.com>; Fri, 21 May 2021 11:57:58 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 9AACC3A1B6D for <dnsop@ietf.org>; Fri, 21 May 2021 11:57:58 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id o8so25208561ljp.0 for <dnsop@ietf.org>; Fri, 21 May 2021 11:57:58 -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=E52tdIoJjkVLPVYZBtwGJIfDGwxboi5H0sWuqH34tFA=; b=p3Vi3/fk4HjSElwFICIRc9Dw6Yqi5Ufw+mtXhgfDJ5QhpbEjH/WzdPVtFtYYVo9rRj lf7bF3bwkvemcY6UkmB/xDIEOfeh1iC2TIvxSlLENIuvlXol6xP2QOLpooPaWLcJdl0v NRiV0ZPr3EZ2RaDOIKdxGqpanlqCMqNhOymqcy6HFmbS+Mt7AifrecQ424h5E72kehrG Q2aQOLuUzPxui8FTYw8jQZ2r86PFjXDjtfaZhWKUs/UbQIHqhijbzLdYh2vv141JYTkx YWHZY5R5ilsv6+6ilpRn4ypBOIMR/3WedH5outzYUqf6MXOz3iNL9MPlRYwXQpjPv/4z FBLQ==
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=E52tdIoJjkVLPVYZBtwGJIfDGwxboi5H0sWuqH34tFA=; b=Uwn4I87o+N84XvbThIem3cEiGuVx8931SWWDxHr7euzBgzxwP3ppsNx9MmwPG+XIoW 40rOosCTwCPKKP/IAklZBXcdAC0Kz4hGfIRCab5NNVQeJz2Azx+zmuJMVai860Fo13rr Qu5WNf+V4aAuO6wB1vCaV+1N+KtDBlFZRPV0vrOD8XGqBP5TkQItw5nEjaTO+WHnXDRx wvkPUDXlbn6OTYbAaJAG2GkqnzKKjYehyKnJsViKMPVz6EvmCcSW7wSaTwNm6wyASY61 pUt9jgBzIleoGsRi2iwzMQEOIEu2+iFV9N5L1ACkCUs1eyCrmclQQGztz7vpp4dVdmhG jmtQ==
X-Gm-Message-State: AOAM530Pkrj8Br9XAKMUg7Ap9Mhz+8ECrjWDFNx9J5xoQaFavy0ujprK 4tXFH2iZ6ZipfzgpgyftMF1ggq12h/oaDWIV2do=
X-Google-Smtp-Source: ABdhPJxRkECdcFcqLtP84cXwAd2vfq9MS8U/FHnAGPMIbIqRYMkSkjzTaiKTuZs19MtPkNfjQ5zWEFfUcOcu5ZVc9Wo=
X-Received: by 2002:a2e:2f14:: with SMTP id v20mr7788421ljv.363.1621623471480; Fri, 21 May 2021 11:57:51 -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> <CAKC-DJhH=OK_mraWK1pVEx6a_hiPSPF-KQwd+mDy_2mg_a17CQ@mail.gmail.com> <CAH1iCip=Y0MTh4=ATqWPdWSDot4dmBge96Y-cdL86hk3dk3ddg@mail.gmail.com> <9a138693-60a0-4b75-99f5-6a7544f935a0@www.fastmail.com> <CAH1iCirdY4HWj1o8X3mEkPJODrQZ391YsuC75Hs5m5G4PM3ATA@mail.gmail.com> <1A6728DB-72CB-425E-90D7-38159DC8D4FB@fl1ger.de> <CAMOjQcF=K_Dkya7yamKECxHjmsEVHmLyoaoF3KRnCXqPde4wSw@mail.gmail.com> <91F79DA0-4BD9-414C-973D-024F3583F3EB@fl1ger.de> <CAH1iCioNaPJUbKojB3jMhQpv+k3XquzL8qeH_9tZDHrUCSTKHw@mail.gmail.com>
In-Reply-To: <CAH1iCioNaPJUbKojB3jMhQpv+k3XquzL8qeH_9tZDHrUCSTKHw@mail.gmail.com>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Fri, 21 May 2021 14:57:40 -0400
Message-ID: <CADyWQ+G0oZNCqWUafTxLq-0iOs0C+Jn06FF4tGs19NQSdCg1hg@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: Ralf Weber <dns@fl1ger.de>, WG <dnsop@ietf.org>, Martin Thomson <mt@lowentropy.net>, Eric Orth <ericorth=40google.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fa5a1805c2dba2e6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/d-3BaOR9HRz4grE75s1LUQ9zLjg>
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: Fri, 21 May 2021 18:58:03 -0000

All

The WGLC has been closed.

There will also be an IETF LC to raise concerns.

tim


On Fri, May 21, 2021 at 2:17 PM Brian Dickson <brian.peter.dickson@gmail.com>
wrote:

>
>
> On Thu, May 20, 2021 at 11:29 AM Ralf Weber <dns@fl1ger.de> wrote:
>
>> Moin!
>>
>> On 20 May 2021, at 19:59, Eric Orth wrote:
>>
>> > A big selling point behind why we have client implementers planning to
>> > query HTTPS records is the expectation that this will be the only query
>> > type we will need to add and that it can be extended to handle any
>> future
>> > information we need for establishing HTTPS connections (and we want
>> > mechanisms to be able to add stuff in the future to keep improving HTTPS
>> > connection behavior).  It is not practical to add too many additional
>> DNS
>> > queries to make web requests, and nobody wants a
>> > deprecation/new-SVCB-based-record-type cycle every time we need to add
>> > something.  So in the end, I do not expect HTTPS would see much adoption
>> > without the extensibility.
>> I fully agree. The point I was making is that ECH sort of already is an
>> extension that were not in the original draft and there may be other
>> Enhancements in the future.
>>
>
> I think the handling of presentation formats and wire formats leaves much
> to be desired.
>
> However, the handling of future extensions is not (IMHO) currently usable
> via the existing proposed mechanism.
>
> The discussion about "what if ECN needed to be added later" got me
> thinking about the issue.
>
> I think there is a need for something similar to RFC3597, except for
> fields in a record rather than a BLOB for the record itself.
> RFC3597 is fine for an RRTYPE with only one RDATA element/structure, but
> not for complex RRs.
> So, this problem on sub-field encodings has arisen from ignoring RFC5507
> (regardless of why it has been ignored).
>
> There is a pertinent question about any method of addressing this gap:
> should it be limited to SVCB (part of this draft), or its own thing?
> I can see valid arguments either way.
> If it is a standalone thing, that would seem to encourage, rather than
> discourage, ignoring 5507.
> If it is part of SVCB, it would not be expected that an authority server
> would support that outside of supporting SVCB/HTTPS.
> Possibly, it could be seen as an enhancement to 3597, in which case the
> standalone should definitely point the reader at 5507.
>
> Here's a short list of things I think such a scheme should have:
>
>    - A set of defined presentation-format:wire-format (bidirectional)
>    mappings
>    - A method of applying a label to a key number
>    - For backward compatibility to any existing implementations, these
>    should both be optional, with the existing mapping as the default
>    - The set of mappings should be independent of the key numbers to
>    which they are applied
>    - The set of mappings should be a superset of any mappings used in
>    SVCB already, and should include other well-known mappings
>    - There should be a mapping type for "flag" where the existence of the
>    keyNNN without any data is supported for both presentation and wire formats.
>    - This mapping should be used for all of the existing SVCB parameter
>    types that already exist, to make implementation much easier and consistent
>
> Here's what I think would work:
>
>    - keyNNNN:label:mapping=value
>
> with the following alternate formats:
>
>    - label=value -- requires label be understood by the server, including
>    both the corresponding key number and mapping
>    - keyNNNN::mapping=value -- no label included
>    - keyNNNN=value -- no label included, default generic mapping
>    - keyNNNN:label=value -- label available, default generic mapping
>
> For purposes of examples, here are some suggested mappings:
>
>    - TLVSorted - space-separated sequence of name=value mapped items;
>    wire format is a sorted sequence of 16-bit key, 16-bit length, and
>    wire-format value defined for the corresponding key (sorted by key number)
>       - SVCB and HTTPS formats are TLVSorted
>       - Presentation formats do not need to be sorted
>    - uint16 - single integer with no leading zeros, maps to 16-bit
>    unsigned value, must be a singleton
>    - uint16SortedList - comma-separated list of integers between 0-65535,
>    maps to a sorted sequence of 16-bit unsigned values
>    - base64 - base-64 encoded blob, maps to whatever binary it decodes
>    to, must be a singleton
>    - flag - has no value in presentation format, has no data in wire
>    format (implicitly a singleton)
>    - ipv4list - one or more IPv4 addresses in acceptable standard format
>    for an A record - if multiple, space separated and double-quote delimited;
>    maps to a sequence of IPv4 addresses (A record wire encoding)
>    - ipv6list - one or more IPv6 addresses in acceptable standard format
>    for an AAAA record - if multiple, space separated and double-quote
>    delimited; maps to a sequence of iPv6 addresses (AAAA record wire encoding)
>    - CSV - one or more strings, separated by commas, enclosed in double
>    quotes, as follows:
>       - inside quotes is encoded as the subset of printable-ASCII
>       characters in the range of decimal 32 to decimal 126 with escaped
>       (backslash) double-quote, escaped escape (double backslash), and also
>       permitting other 8-bit values as escaped-decimal values \DDD
>       - maps to sequence of (length | value) where each length is uint8
>       and length(value) is between 1 and 255 inclusive.
>       - mapped value of one string from the list is the contents of the
>       substituted string (e.g. with escape substitutions performed) without the
>       enclosing quotes
>    - FQDN - a valid domain name; maps to wire-encoding for a domain name
>    - The defined field mappings may be added to by <TBD> process (RFC
>    required, Standards Action, other?)
>
> Here's what I think the appropriate key/label/mapping should be for the
> initial record and SvcParams:
>
>    - SVCB/HTTPS Resource Record is:
>       - SvcPriority (uint16)
>       - TargetName (FQDN)
>       - SvcParams (TLVSorted)
>    - SvcParams table keynum/label/mapping:
>    - 0/mandatory/uint16SortedList
>    - 1/alpn/CSV
>    - 2/no-default-alpn/flag
>    - 3/port/uint16
>    - 4/ipv4hint/ipv4list
>    - 5/ech/base64
>    - 6/ipv6hint/ipv6list
>
> The specifics for alpn and CSV are somewhat novel, I realize, but I think
> they are sufficiently unambiguous and well-defined to enable 2-way mappings
> of arbitrary binary blobs of up to 255 characters, so can handle any
> potential ALPN value.
> Thus, the example used of foo\\,bar,h2 would be, as a CSV, "foo,bar","h2",
> and in wire format would be "\x00 \x11 \x07 foo,bar \x02 h2".
>
> Brian
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>