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

Mark Andrews <> Mon, 10 May 2021 22:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DF823A2D00 for <>; Mon, 10 May 2021 15:14:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=FMB2emzG; dkim=pass (1024-bit key) header.b=iq+ujKMp
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1rfSiJAA-xtZ for <>; Mon, 10 May 2021 15:14:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 76FAB3A2D02 for <>; Mon, 10 May 2021 15:14:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPS id 92C5E3AB023; Mon, 10 May 2021 22:14:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=ostpay; t=1620684842; bh=35m0RjrEreYKT472QC5bWYlljJgicZiVKwms1XISufs=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=FMB2emzGtIgc6VblYj4xOcvFiU7fzf0gVXt48Ts8i41bJDw5JdW7TAmm9du/aJmUz hwZCpLdwdG7QR6PjuFDpj0e+1biA/0yXB4pxDDSYJ454hiDj+mhQEJK5Bf2cI4xsYP 0O9R0SK1//LP/gp0Txy/i/9ldfp+g8JrEgigMPPI=
Received: from (localhost.localdomain []) by (Postfix) with ESMTPS id 813B316009C; Mon, 10 May 2021 22:14:02 +0000 (UTC)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 5DFF216009A; Mon, 10 May 2021 22:14:02 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 5DFF216009A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1620684842; bh=pSuI3TbNf1AoQej8O9SUXTMRaLFy/sFazRMd4oCglqc=; h=Content-Type:Mime-Version:Subject:From:Date: Content-Transfer-Encoding:Message-Id:To; b=iq+ujKMpzkvBRHtScOQXwr4d/wtBnTPuFYm0o1UPTviGgxuk7S0sdSmsiOCPUrZ9F NV2meF5D362BN1+/eaq6BlAIsRnomp7g7CfAeTyuNn6d/lKq9L6muSUrDUnT4c3ngx R4VOViOxM+kiM8uLkFyqNApSwXXg8P32ULEWN/lM=
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id ZWSL6Xju672Z; Mon, 10 May 2021 22:14:02 +0000 (UTC)
Received: from [] ( []) by (Postfix) with ESMTPSA id 37EFF16008B; Mon, 10 May 2021 22:14:01 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Mark Andrews <>
In-Reply-To: <>
Date: Tue, 11 May 2021 08:13:58 +1000
Cc: Joe Abley <>, dnsop <>, Pieter Lexis <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Ben Schwartz <>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 May 2021 22:14:10 -0000

> On 11 May 2021, at 02:56, Ben Schwartz <> 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.  It would also require a dramatic rewrite of a specification that is now widely deployed.
> As for the question of commas, I continue to believe that the current text is preferable.  I believe that the behavior Dick is advocating for is in fact the one that was present in the draft until -02 [1], changed here [2].  We changed this text after receiving complaints from WG members that the algorithm as specified was too complicated, along with my own experiences attempting to implement it in multiple codebases that apply char-string decoding during or before tokenization.
> The key question is: how is the zone file parsing supposed to work?  I see two main options:
> One-pass (draft-02):
> 1. Read the key name up to an "="
> 2. Load a parser whose behavior depends on the key name
> 3. Feed this parser characters from the zone file until it declares completion or error
> Two-pass (more recent drafts):
> 1. Read the key name up to an "="
> 2. Parse the value as a char-string
> 3. Pass the char-string parser output to the a key-specific parser for deeper processing
> In one-pass parsing, comma-separated value (CSV) lists are like dot-separated domain names: first-class entities whose delimiter escaping is fully integrated into the parsing.  In two-pass parsing, CSV format is an implementation detail of particular SvcParam registrations, encoded as data inside plain char-strings in the zone file.
> 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.

Yet you fail to mention that the following

3. Encoding
   JSON text SHALL be encoded in Unicode.  The default encoding is

The UTF-16 JSON strings values are encoded as UTF-8.  UTF-8 in zone files usually ends up being \DDD for non-ASCII and ASCII control octets once it has gone from text -> wire -> text to put everything into ASCII printable.  Zone files are ASCII documents.  If you are using the values in other contexts you may convert the
wire forms differently.

> In two-pass parsing, this is trivial.  One simply parses the value as a char-string, and feeds the output to a JSON parser.  The resulting double-escaping may be unattractive, but is commonplace when working with structured data inside a string.
> Another point in favor of two-pass parsing: it makes unknown keys "value errors" instead of "syntax errors".  In one-pass parsing, when the parser encounters an unrecognized SvcParamKey, it must stop and fail immediately.  It cannot proceed, because it cannot even continue tokenizing.
> [1]
> [2]
> On Mon, May 10, 2021 at 8:35 AM Joe Abley <> wrote:
> Hi Pieter,
> On 10 May 2021, at 11:23, Pieter Lexis <> wrote:
>> You then invite the following issues:
>> Clients need to match the tuple (ownername + prio + target) and get all
>> data from all matched rrsets, whereas now you get all that data in one
>> piece of rdata.
> Inviting that issue is also a potential benefit, but I agree that the implication exists. For example, the ability to publish sets of SvcParams with long TTLs ought to increase the probability of cache hits for that data and reduce SVCB response sizes.
>> A client also can't figure out (if not doing DNSSEC valdiation
>> themselves) if you have received all the SVC data for a certain name.
> A client can't figure out without DNSSEC whether anything they have received is correct in, in general. So setting aside that more general authentication problem, I don't think it's correct to say that a client cannot tell whether they have received a complete RRSet in the answer section of a response. It's either there and complete or it's absent (and perhaps TC=1 if the reason for its absence is message truncation).
> There should be no response possible in an implementation that adheres to the protocol in which a truncated RRSet appears in the answer section. If we're widening the net to implementations that don't follow the rules then I agree anything is possible.
> Joe
> _______________________________________________
> DNSOP mailing list
> _______________________________________________
> DNSOP mailing list

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: