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

Ben Schwartz <bemasc@google.com> Mon, 10 May 2021 16:56 UTC

Return-Path: <bemasc@google.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 70EC63A23AC for <dnsop@ietfa.amsl.com>; Mon, 10 May 2021 09:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level:
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 jW-VELVwDQwx for <dnsop@ietfa.amsl.com>; Mon, 10 May 2021 09:56:53 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 E6A983A2386 for <dnsop@ietf.org>; Mon, 10 May 2021 09:56:52 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id u5-20020a7bc0450000b02901480e40338bso10028516wmc.1 for <dnsop@ietf.org>; Mon, 10 May 2021 09:56:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HHdCmwmp0PMTZ4dnVZWs+JPsr2fgYPGjj1atAofp/CI=; b=JTtLDYJZe/BiWsVC5LPwRLYV5m8g4OxUo09rWdbnqbaMvFecpmPxKFrBcrZJmwT/wE PAw6Kk/FPOefbn+6D+DfOcA+WwHED4e7qx8tU4Sw9Mp7qRLLOOfoY08FLkbuxUaaWV91 X6ov7DlQBHxajuVUCYY1vJqQY90/R43O0Dnpi7qMT548tUTwzvg7+FduPqWRSyO/c8W8 l3lFqda/E36RHeTPpJBMB4ISKlXjDZefO5g3KkE45AWwcLVxDH/K7oJVZluFZkT3CDgj kJhPcFyKbUeJy4XNjGwrmMBL0QzlVElN7SGogs63ZQhhrcgpuGyRiPt5p2faP6zXQyWy Sn5g==
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=HHdCmwmp0PMTZ4dnVZWs+JPsr2fgYPGjj1atAofp/CI=; b=a6kuuegyCEZq5o38HHVnQkbTIQZvEasVI7xhwFwOVxHbluW18YJuQNFJ/BhB7c9kOC Q3yaGYRrvsOGYo9Bcx8n6J7dKgLY6PMrCzV3NtVwkxjwqDWKBlLLGC354lZNFzrFr+JO sTv1Gs0CcExNLfodrMBYWCNJydKvP9GDo+4bW/TFYB/IBSDkjjsSO/R8WL/CdHeWkThq vZUSKM82oyWwv3+NiHBkFoDJbbFncg0vNzVA3OMbiK/EaFK7h/bgjqC7EpazXUGeW6eD 6lE8eJbxza27fzqmgqp2abXx9USmoryH4fXa9PAr98RknBiBwGsmqoklsLVA1HM+PjpU GL6Q==
X-Gm-Message-State: AOAM531PsVDfWtdRyyxpl6n/5M521xD2TCH/iiwEupUni5l4XD/UQVkR 8k50cbSqhlpeREpffoP4iHeOvnjGI3N8i2JVdqnjcQ==
X-Google-Smtp-Source: ABdhPJzptgd5KOK6/T/QCLBwL7rJ9SmrkrqL8Aqai7A1hOk/nYm+ZnIKbAdP18v6+0o4Cx2qjFTAFojSBPPIHQSHyR4=
X-Received: by 2002:a05:600c:3388:: with SMTP id o8mr63604wmp.101.1620665809389; Mon, 10 May 2021 09:56:49 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <2952D408-117B-40D0-B859-7A8E4111629E@hopcount.ca>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 10 May 2021 09:56:37 -0700
Message-ID: <CAHbrMsD+uiaYQ8i58VRjF=3AtW9uAoAtgbKzNzrPZC3QCmD2pQ@mail.gmail.com>
To: Joe Abley <jabley@hopcount.ca>
Cc: Pieter Lexis <pieter.lexis@powerdns.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000f3c96505c1fca933"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/D4wxu0kdYN1B9YzFRzGz34iapH8>
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: Mon, 10 May 2021 16:57:08 -0000

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.

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]
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-02#appendix-A.1
[2] https://github.com/MikeBishop/dns-alt-svc/pull/282


On Mon, May 10, 2021 at 8:35 AM Joe Abley <jabley@hopcount.ca> wrote:

> Hi Pieter,
>
> On 10 May 2021, at 11:23, Pieter Lexis <pieter.lexis@powerdns.com> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>