Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-httpssvc-03.txt

Ben Schwartz <bemasc@google.com> Fri, 12 June 2020 02:44 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 3FEC03A0E49 for <dnsop@ietfa.amsl.com>; Thu, 11 Jun 2020 19:44:44 -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 G7fD8dYYEOBo for <dnsop@ietfa.amsl.com>; Thu, 11 Jun 2020 19:44:41 -0700 (PDT)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 AA0E13A0E3A for <dnsop@ietf.org>; Thu, 11 Jun 2020 19:44:40 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id j10so8168190wrw.8 for <dnsop@ietf.org>; Thu, 11 Jun 2020 19:44:40 -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=Aidc4qunjdQey5dE3+kG4RKi2jwMiSVAuZqIlW5uEzA=; b=f9ylhCS78s/JVQfMFWL7+wkfRh/zijuDlFDSJ/IY4Djqmk+cz4V1Mi1wPI+evOmsgK R7R6BGufxkZUYltv58OY9csFA8dzMo3Y8vgamUtHTTthkJuEuSpiA1MBcpxvqF9B8vWE uWVGDZkTtijjasIIQerE4ZIYGcnwvMYV0Wav5vzblSL3zAOKVRduryC4Ljdmmo6SD+4M kMjw40vnKPMPrNXCOczbFcrLrGV+zK/F1G1DoQu5Lp+Bn2CW6Ga5FMtyl0PSAps92NRp XdbVBnYS0vf7iwJVY1SYPTPgSsqgurb3gEDHokoEyU1P+HNrI0VLppymA+wXDJrLP6EI s8iQ==
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=Aidc4qunjdQey5dE3+kG4RKi2jwMiSVAuZqIlW5uEzA=; b=Z9yHF7Aedx+bjB0i6BC0YAVlPoLzYUrU7vPyKqVEcJq+np631oqfetaHb0+fRnsMb0 YzxhTQe6A07+yeFkEXA7j0nYLOhAVt1f5XC5ob0UwSPNcOXv6ZYXlxwzm7M2c35Tn2t0 CquekIcQg8dtrbYra2KTq0mqopC9rJJz0sfzpSj+5AE5BCqtR6PMwmD5NcmF/X4ifUBR d9/8SwbMQWTBr+BCama1Mgx5OHXjNdZeP/SgxVb2eQIUiBkuFu3/yfIbsy2ni2A54LdJ r22hKz3B6+n3nR//I70lc+Xtoni/T+nCot13plXd2E3gTdB0bUl5Q+ezLtpm48d2Vg7Q lsqw==
X-Gm-Message-State: AOAM532fzui1eF5MxPBFhmzHC9jx6IQAuIKmoWK+MQCX9O4KLtqUco5r vh32clBhponhWgSELeGsBqNNWmGMq/vrFmHrEbMLRyFI5v/fZw==
X-Google-Smtp-Source: ABdhPJy/Om8tXRr04r1WRokHo0SwlPezGGQSwu3OMRYgO9qiNuDbdaRY/juHfaCd09+RBRGx7k9z3spR+ipdy8e7pRA=
X-Received: by 2002:a5d:4cc4:: with SMTP id c4mr12223799wrt.159.1591929878556; Thu, 11 Jun 2020 19:44:38 -0700 (PDT)
MIME-Version: 1.0
References: <159192870681.31818.12194161917935801436@ietfa.amsl.com>
In-Reply-To: <159192870681.31818.12194161917935801436@ietfa.amsl.com>
From: Ben Schwartz <bemasc@google.com>
Date: Thu, 11 Jun 2020 22:44:27 -0400
Message-ID: <CAHbrMsCMZ49sk+CzuyFL-naRw2nU4XV81zy6HHhqE5a-0Jfc1A@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Cc: i-d-announce@ietf.org
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000f33c2d05a7da0e64"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/oPV0w5TOksyW8CunEwQA64JEZk8>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-httpssvc-03.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: Fri, 12 Jun 2020 02:44:44 -0000

Thank you to the many participants who've written detailed feedback on this
draft over the last few months.  This draft includes a wide variety of
textual updates based on your observations.

There are two significant changes that I think are worth highlighting.
First, the requirements related to chain lengths have been adjusted.
Previously, the relevant text (a placeholder to invite discussion) said

> Chains of consecutive SVCB and CNAME records SHOULD be limited to (8?) ...

Based on the discussions on this list, the text now says

> To avoid unbounded alias chains, clients and recursive resolvers MUST
impose a limit on the total number of SVCB aliases they will follow for
each resolution request. This limit MUST NOT be zero, i.e. implementations
MUST be able to follow at least one AliasForm record. The exact value of
this limit is left to implementations.

Second, the IANA registration rules for SvcParamKeys (i.e. new extensions)
have changed.  Previously, almost all of the 16-bit values were "Expert
Review", except for 256 reserved for Private Use (i.e. experimentation in
closed settings).  In this draft, 32512 values are under Expert Review,
32512 are First-Come-First-Served, 255 are Private Use, and 257 are subject
to Standards Action.  We hope that this will enable more rapid public
experiments without risking key space exhaustion.

On Thu, Jun 11, 2020 at 10:25 PM <internet-drafts@ietf.org> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations WG of the
> IETF.
>
>         Title           : Service binding and parameter specification via
> the DNS (DNS SVCB and HTTPSSVC)
>         Authors         : Ben Schwartz
>                           Mike Bishop
>                           Erik Nygren
>         Filename        : draft-ietf-dnsop-svcb-httpssvc-03.txt
>         Pages           : 39
>         Date            : 2020-06-11
>
> Abstract:
>    This document specifies the "SVCB" and "HTTPSSVC" DNS resource record
>    types to facilitate the lookup of information needed to make
>    connections for origin resources, such as for HTTPS URLs.  SVCB
>    records allow an origin to be served from multiple network locations,
>    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 HTTPSSVC DNS 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.
>
>    TO BE REMOVED: This proposal is inspired by and based on recent DNS
>    usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long
>    standing desires to have SRV or a functional equivalent implemented
>    for HTTP).  These proposals each provide an important function but
>    are potentially incompatible with each other, such as when an origin
>    is load-balanced across multiple hosting providers (multi-CDN).
>    Furthermore, these each add potential cases for adding additional
>    record lookups in addition to AAAA/A lookups.  This design attempts
>    to provide a unified framework that encompasses the key functionality
>    of these proposals, as well as providing some extensibility for
>    addressing similar future challenges.
>
>    TO BE REMOVED: The specific name for this RR type is an open topic
>    for discussion.  "SVCB" and "HTTPSSVC" are meant as placeholders as
>    they are easy to replace.  Other names might include "B", "SRV2",
>    "SVCHTTPS", "HTTPS", and "ALTSVC".
>
>    TO BE REMOVED: This document is being collaborated on in Github at:
>    https://github.com/MikeBishop/dns-alt-svc [1].  The most recent
>    working version of the document, open issues, etc. should all be
>    available there.  The authors (gratefully) accept pull requests.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-httpssvc/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-03
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-httpssvc-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-httpssvc-03
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>