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

Ben Schwartz <bemasc@google.com> Thu, 13 May 2021 17:50 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 7FAF43A1786 for <dnsop@ietfa.amsl.com>; Thu, 13 May 2021 10:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 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, 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 vRmbjUTo-31F for <dnsop@ietfa.amsl.com>; Thu, 13 May 2021 10:50:20 -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 9BBC63A177E for <dnsop@ietf.org>; Thu, 13 May 2021 10:50:19 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id u133so3566505wmg.1 for <dnsop@ietf.org>; Thu, 13 May 2021 10:50:19 -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=okyxZW+r2kUz8OVt7EkAmggE22Z7RIDo4fm+kj6WcQ8=; b=TIIHtOD93+CAfGQHcKEkqs8UwkKLWv4TADKOsMH3vAN/nDVHcjYY6MsyKw5EvZoWvR vQ5g7qYc9No+9CmjvVUW4AvKZ6YUMOV9gJDnJPuibx7Fs/MFRDjcka+mqWdkDIn5P8jK osdiCsG5pKpOtnN0EA0A10jA36Utynta1+kZXkMhh7T03qIXacjvlZACLA4rE0cwZSA/ mo3tpgrpK/Tssn9dP5z4O8qNAC2SxobKlg+49BnoM7jTv2ihDrhuQn+zZmPSgwI3E9wd xOzyGoO70hAo8AKZncjN13KGM99tgO4pOGtK1T31Shntl/px8j+zny/QBvgH8a4g8IPO HHUg==
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=okyxZW+r2kUz8OVt7EkAmggE22Z7RIDo4fm+kj6WcQ8=; b=QxCXDMbMqRnntF9a+ChpnHxH5XDdccjbHLut+i5wQDeA1aQB6mo2EvpbnGkMPw8OYR gL4y7tlm7zVgx21oMCOI1SYWno65dMqdV6cQ80uplvgtxlp30yucbcEMDFWzdA3eUl05 9hUxfcVFeycxKvao4gCTMdQ2bLn7RzNhSNM6ZMtm97z2rW31VjjsPlCvu9dQl96a1uFs SAsWSSsuL9P6gEai4Ed4GnGTpgrKQcaK6eCo/LHbkC6WuNWAfobmMGEHdaHUTZSyen3W m7ZcYIStj+eRRDEKMeAr5M7gyEv53zAvAJmvzdUZvSFjlY8CuQjEbjcll2Akmd+4ve9C YRaw==
X-Gm-Message-State: AOAM533SZvMwZhdsCTThAt9MYzZPM9aUP0symWLI3aCZRbFzRwBOZuOG 59vGeYU/NVZKhC/jiI0jRO/KDEzCpUT2WotsufdXmA==
X-Google-Smtp-Source: ABdhPJw9AytXzfwdCLOE44hYy7PVSRjDLt6cALsVQUAJPEe+JAjQKALJn2UTuo5+//qxHCOBmtxg1ergDkQ6Jig7GJg=
X-Received: by 2002:a05:600c:3388:: with SMTP id o8mr4876632wmp.101.1620928217106; Thu, 13 May 2021 10:50:17 -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> <73e99492-7cde-37aa-d189-b56c94ca7289@nic.cz>
In-Reply-To: <73e99492-7cde-37aa-d189-b56c94ca7289@nic.cz>
From: Ben Schwartz <bemasc@google.com>
Date: Thu, 13 May 2021 10:50:04 -0700
Message-ID: <CAHbrMsAruP6_dcD-cHng39mqTqBMjJ6NRfevpUzMRmXLqjgUbw@mail.gmail.com>
To: "libor.peltan" <libor.peltan@nic.cz>
Cc: Brian Dickson <brian.peter.dickson@gmail.com>, dnsop <dnsop@ietf.org>, John Levine <johnl@taugh.com>, Joe Abley <jabley@hopcount.ca>, Eric Orth <ericorth@google.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000009c66e505c239c218"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/u7cknRlT7ftUnKB1jw_VdBK0QGs>
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, 13 May 2021 17:50:25 -0000

On Thu, May 13, 2021 at 3:56 AM libor.peltan <libor.peltan@nic.cz> wrote:

> Hi all,
>
> just my comment:
>
> Perhaps complexity is subjective.  The important thing is that the
> standard be reasonably implementable.  I hope that the list of published
> implementations [3] will serve as convincing evidence that the current
> draft is sufficient in that regard.
>
> --Ben
>
> I agree that complexity is subjective. I have no problem implementing
> complex procedures. But more complexity means more probability for bugs
> (and even security issues).
>
> Currently, the authoritative server (while transforming presentation to
> wire format), MUST:
>
>  - sort the SvcParams by key
>  - verify their uniqueness
>  - deal with list of fields nested in other fields (this includes the
> discussed comma escaping)
>
> and the client MUST:
>
>  - verify that SvcParams are sorted and unique
>  - deal with list of fields nested in other fields (at least that various
> "lengths" match)
>
> In the concurrent proposal, the sorting and deduplication will be "for
> free", because DNS ensures this,
>
DNS only ensures that each entire record appears only once, which is
different from the current draft's requirement that each key appear only
once (to form a map).

> and each RData would consist on just one list of values, much easier to
> handle.
>
I'm not sure I understand.  Are you proposing that each record contains a
single value, or each record contains multiple values?  If the former, note
that you have a "set" of values, not a "list"; order is not preserved.  Any
value type that is actually an ordered list will have to complicate its
value format in order to express the ordering.  If you mean for each record
to contain multiple values, then you either have multiple layers of
redundant multiplicity (sets of lists), or you require that clients
validate the RRSet to ensure there are no duplicate keys.  Either way, you
have to consider who is responsible for preventing multiple values for
single-valued parameters, whereas in the current draft, this is essentially
inexpressible.

> On the other hand, the client would have to group several RData (already
> sorted) to get all info, and believe they're all there (as Brian pointed
> out, it has to anyway). And it would cost more bandwith due to DNS overhead
> -- repeated TTLs etc (thanks Ben and Vladimir for the lesson).
>
> Have I summarized the pros/cons of both approaches well enough?
>
I would also add the considerations for humans who are reading or writing
zone files.  Can they see bindings as a unit, with confidence?  Is the
syntax familiar and self-explanatory?  Is it excessively verbose?  Are
typos likely to be caught early, with helpful error messages?