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

"libor.peltan" <libor.peltan@nic.cz> Tue, 11 May 2021 10:30 UTC

Return-Path: <libor.peltan@nic.cz>
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 DFE913A0E1F for <dnsop@ietfa.amsl.com>; Tue, 11 May 2021 03:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 vLYGiS5Er58n for <dnsop@ietfa.amsl.com>; Tue, 11 May 2021 03:30:43 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6A13A0E17 for <dnsop@ietf.org>; Tue, 11 May 2021 03:30:41 -0700 (PDT)
Received: from [192.168.1.152] (mem-185.47.220.208.jmnet.cz [185.47.220.208]) by mail.nic.cz (Postfix) with ESMTPSA id D5A5A140ADF for <dnsop@ietf.org>; Tue, 11 May 2021 12:30:37 +0200 (CEST)
To: dnsop@ietf.org
References: <F4CE48A1-7AB0-45D0-97FF-158CE3A04EE1@icann.org> <3EE971EE-0777-44D6-9CD2-771B92FFE938@hopcount.ca> <1d822219-8ab9-2cb7-d0a4-9b8afc39058d@powerdns.com> <2952D408-117B-40D0-B859-7A8E4111629E@hopcount.ca> <CAHbrMsD+uiaYQ8i58VRjF=3AtW9uAoAtgbKzNzrPZC3QCmD2pQ@mail.gmail.com> <CAH1iCirykCpqkQEizYUBYMJEXMYRGkWvnzyo-jP=XOT-4fP-EA@mail.gmail.com>
From: "libor.peltan" <libor.peltan@nic.cz>
Message-ID: <123fd984-a3e1-0d09-b745-9a7ed6260759@nic.cz>
Date: Tue, 11 May 2021 12:30:37 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <CAH1iCirykCpqkQEizYUBYMJEXMYRGkWvnzyo-jP=XOT-4fP-EA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------1C9F3BAD49716A5885475970"
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/RQiO3FEt2BJcid1uxfBAh5_834s>
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: Tue, 11 May 2021 10:30:48 -0000

Hi all,

this is actually not the first time someone has come with this issue: 
https://mailarchive.ietf.org/arch/browse/dnsop/?gbt=1&index=WxZLxeJF3vSHiOG0jGm8kek5ajI

If there really is a strong reason for putting multiple key-value 
records into one RData (instead of one RRSet), it should be described 
somewhere clearly (more clearly than Ben's two pretty relativisable 
sentences). If so, I would accept it happily.

Brian, thanks for nice elaborate on the "counter-proposal". What exactly 
is illogical on that, in the end?

FYI in Knot DNS authoritative, we were able to implement 
zonefile<->wireformat transitions according current draft (being a Merge 
request to date). I feel no need to change the escaping manner.

Libor

Dne 11. 05. 21 v 1:59 Brian Dickson napsal(a):
>
>
> On Mon, May 10, 2021 at 9:58 AM Ben Schwartz 
> <bemasc=40google.com@dmarc.ietf.org 
> <mailto:40google.com@dmarc.ietf.org>> wrote:
>
>     I don't support breaking the SvcParams into separate RRs across
>     the RRSet.  This would be an extremely inefficient encoding in
>     wire format, and would conflict with the usual understanding of
>     resource records as independently meaningful alternatives.
>
> [snip]
>
>     To see why I favor two-pass, consider a SvcParam whose wire format
>     value is defined to be CBOR, represented as JSON in the zone
>     file.  JSON is defined as UTF-16, and allows strings containing
>     any character from the Basic Multilingual Plane.  It also allows
>     various kinds of backslash escaping including " \" " for quotes
>     within strings, and "\uD834\uDD1E" for extended unicode
>     codepoints.  A one-pass parser must somehow integrate this into
>     the flow of zone file parsing.  The easiest way is to simply
>     disable all RFC1035-style escapes and line-breaks for the duration
>     of the SvcParamValue, but this is a major breach of standard zone
>     file practice, and raises questions about how to store UTF-16
>     characters in a zone file. Alternatively, we could somehow combine
>     both RFC1035 and JSON escaping, but if this is even possible, it
>     would seem to require writing a new RFC1035+JSON hybrid parser.  I
>     also think these behaviors would be confusing to users, who would
>     have to try to understand how this new integrated escaping works
>     in order to author zone files containing either kind of escape.
>
>
> [snip]
>
> Let me ask what is probably a really leading question, in terms of the 
> semantics for SVCB (and HTTPS).
> If I understand the draft in its current form, the goal is to be able 
> to encode and parse some DNS RRset in such a way as it lets you 
> obtain, in one fell swoop (but possibly multiple passes for parsing) 
> everything needed to obtain:
> - A well-ordered list of one or more targets, where each target has a 
> set of attributes.
> - The examples currently show RRsets with multiple distinct Priority 
> values
> - However, the words indicate that it is permissible for two RRs in 
> the set to have the same Priority value.
> - The effect is having an array of objects, each of which has a 
> priority, name, and optional set of key/value pairs (where values can 
> be lists).
>
> So, I have a proposed solution that will make the parsing, and 
> generation of post-parsing JSON objects as close to trivial as possible.
> This borrows heavily from what Joe Abley already wrote. I'm just 
> taking the concept to its (il)logical conclusion.
>
> 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..."
>
>
> I think this is likely a lot easier to parse, and to convert into 
> whatever form your ALPN-handling stuff wants (including JSON).
> I is also very close to trivial to write a JSON -> Zone File 
> transliterator, so user input in JSON (which meets the JSON structure 
> expected) can be handled, and even bidirectionally allow Zone File -> 
> JSON for user editing of already-existent entries.
>
> For the example above;
> If the priority of both of the above were the same, they would be all 
> "1 1 ..." and "1 2 ..." instead of "1 1 ..." and "2 2 ...".
> If my JSON isn't horribly bad, I think this would get converted into:
>  [ { "name" : "h3pool", "priority" : 1, "SvcParams" : { "alpn" : 
> "h2,h3", "ech" : "123..." } }, ...]
>
> IMNSHO, it'll be faster to discard any existing parsing code, and 
> embrace this as the Zone File format (and wire format) going forward.
>
> Hope this is helpful to the discussion.
>
> Brian
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop