Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

Tommy Pauly <> Fri, 27 September 2019 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40948120853 for <>; Fri, 27 Sep 2019 08:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.026
X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 n2v1ekWVwfcl for <>; Fri, 27 Sep 2019 08:00:11 -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 D5034120851 for <>; Fri, 27 Sep 2019 08:00:11 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x8REvE2Q026041; Fri, 27 Sep 2019 08:00:05 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=5itPyvpAn9u5khYP93DMaiWqnsFhs6+Cen+FR76qeJc=; b=Z7H7PsXeVDcTfoEHPQiiQo+vV53tci0l47VstVFDJmUrTmkDG0Hh+M++MiY0egOvisiM YcxkW1BiC8DAl/Qpahi9krb6LjsQ0qhYeRReQ9KNdeQcQzm0xATe+AthNAR+r1nRL4QQ RVcKGPLrT5i+s7Z03BTjD6Ehhd2xQny5F6/XjDPe1fWyJ2ARUdpMMnxPLwh5A83CgobO CIVPn5xhREkCdNgDhpR+tDv+t3QAJZwBWLCV5sa7Uq13T3WmgVPsrNzJeiUCUS5zLuk4 KK1uI5GKqeh3vZf4SkZb5u9x5ODTtrdHf9ayHZBlVQNoteKzTz6wtUF/4ZuSeUEhweiG SQ==
Received: from ( []) by with ESMTP id 2v643nkfd6-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 27 Sep 2019 08:00:05 -0700
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPS id <>; Fri, 27 Sep 2019 08:00:05 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built May 7 2019)) id <>; Fri, 27 Sep 2019 08:00:04 -0700 (PDT)
X-Va-CD: 0
X-Va-ID: 30284d7c-6f2e-4b81-8b2e-7c390b0c439c
X-V-T-CD: cd7fe6dda57047a2c0f8fb4a3a560f60
X-V-E-CD: 31dbcdd2b3b1a4562363c4fa890246d9
X-V-R-CD: 8e38dba737855cf68a2423294120e81e
X-V-CD: 0
X-V-ID: 002da8d9-748a-4088-ac20-1da905901d49
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-09-27_06:,, signatures=0
Received: from [] by (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPSA id <>; Fri, 27 Sep 2019 08:00:03 -0700 (PDT)
From: Tommy Pauly <>
Message-id: <>
Content-type: multipart/alternative; boundary="Apple-Mail=_F8F77607-0B29-4FDE-8792-E321DF3D4B3E"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\))
Date: Fri, 27 Sep 2019 07:59:58 -0700
In-reply-to: <>
Cc: Ben Schwartz <>, Mike Bishop <>, Erik Nygren <>
To: dnsop WG <>
References: <> <>
X-Mailer: Apple Mail (2.3594.4.17)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-27_06:, , signatures=0
Archived-At: <>
Subject: Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
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: Fri, 27 Sep 2019 15:00:16 -0000

> On Sep 24, 2019, at 6:17 AM, Erik Nygren <> wrote:
> Following discussions around the "HTTPSSVC" record proposal in Montreal with the DNSOP, HTTP and TLS WGs, we've updated what was previously "draft-nygren-httpbis-httpssvc-03".  The new version is "draft-nygren-dnsop-svcb-httpssvc-00".   This incorporates much of the feedback from the WG discussions, as well as feedback from discussions with the TLS WG (as we'd like to see this replace the need for a separate ESNI record).
> In particular, it generalizes the record into a new "SVCB" record which doesn't have any protocol-specific semantics.  It also defines an "HTTPSSVC" record that is compatible with SVCB (sharing a wire-format and parameter registry) and which defines the HTTP(S)-specific semantics such as bindings to Alt-Svc.  Other protocols can either define bindings directly to SVCB or can define their own RR Type (which should only ever be needed if there is a need to use the record at a zone apex).
> We'd like to see this adopted by the DNSOP WG.  Until then, issues and PRs can go against: <>
> Major changes from "draft-nygren-httpbis-httpssvc-03" include:
> * Separation into the SVCB and HTTPSSVC RR Types  (and separated all of the HTTPS-specific functionality and text to its own portion of the document).
> * Elimination of the SvcRecordType field (and making the SvcRecordType implicit)
> * Changing the wire format of parameters from being in Alt-Svc text format to a more general binary key/value pair format (with a mapping to Alt-Svc for HTTPSSVC).
> * Adding optional "ipv4hint" and "ipv6hint" parameters.
> * Quite a few cleanups and clarifications based on input (and we undoubtedly have more left to go)
> This retains support for all of the use-cases that the previous HTTPSSVC record had (such as for covering the ANAME / CNAME-at-the-zone-apex use-case).
> Feedback is most welcome.  If the TLS WG is going to use this instead of a separate ESNI record, there is a desire to make progress on this fairy quickly.

I wanted to express support for getting this work adopted in DNSOP, and ideally doing so relatively soon so that we can unblock work on ESNI. From an OS implementor perspective, I'd really prefer to have an RR type that can be used for ESNI defined from DNSOP, and done so in a way (as this proposal does) that can be expanded to include other information like Alt-Svc, and even properties like support for DoH, etc.

I'd also ask that if this work is adopted, an early IANA allocation be made for the RR type once the basic record content and format is agreed upon.

Thanks to the authors for their work on this solution!


>        Erik
> ---------- Forwarded message ---------
> From: < <>>
> Date: Mon, Sep 23, 2019 at 7:01 PM
> Subject: New Version Notification for draft-nygren-dnsop-svcb-httpssvc-00.txt
> To: Mike Bishop < <>>, Erik Nygren < <>>, Benjamin Schwartz < <>>
> A new version of I-D, draft-nygren-dnsop-svcb-httpssvc-00.txt
> has been successfully submitted by Benjamin Schwartz and posted to the
> IETF repository.
> Name:           draft-nygren-dnsop-svcb-httpssvc
> Revision:       00
> Title:          Service binding and parameter specification via the DNS (DNS SVCB and HTTPSSVC)
> Document date:  2019-09-22
> Group:          Individual Submission
> Pages:          33
> URL:   <>
> Status: <>
> Htmlized: <>
> Htmlized: <>
> 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 keying material for encrypting TLS SNI).  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".
> 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
> _______________________________________________
> DNSOP mailing list