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

Ben Schwartz <> Mon, 16 November 2020 06:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E21FC3A1434 for <>; Sun, 15 Nov 2020 22:44:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XzneuWEzKgJk for <>; Sun, 15 Nov 2020 22:44:02 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA6CE3A1431 for <>; Sun, 15 Nov 2020 22:44:01 -0800 (PST)
Received: by with SMTP id r12so16224841iot.4 for <>; Sun, 15 Nov 2020 22:44:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zkV8mDkfmVfTXgxz4ro9JGnxg7ve4wtZtWjYaaEGnbw=; b=H4vSBEgIF3rNSsk0xZT6C96fvYGcDLGKB0dE0YoqV14G7YK5X+XeG/C+X2aIdXuNOA J9K0BLyojc8JhlU8ksIl7TpZ5iEiFee6y+mnmLj/uyZeYCftQrrNmYGwrJM71N/tyubM Wfa37Sp0GkX/JuH+kWqKxcVlOVjFW1gaVmp3yAoo+rxzSa7ZyfG3PlaDVAMD1XH7HGjP 1lUZkKSaXbJ3PXdsaFhS3Fz6HWp4wIZdG3eEAD5ezjLRwqNDZ3QGYTFK6iO9u3/6C6je VjRYlW57xdaU8+gk1HghcR/TYu2HF6FEIVaF4fnHVQk03+6Qu95aYF38QCKZHlh5gTqh umLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zkV8mDkfmVfTXgxz4ro9JGnxg7ve4wtZtWjYaaEGnbw=; b=Q7vCllOwZ+48zqEIxV3dCBOohnr+1IluwNyXR27ONRhE4rhjme4ZFVJxpStRFN8Dnd ecZHObnMizre6QF+93fA3S8muQVDwHRNqzO3WPqTrR6Mp29ERQNtdvbNf3HOYUyi6tCo JQwalCDd7vd7APq+lzWqzjYiETYR5OUSXAzxFAcGVpZ3d2BqI+9I1pxxjllOVPUdDtTa HENOjFS/bsoehGW+3Ti9qXepDVr80cPLz8UohVAwcvIZHaXGn1DbBLi9/FPmEauxHBDl yHZwJPT0ih6dhmGCxxKK+E7UPpkRUZt8y1BVqNevWFLLAj+XaveKTQ34QIRsjD0KuvJB 51yw==
X-Gm-Message-State: AOAM532iahh7A2UtAfI8HrZLjm0UNIO1cvtnpxNCbZAJub1Cr7zL9xSc 42avZYNQk3+ZkwG1hSlIavIHqjoacT9gUCw8cpdIhY7BbFWDyg==
X-Google-Smtp-Source: ABdhPJzRgKNw3ukyQ+MF6R7EsQZ2ZAWGKo8Os9VM1F3TQ+hZJ/T+zxvhqeb1ZSTKhxtisat8A5WYALZk4u0An78ojyA=
X-Received: by 2002:a05:6638:451:: with SMTP id r17mr9982920jap.8.1605509040789; Sun, 15 Nov 2020 22:44:00 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Mon, 16 Nov 2020 01:43:49 -0500
Message-ID: <>
To: dnsop <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="00000000000015ce9205b433b4e9"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Nov 2020 06:44:04 -0000

For those who haven't looked at the diff, here are the changes since -01
      *  Added a Privacy Considerations section
      *  Adjusted resolution fallback description
      *  Clarified status of SvcParams in AliasMode
      *  Improved advice on zone structuring and use with Alt-Svc
      *  Improved examples, including a new Multi-CDN example
      *  Reorganized text on value-list parsing and SvcPriority
      *  Improved phrasing and other editorial improvements throughout

Notably, the normative changes are extremely limited compared to the
previous draft.  This reflects the authors' view that this draft is
stabilizing and should be ready for WGLC soon.

Perhaps more important than the changes that were made are the changes that
were discussed but have not been made:
* We had an extensive discussion regarding the meaning of TargetName = ".",
which is currently shorthand for the owner name.  Some suggested augmenting
this to mean "owner name minus underscore prefix labels", and others
suggested removing this special-case entirely.  (
* We received a suggestion to ban fallback to non-SVCB connection
establishment (  (We
clarified the fallback text but did not change the recommendation.)
* The escaping of ALPNs that contain commas continues to be contentious.
We received a suggestion to remove support for such ALPNs (

In each case, we think that the draft's current text still reflects the
group's consensus and strikes the right balance.  If you disagree, please
open a thread on the dnsop list and we will discuss it.

We have one open issue that seems likely to result in a text change (  This is a fine point
regarding the HTTPS user experience if TLS fails, and we are soliciting
input from experts on those topics.

On Mon, Nov 2, 2020 at 4:44 PM <> 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
>         Title           : Service binding and parameter specification via
> the DNS (DNS SVCB and HTTPS RRs)
>         Authors         : Ben Schwartz
>                           Mike Bishop
>                           Erik Nygren
>         Filename        : draft-ietf-dnsop-svcb-https-02.txt
>         Pages           : 45
>         Date            : 2020-11-02
> 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.
>    TO BE REMOVED: This document is being collaborated on in Github at:
> [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:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> DNSOP mailing list