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

Ben Schwartz <bemasc@google.com> Tue, 11 May 2021 18:12 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 4B2A93A2110 for <dnsop@ietfa.amsl.com>; Tue, 11 May 2021 11:12:22 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 DTX_fZ40-spG for <dnsop@ietfa.amsl.com>; Tue, 11 May 2021 11:12:17 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 3594B3A2112 for <dnsop@ietf.org>; Tue, 11 May 2021 11:12:16 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id h4so21039531wrt.12 for <dnsop@ietf.org>; Tue, 11 May 2021 11:12:16 -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=I1M6DWsDqrUFpFlUwhQO2zjqTfC4pnxszT1BR/XrLL0=; b=Kj9DtMbw2IdUQzlUBChKmyJS60YDJ7rG0xWY40ykWwiktIAjtvtqmb41eKOMwVoAlY 8ViTV/8cTWJ1SShGazTP+pNDRHizty/DtDTZrd1mHCmNrlGZ/KxXma+i78TQMRmn3xPR EpP5NyuKjLgOSuP7G6pXEEPCpip6nP6V6l9WcutvxPo46q0PzGMs3g8foJSLSjOrQ152 iW0l8uT4+3AYiVGSMcqXQae539hcsQa86QT86hj2/L3tW4RERKDvo/AJx8wgqFljDY0H WmgXU2TYGL/Lyzx9RqagQjiTisCRNfEVFe0S8NyJXB8BL5Pdq9LhtAz5eTp+vO1S0rMG nPTQ==
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=I1M6DWsDqrUFpFlUwhQO2zjqTfC4pnxszT1BR/XrLL0=; b=RyA4rh42LbQ+mGGjy9KiBQqdX6QAKfk/BByaP86TfbpUaHXXrs8QKeSATHmdn0xvUp ND0BjFg/P7Dqyr4JH/qLLJ2AWghtg3hGRiDei+W/CquMhtZKkhV5GSk4hbTZS3ADbvR7 WYieqePayEum+WHEsS6JZUUdNHiDup1KUlBAszAQZhDOKODP0602HRlonH3mafUwTuJb XLSqyILQ6d6ys/llXYZaFt32ofZYfm0v771YsPz5lZVASlo8uGE0oaLAh9NtYpJ5sEN+ ls+775KwQrARDnT2B4M7vVPpZETQONcUAEWKi1CU5zQ6/uzUiV+PZTzjdPEemzN2Y0+u zzng==
X-Gm-Message-State: AOAM530nAMffJWd2/VFHtXR2Ns/1Jw10TVQKi8AWh+YQLOAA+RJXOIhb NypOgzVZMvsh8my33/V+iq0X8gjYDD9q+PczvQVcDQ==
X-Google-Smtp-Source: ABdhPJxEjgu9V+ftPcMsZxykwVX4SFPwaT+LAJDsgyVlTb/K/l7GY5EgCN2bQe4K+MeEyaa46R3b3t8xEMrUjBCObns=
X-Received: by 2002:adf:eec4:: with SMTP id a4mr40177504wrp.159.1620756734360; Tue, 11 May 2021 11:12:14 -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> <CAHbrMsD+uiaYQ8i58VRjF=3AtW9uAoAtgbKzNzrPZC3QCmD2pQ@mail.gmail.com> <CAH1iCirykCpqkQEizYUBYMJEXMYRGkWvnzyo-jP=XOT-4fP-EA@mail.gmail.com> <123fd984-a3e1-0d09-b745-9a7ed6260759@nic.cz> <CAHbrMsCrf8GS3N=HF53X-M0oq09yw_vKGFLU_qA6wt94-+vNXg@mail.gmail.com> <07FE2C2B-10C4-47B0-BFF7-AD8E980A2E26@hopcount.ca> <CAHbrMsB6qGs2QsvYMC9j2ahWAR80gdcsDbgihQiXYXG03OY9qQ@mail.gmail.com> <D72B8D52-50F8-457F-B123-D303F4865557@hopcount.ca>
In-Reply-To: <D72B8D52-50F8-457F-B123-D303F4865557@hopcount.ca>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 11 May 2021 11:12:02 -0700
Message-ID: <CAHbrMsDzWjib5zfRpr3hJk4bjXjGAq9Z2pymPoLac9rJZPbWAQ@mail.gmail.com>
To: Joe Abley <jabley@hopcount.ca>
Cc: "libor.peltan" <libor.peltan@nic.cz>, dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000072ade905c211d51c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pta4WWBPO8WbVwsYOfXs8Cjluac>
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 18:12:22 -0000

On Tue, May 11, 2021 at 10:32 AM Joe Abley <jabley@hopcount.ca> wrote:

> On 11 May 2021, at 12:32, Ben Schwartz <bemasc@google.com> wrote:
>
> > On Tue, May 11, 2021 at 9:20 AM Joe Abley <jabley@hopcount.ca> wrote:
> >> On 11 May 2021, at 12:08, Ben Schwartz <bemasc=
> 40google.com@dmarc.ietf.org> wrote:
> >> ..
> >>> * It saves at least 11 bytes of overhead per parameter by avoiding
> repetition of
> >>>   the name, type, class, TTL, and inter-pair binding ID.
> >
> > ... but it inflates response volume in the case where a separate
> SvcParams RRSet is able to be cached significantly longer than the SVCB
> RRSet.
> >
> > It sounds like you're proposing a design in which the information in one
> SVCB record is not just spread across multiple records in an RRSet, but
> actually across multiple RRSets.
>
> Yes, that's what I tried to sketch out before. The SvcParams in an SVCB RR
> becomes a pointer to a second RRSet with a different RRType. So the
> SvcParams information is spread across multiple records in a a different
> RRSet from the SVCB RRRSet. If it's still not clear what I mean, I can try
> again.
>
> Note that I'm not proposing a change to the spec, just illustrating that
> different design choices were possible that avoid the need for delimiters
> or escaping.
>

OK, thanks for helping me understand your thought process.


> While we're on the topic of RRSets and multiple RRTypes, the way that
> AliasMode and ServiceMode are distinguished is also a bit clunky; what are
> the implications of needing to remove all ServiceMode RRs in an RRSet in
> the event that one of them is found to be in AliasMode if we imagine that
> some consumers of these responses will get it wrong?


I think the recipient logic ("if there is an AliasMode record, just use
it") is simple, and not likely to be a source of confusion.  Given that
publishers SHOULD NOT publish mixed-mode RRSets, both sides would have to
be misbehaving for such a bug to be triggered.  If both sides are
noncompliant, presumably the recipient would attempt to connect using one
or more of the ServiceMode records, and succeed if they are usable.  This
doesn't seem problematic to me.  The purpose of this exclusion was mainly
to simplify analysis, avoid inefficient configurations, and maintain
parallelism with CNAME.


> Was there any thought given to an RR schema that prevented such
> ambiguities from being published?
>

This design choice, like many aspects of SVCB, was constrained by latency
and efficiency considerations.  However, note that the ambiguity is
limited: SvcPriority zero sorts to the top, so clients will naturally see
it first.

>  That is not just a variation on SVCB, but an entirely different proposal.
>
> I'm not sure how you think of those two things as different. Isn't every
> variation of something a new something?
>

I think the distinction might be useful as a matter of working group
process.

>>> * It provides a wire format whose structural nesting matches the
> logical scope
> >>>   of each key=value pair, and avoids requiring cross-RR reconstruction
> of
> >>>   bindings by the client.
> >>
> >> This seems like it is documenting a design choice rather than
> explaining it. The decision to include a list of key-value pairs in the
> SVCB RDATA is good because it avoids having to do something different?
> >
> > To restate this sentence, it is good because the concrete syntactical
> structure matches the abstract conceptual structure, and (relatedly)
> because it simplifies client implementation.
>
> What are the concrete syntactical structure and the abstract conceptual
> structures? If those are terms of art I apologise; I'm not familiar with
> them.
>

The concrete wire-format syntax is an octet sequence containing a
TargetName and some SvcParam key-value pairs.

The abstract structure is a "binding" comprising a TargetName and a
key-value map that is associated with that TargetName.

What are you comparing the client implementation to in your final comment?
> What other design option was found to be more complex to implement on the
> client side?
>

I was comparing it to designs where the TargetName and params are separated
into different RRs, or mixed into an RRSet with other bindings.  In such
designs, the client must perform additional work to fetch, associate, or
reconstruct these different components that are encoded or delivered
separately but are only usable as a unit.

I'm sure it feels frustrating to get all these questions at the last
> minute, and I apologise (as I think I said before) that I did not follow
> this work more closely, earlier.
>
>
> Joe
>