nearing completion for HTTPS RR type (and SVCB RR type)

Erik Nygren <> Thu, 18 June 2020 02:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 269C33A0CA7 for <>; Wed, 17 Jun 2020 19:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j33WfUsRizqL for <>; Wed, 17 Jun 2020 19:52:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4959F3A0CA4 for <>; Wed, 17 Jun 2020 19:52:32 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jlkcC-0007EF-Us for; Thu, 18 Jun 2020 02:49:21 +0000
Resent-Date: Thu, 18 Jun 2020 02:49:20 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jlkc9-0007DP-IA for; Thu, 18 Jun 2020 02:49:17 +0000
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jlkc7-0007hC-5U for; Thu, 18 Jun 2020 02:49:17 +0000
Received: by with SMTP id y78so1460649wmc.0 for <>; Wed, 17 Jun 2020 19:49:14 -0700 (PDT)
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=3vskRBtBRNqnel4I8E9i2hJ8XeCGP/ErUM8T2V/TW0I=; b=N0EJz341ln78bo6/P44Mt1t9h6TjlhLl6BuUMo2zx0WguQbcJPmeAJIaa6dFE0cfY1 2tFc5SdiojaacmCCgJMwUIG4PX9GlBui8zZv9wYd//c6BGZaBl8yX6p9nLasIF3IQyMT hZeGrPiX4sSfb+JWKhK4gOaRHcT61MQcSffNuyrfwnXbi/DgsdTrRR5LLiyyEo1Ii9o9 KD00ato75rZLwvzUdVWuB2SMCDmx+JtEWAmdR6aN/IdLQV2BL/DP6eRlC4GOsj5ToaUb pwaDD2ss22AoSydeQs444DWo+CwTKrqOuNR3mRSXPGUtsafFNQVwJ0gkLaJBd9KrV1WK W/Yw==
X-Gm-Message-State: AOAM532tVKGIeAE9JVLZuIPn8HiYv2TNFWof6yT7dUlHlkYNuHiKWaNx fdpcoI7ACCN9IiqPDMmz8+5QxQLwIiUjRxK8Al0Q7VEq/AI=
X-Google-Smtp-Source: ABdhPJzvEAS4+Iw7fjjFTO9cv6uxT3CQUdaoptlquc/vBOs/LVDrP6mvRFSvI18llM/bXQw09b6gfgybNmothhPE8qI=
X-Received: by 2002:a7b:c186:: with SMTP id y6mr1751181wmi.82.1592448543368; Wed, 17 Jun 2020 19:49:03 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Erik Nygren <>
Date: Wed, 17 Jun 2020 22:48:52 -0400
Message-ID: <>
To: " Group" <>, Mike Bishop <>, "Ben Brown (" <>, tjw ietf <>
Content-Type: multipart/alternative; boundary="000000000000c028ad05a852d161"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Scan-Sig: 1jlkc7-0007hC-5U 7beed9214dbb240f6593a1b24e960cb7
Subject: nearing completion for HTTPS RR type (and SVCB RR type)
Archived-At: <>
X-Mailing-List: <> archive/latest/37785
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

We're hoping to start WGLC in DNSOP sometime in the next month or two
for the HTTPS RR type (formerly "HTTPSSVC", along with SVCB).
We submitted an early code point allocation request for the DNS RR types.
As such, now would be a good time to take another read through.

Remaining issues are tracked here (and can be discussed here,
in dnsop, or in the issue tracker as appropriate):

The most relevant to the HTTP WG are:

* Consider SVCB-Used header
* Parameter to indicate no HSTS-like behavior
* Consider a way to indicate some keys as "mandatory"

Note that the current draft decouples itself fully from Alt-Svc.
That there are a few areas for future improvement to Alt-Svc
that came out of discussion here, but are not covered in the current draft.

The latest authors' draft (for pull requests) is at:

and latest published is at:

Best, Erik

---------- Forwarded message ---------
From: <>
Date: Fri, Jun 12, 2020 at 4:18 PM
Subject: New Version Notification for draft-ietf-dnsop-svcb-https-00.txt
To: Benjamin Schwartz <>om>, Erik Nygren <>rg>,
Mike Bishop <>

A new version of I-D, draft-ietf-dnsop-svcb-https-00.txt
has been successfully submitted by Ben Schwartz and posted to the
IETF repository.

Name:           draft-ietf-dnsop-svcb-https
Revision:       00
Title:          Service binding and parameter specification via the DNS
Document date:  2020-06-12
Group:          dnsop
Pages:          39
a "mandatory" key range

   This document specifies the "SVCB" and "HTTPS" DNS resource record
   (RR) 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 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 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: 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.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

The IETF Secretariat