[DNSOP] AD Review of: draft-ietf-dnsop-svcb-https

Warren Kumari <warren@kumari.net> Tue, 27 July 2021 16:35 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 113A83A0914 for <dnsop@ietfa.amsl.com>; Tue, 27 Jul 2021 09:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cZMxkA99BY3Y for <dnsop@ietfa.amsl.com>; Tue, 27 Jul 2021 09:35:12 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 7C2B33A08EA for <dnsop@ietf.org>; Tue, 27 Jul 2021 09:35:11 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id l4so16692383ljq.4 for <dnsop@ietf.org>; Tue, 27 Jul 2021 09:35:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=uQ08e5QdjPMxPfcFK6NNwC7tMLzjP12L+Ln2AWiwIIo=; b=V9VAv0RZ9srjGXI1CBoTHndv/eT47PmbBXIQkB/B+eh8aq7Yor+YQ9OCfcilRG9vDY IgzrX0xRMe2+IBWof6jy6caHYJbhvmhkh0j3w3tF4DaDTAYIyEY1FQUHKhu3/tB/lR+u yugquNVHv+ZCqTE6tW+sx8phStp5gQwEpu6O3Lqgxuctsvf6BHhxcUYIl1dwIBVWOqoZ qQtyAxmYZfHRr81lx/q36rls1cbm7KRGHMAiuOE3cRB0HXFYKMtFU4v1/r7jK9gL/+// tQN0+3RSr9hvUt9SQxjiPE+rR6nxpyc4YTjoa07Vh1t9toEIPWKwuVxwfZ4HiY3nFLU8 HBQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uQ08e5QdjPMxPfcFK6NNwC7tMLzjP12L+Ln2AWiwIIo=; b=kV07xUWHfafQNWckBI4VhIsRKJ8posxCQYfb1Vn+82tcJrs+Nmol1wFHwdnsVLnPe6 fIeC0oWx85cIHRE3iM3rcVgcwSjiUdj0rk8uzfqKXikprwUwNGk9IfEdIPBQq5++EI3g uyoUvy28tegd30s6+PVcubuN/xU0MgQfZbFKZOTWIOjMVMbm8esYGTiKBtghNMD7haH6 yR7vXRkq0+kqqPpAkSgDfiiVCkOjv18sqyyi+rEEkmEu109v65ne7oxLnvekDTboq8l/ GoG9ewwCoH0ASmzxKc0Rbv/XBle2KcxlKa8gWP7J4DeJMFf95Oyyu0EPnz6/XzHFCTHY nFXg==
X-Gm-Message-State: AOAM533FOzqdeccdqIm4D8XrEv0NO3awnzCBugb15NpOv+HkO5pm3urv GkLb+jx1n6ihNJt8YbIjSYbzmu90IyPk2ORsXTgkJhPhaTTdnA==
X-Google-Smtp-Source: ABdhPJzJnFn6nfgxebWfv3AUuAhx2ZqtP4XjZislHISv59uXa3xv2V65CTdJqX9zVX5WE6FAoAqP6VnVAaNc8AuwRWs=
X-Received: by 2002:a05:651c:33a:: with SMTP id b26mr16334351ljp.409.1627403708331; Tue, 27 Jul 2021 09:35:08 -0700 (PDT)
MIME-Version: 1.0
From: Warren Kumari <warren@kumari.net>
Date: Tue, 27 Jul 2021 12:34:31 -0400
Message-ID: <CAHw9_iLPr=EzY0CiMurMQp0QkYk+xoB8TJTgSga3Qejk6yd7VQ@mail.gmail.com>
To: dnsop <dnsop@ietf.org>, draft-ietf-dnsop-svcb-https@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/V6e6movDu9OZEKYUFkDCDV0jMiw>
Subject: [DNSOP] AD Review of: draft-ietf-dnsop-svcb-https
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, 27 Jul 2021 16:35:26 -0000

Dear Authors and WG,

This document made me grumpy.

Pointing out nits and similar in documents is one of the few times
that I get to feel superior, and demonstrate my outstanding missing
comma detection abilities... I feel that I've been robbed of this
opportunity in this document -- I only found 4 (four) issues in 57
pages, for a measly 0.07 errors per page...

While they are just nits, I'd still appreciate it if the authors could
address them and post a new version -- having the document as clean as
possible before starting IETF LC helps things run smoothly.

Please SHOUT LOUDLY once you've had a chance to address these (marked
with [O] [P] notation), and I'll kick off LC.


DNSOP Working Group                                          B. Schwartz
Internet-Draft                                                    Google
Intended status: Standards Track                               M. Bishop
Expires: 18 December 2021                                      E. Nygren
                                                     Akamai Technologies
                                                            16 June 2021

 Service binding and parameter specification via the DNS (DNS SVCB and
                               HTTPS RRs)


   This document specifies the "SVCB" and "HTTPS" DNS resource record
   (RR) types to facilitate the lookup of information needed to make
   connections to network services, such as for HTTPS origins.  SVCB
   records allow a service to be provided from multiple alternative
   endpoints, each with associated parameters (such as transport
   protocol configuration and keys for encrypting the TLS ClientHello).
   They also enable aliasing of apex domains, which is not possible with
   CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
   origins.  By providing more information to the client before it
   attempts to establish a connection, these records offer potential
   benefits to both performance and privacy.

1.  Introduction

   The SVCB ("Service Binding") and HTTPS RRs provide clients with
   complete instructions for access to a service.  This information
   enables improved performance and privacy by avoiding transient
   connections to a sub-optimal default server, negotiating a preferred
   protocol, and providing relevant public keys.

   For example, when clients need to make a connection to fetch
   resources associated with an HTTPS URI, they currently resolve only A
   and/or AAAA records for the origin hostname.  This is adequate for
   services that use basic HTTPS (fixed port, no QUIC, no [ECH]).  Going
   beyond basic HTTPS confers privacy, performance, and operational
   advantages, but it requires the client to learn additional

[O] the client to learn
[P] that the client learn
[R] readability/grammar

   information, and it is highly desirable to minimize the number of
   round-trips and lookups required to learn this additional

[O] and it is highly desirable to minimize the number of

   round-trips and lookups required to learn this additional
[R] Can this sentence be split? The "HTTPS confers ..., but ... and it
is highly desirable..." gets a bit confusing unless you already know
this :-)

The SVCB and HTTPS RRs also help when the operator of a service
wishes to delegate operational control to one or more other domains,
e.g. delegating the origin "https://example.com" to a service
operator endpoint at "svc.example.net". While this case can
   sometimes be handled by a CNAME, that does not cover all use-cases.
   CNAME is also inadequate when the service operator needs to provide a
   bound collection of consistent configuration parameters through the
   DNS (such as network location, protocol, and keying information).

   This document first describes the SVCB RR as a general-purpose
   resource record that can be applied directly and efficiently to a
   wide range of services (Section 2).  The HTTPS RR is then defined as
   a special case of SVCB that improves efficiency and convenience for
   use with HTTPS (Section 8) by avoiding the need for an Attrleaf label
   [Attrleaf] (Section 8.1).  Other protocols with similar needs may
   follow the pattern of HTTPS and assign their own SVCB-compatible RR

   All behaviors described as applying to the SVCB RR also apply to the
   HTTPS RR unless explicitly stated otherwise.  Section 8 describes
   additional behaviors specific to the HTTPS RR.  Apart from Section 8
   and introductory examples, much of this document refers only to the
   SVCB RR, but those references should be taken to apply to SVCB,
   HTTPS, and any future SVCB-compatible RR types.

   The SVCB RR has two modes: 1) "AliasMode" simply delegates
   operational control for a resource;

[O] 1) "AliasMode" simply delegates

   operational control for a resource;

[P] 1) "AliasMode", which simply delegates

   operational control for a resource;

[R] grammar/clarity. Suggest the same for #2 below.

 2) "ServiceMode" binds together
   configuration information for a service endpoint.  ServiceMode
   provides additional key=value parameters within each RDATA set.

1.1.  Goals of the SVCB RR

   The goal of the SVCB RR is to allow clients to resolve a single
   additional DNS RR in a way that:

   *  Provides alternative endpoints that are authoritative for the
      service, along with parameters associated with each of these

   *  Does not assume that all alternative endpoints have the same
      parameters or capabilities, or are even operated by the same
      entity.  This is important as DNS does not provide any way to tie

[O] This is important as DNS
[P] This is important, as DNS
[R] grammar

      together multiple RRs for the same name.  For example, if
      www.example.com is a CNAME alias that switches between one of
      three CDNs or hosting environments, successive queries for that
      name may return records that correspond to different environments.

   *  Enables CNAME-like functionality at a zone apex (such as
      "example.com") for participating protocols, and generally enables
      delegation of operational authority for an origin within the DNS
      to an alternate name.

... and I found no more errors or even nits below.


Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky