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

Mark Nottingham <> Tue, 23 June 2020 05:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54A543A177C for <>; Mon, 22 Jun 2020 22:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=GYVsxldf; dkim=pass (2048-bit key) header.b=GC3zgcbX
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4CncRtT3uhmR for <>; Mon, 22 Jun 2020 22:48:00 -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 2BF023A173E for <>; Mon, 22 Jun 2020 22:47:59 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jnbk0-0006iw-KL for; Tue, 23 Jun 2020 05:45:04 +0000
Resent-Date: Tue, 23 Jun 2020 05:45:04 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jnbjx-0006i9-P3 for; Tue, 23 Jun 2020 05:45:01 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jnbjv-0002ix-JZ for; Tue, 23 Jun 2020 05:45:01 +0000
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 68F735C03FE; Tue, 23 Jun 2020 01:44:44 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Tue, 23 Jun 2020 01:44:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=a V//8tIZQghr8M/C9TX2f93XYw6sRt8UiiXrYbf1AG0=; b=GYVsxldft1hN2hwD/ grAexWPq9GckGB6rlhmqiobiVM6VbqcSYTV9A7IcmznUNQ+OPs6fzMvsKNK/5ruh JWEzFCkUN8lms2D2qYibc0lvNRa9xvRchZutJP6DDoxTXr+gl4QZta5rI8m0NIbF 1tYLVl6XzgwWhA3MYEQcSPuwtFV6/qR1/JbZiLJUGnxBw+3yHu5xY1guiyL7GInj /ECC4tY7s4oU21SaE8tjmjmlxG+ux7gz/7yMfXBI046e8RVTT/UF55gkNvHmxBNZ zC/MVBsE1htaAhNW3xl3/PHVccXlve8K+Fz3sugDCi3JalxJ+FRG0mQqND1svqjA xGg2A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=aV//8tIZQghr8M/C9TX2f93XYw6sRt8UiiXrYbf1A G0=; b=GC3zgcbXoc9QksS+bQpWxSJC0ey+9OhbBkXTnnUlS1QwWbhxiZD3gW4K7 fJzBCMn5ABMky1fvZ3nQaCvn49O/HodwQqU1vmRkDyvfPToaL0csCH589Ug9xxBh +xcd16AkVwg8EbC1aW64TuNqaOg7t2/joztEWoJGLmh0o2InwaMntW5/GtaeDq0d RGfQFLhr9qSx8+udq3yL0XqfE64z2Ei0Bos1hHzZ5ed3yExjHrSu7dexHWPHgsLs FNGfVcsi3R+zB/iaqv+9YaAD7otukT2KAIZ8zPpfnWorZemaH1UrPDhGDJv8qVwq KDj28FfMnU3fTPBw/uGjoogHO5hCA==
X-ME-Sender: <xms:xpbxXi9sBk8a0f2qHcdhkeTUaUVy3O1whImuK5x6rYFDt5dA1XGVtg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekfedgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeegteffteeigffhheffvdehtdfgheetgffgvedtgffghffgfeekffelffduueeu ueenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhivghtfhdrohhrghenucfkphepud duledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:xpbxXitmODAxB5-4cxjp6pUjJ5Ti6LK5_9uOLwOeEWlorqhHsXlrHw> <xmx:xpbxXoB60qT71f4xZM1G3l7tW7E904pnJ4bqpoyjwYNskmHCPTMCFw> <xmx:xpbxXqeUkHrI_cRR7DpAo_EeycCxDbLdjieH9-V1mA-D-wXPvRIv1g> <xmx:zJbxXsrh0zPnsDkUsEK2h101sv3p9M_Ve7NuXwfO32D4LMmc79RGuA>
Received: from ( []) by (Postfix) with ESMTPA id 4A6213280059; Tue, 23 Jun 2020 01:44:35 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Tue, 23 Jun 2020 15:44:33 +1000
Cc: " Group" <>, Mike Bishop <>, "Ben Brown (" <>, tjw ietf <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Erik Nygren <>
X-Mailer: Apple Mail (2.3608.
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-9.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1jnbjv-0002ix-JZ 267a2cf67f74bec7a448349cea1a9370
Subject: Re: nearing completion for HTTPS RR type (and SVCB RR type)
Archived-At: <>
X-Mailing-List: <> archive/latest/37811
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Erik,

Thanks for that. Reading through the document for the first time in a while, a few questions pop to mind:

* For those who haven't been following, can you explain why it was thought best to decouple form Alt-Svc?

* The introduction talks about SVCB 'provid[ing] clients with complete instructions for access to an origin.' 'origin' is a Web-specific term; is there a more neutral term you can use to distinguish it from HTTPS? I see in Terminology that you justify this for alignment with Alt-Svc, but that seems to assume that other protocols will have an origin concept -- in particular, a scheme (I'm not against aligning all potential protocols to this model, just a bit surprised that it's got this far).

* That brings to mind the SRV framework; is there any attempt to relate the SVCB framework to it -- especially since this appears to embed the ALPN view of the world? I'm sure some will want to know...

* Did you consider publishing these as two separate documents? That might make the layering more clear.

* Do we have statements of support for the delegation use cases from client implementers? This was a key purpose for Alt-Svc, but it wasn't implemented by clients widely.

* Section 7.5 gives the HTTPS record effective HSTS semantics. Has there been engagement with / review from the security community on this? In particular:
  * Are the presumably shorter DNS TTLs suitable for HSTS use cases?
  * Are there any other fixes / enhancements to HSTS that we want to layer in?


> On 18 Jun 2020, at 12:48 pm, Erik Nygren <> wrote:
> 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 (DNS SVCB and HTTPS RRs)
> Document date:  2020-06-12
> Group:          dnsop
> Pages:          39
> URL:  
> Status:
> Htmlized:
> Htmlized: a "mandatory" key rangesvcb-https
> Abstract:
>    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

Mark Nottingham