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

Tommy Pauly <> Tue, 23 June 2020 14:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CE5A3A0EFC for <>; Tue, 23 Jun 2020 07:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Status: No, score=-2.75 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, 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)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l_ICo7Pzm3hK for <>; Tue, 23 Jun 2020 07:32:44 -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 148613A0D2E for <>; Tue, 23 Jun 2020 07:32:39 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jnjvm-0001qs-6R for; Tue, 23 Jun 2020 14:29:46 +0000
Resent-Date: Tue, 23 Jun 2020 14:29:46 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jnjvj-0001pv-L5 for; Tue, 23 Jun 2020 14:29:43 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jnjvh-0007tA-PY for; Tue, 23 Jun 2020 14:29:43 +0000
Received: from pps.filterd ( []) by ( with SMTP id 05NELGBH062038; Tue, 23 Jun 2020 07:29:29 -0700
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=20180706; bh=bZoKiAK4EdifXkC4qTl9Ui0xAJHbThGHoUTGCwMErD4=; b=JkwUIvK6qaH/2ComVQ0jo+Y/MfNIqSN7tbUsQymZRn+17eFjQ2fAzbjdWj8eagfnRFpm 9RRh14IiN4vvXUud5XEZYZIoIrunY7/EjV1a+yKCEEuPLCWz62bGnWRLpb86L3JiKD+c SY2FarvpbCsQsLsScg776X/66A7IdA982UKSt324mRBRFjiHYBTF7Sc/HBDCuSBp5C1a EcWGewK+tIICapw4EIecz4zYNh38iS3O7uKtHLtvvUVPaKrAiS532T+Uhe1x+miupUxI bw67/Jznuvu00+AdrY8l9HT9vgz69Zw0seqWUKnrxRo31LY4u6Un6jqYWSZfcKBTYSpd MQ==
Received: from ( []) by with ESMTP id 31uk390g6p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Jun 2020 07:29:29 -0700
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) with ESMTPS id <>; Tue, 23 Jun 2020 07:29:28 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) id <>; Tue, 23 Jun 2020 07:29:28 -0700 (PDT)
X-Va-T-CD: db68f2fc3d76f31b3434a5d04e9dc961
X-Va-E-CD: fc2df81a96ce51f283ed9af973944ac1
X-Va-R-CD: 593950aa21a88befd2c383c1b2bcc079
X-Va-CD: 0
X-Va-ID: 10424948-e9b8-4652-8977-252b035e7bb9
X-V-T-CD: db68f2fc3d76f31b3434a5d04e9dc961
X-V-E-CD: fc2df81a96ce51f283ed9af973944ac1
X-V-R-CD: 593950aa21a88befd2c383c1b2bcc079
X-V-CD: 0
X-V-ID: 4ed7b7fc-7a01-41ba-aca8-edf1cfcb4af5
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.687 definitions=2020-06-23_07:2020-06-23,2020-06-23 signatures=0
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) with ESMTPSA id <>; Tue, 23 Jun 2020 07:29:28 -0700 (PDT)
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Tommy Pauly <>
In-reply-to: <>
Date: Tue, 23 Jun 2020 07:29:26 -0700
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <> <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.3608.
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.687 definitions=2020-06-23_07:2020-06-23,2020-06-23 signatures=0
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1jnjvh-0007tA-PY 52caf41b2bb024875c37b1710ad79f9f
Subject: Re: nearing completion for HTTPS RR type (and SVCB RR type)
Archived-At: <>
X-Mailing-List: <> archive/latest/37815
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Thanks for filing issues on the GitHub, Martin!

Regarding the done-ness and implementations, I agree that this certainly isn’t as mature as QUIC. The key thing at this time is getting the wire format stable enough to do the RR type early allocation, which will enable broader interop and deployment testing. Seeing implementations ship prior to publishing the RFC here is an important step, as you indicate.


> On Jun 23, 2020, at 2:25 AM, Martin Thomson <> wrote:
> Hi Erik,
> Thanks for passing this along.  I think that this is - as you say - almost done, but not perhaps in the same way that QUIC is almost done.  It's pretty good for a -00 draft, but I found a fairly large number of issues in my review.  Those were mostly editorial or quite minor, but it suggests that maybe another round of edits would be good.
> I don't quite see the same decoupling from Alt-Svc that I was expecting based on your note.  I think that the balance there is about right, but I would frame this as a parallel mechanism to Alt-Svc that is deliberately compatible.
> As for implementation, we have plans to implement as a client.  They are not concrete plans, however, so don't ask about dates.  I expect that more feedback will be forthcoming as that happens; if you believe that this can ship before then, then I would hope that you would be able to get some experience with client implementations in lieu of what we can provide.
> I also think that the requirements for recursive resolvers are such that experience with implementation there is similarly necessary.
> On Thu, Jun 18, 2020, at 12:48, 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 
>> < <>>, 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: 
>> <>svcb-https-00 <>
>> Htmlized: 
>> <>Consider a "mandatory" key range <>s <>vcb-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