[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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. Thanks, W 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) draft-ietf-dnsop-svcb-https-06 Abstract 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 information. [O] and it is highly desirable to minimize the number of round-trips and lookups required to learn this additional information. [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 types. 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 endpoints. * 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. Grump. W -- 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
- [DNSOP] AD Review of: draft-ietf-dnsop-svcb-https Warren Kumari
- Re: [DNSOP] AD Review of: draft-ietf-dnsop-svcb-h… Warren Kumari