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

Tommy Pauly <> Tue, 23 June 2020 23:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEEF03A0C71 for <>; Tue, 23 Jun 2020 16:44:27 -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 bG8e6daugzH1 for <>; Tue, 23 Jun 2020 16:44:25 -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 02FCC3A0C6F for <>; Tue, 23 Jun 2020 16:44:24 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jnsXI-00009E-Kh for; Tue, 23 Jun 2020 23:41:04 +0000
Resent-Date: Tue, 23 Jun 2020 23:41: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 1jnsXH-00008B-BB for; Tue, 23 Jun 2020 23:41:03 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jnsXE-0007GU-Rp for; Tue, 23 Jun 2020 23:41:03 +0000
Received: from pps.filterd ( []) by ( with SMTP id 05NNW9Gf043427; Tue, 23 Jun 2020 16:40:39 -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=/Eh1y7zgz+YrHsAwosjlwakTbrkSHcmwyCMo5hUdaW4=; b=NuBRvNn+QUjBH2lhDSwC7wEyHA5IT2sn6imWAJ2GJCQ9JTPodT3T7QTuq8CNgEuPSalg 9gmcpmcdW5XEuLwj2ych5oDvf4H3D8e9YKriUT60X/3TfWf2wsUpjZ3vhosvFTscC8G1 nkbQ/Ixgz/fkLKulns9vilIPzGEAZpDC5yMRFOhwzC6Jhii272UcEMi0NAMkiSA6KGrC vzFFERKlX+HBD0COgh/8ULUBFRdV5Okbot/TFlUjoO7MXbYi3h+u1VbGKftTQJlkHTxj D35y8pJviNxRkgBzzSixw3jyVcsdm+5YWKcVmFzoB9ITiq+AA8tEcl4OZVwM8oY9jtY/ sw==
Received: from ( []) by with ESMTP id 31utsb8w1j-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Jun 2020 16:40:38 -0700
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) with ESMTPS id <>; Tue, 23 Jun 2020 16:40:38 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) id <>; Tue, 23 Jun 2020 16:40:38 -0700 (PDT)
X-Va-T-CD: 975b0093eb44fd3855a2b0f880d76e27
X-Va-E-CD: fc2df81a96ce51f283ed9af973944ac1
X-Va-R-CD: 593950aa21a88befd2c383c1b2bcc079
X-Va-CD: 0
X-Va-ID: 8056d28e-f947-4216-8519-a3deff1b111f
X-V-T-CD: 975b0093eb44fd3855a2b0f880d76e27
X-V-E-CD: fc2df81a96ce51f283ed9af973944ac1
X-V-R-CD: 593950aa21a88befd2c383c1b2bcc079
X-V-CD: 0
X-V-ID: 0747fc13-4041-4f2e-a8d7-47a645d960ca
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.687 definitions=2020-06-23_14: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 16:40:38 -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 16:40:37 -0700
Cc: Martin Thomson <>,
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <> <> <> <> <>
To: Mark Andrews <>
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_14: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: 1jnsXE-0007GU-Rp 1e957568a6f4d7f752f43850f35b6ee4
Subject: Re: nearing completion for HTTPS RR type (and SVCB RR type)
Archived-At: <>
X-Mailing-List: <> archive/latest/37817
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Yes, there have already been lots of tests with the private BIND values! I’ve built and tested an implementation using that.

I think we’re ready at this point to do tests that are more than experiments, but larger deployment tests that are using the stable types.


> On Jun 23, 2020, at 4:38 PM, Mark Andrews <> wrote:
> One doesn’t need an early allocation for interop testing.  Just pick 2 private type values.  BIND uses SVBC/65481 and HTTPS/65482 which matches what dnspython is doing for their testing.  If the record format changes pick 2 new private values and discard the old ones.  Use “TBA (use 65XXXX for pre allocation testing)” in the draft so everyone is in sync with a particular WIRE FORMAT.  The final allocation can be made by IANA when the document is with the RFC editor.
> I’ve done this a number of times with multiple RR types.
>> On 24 Jun 2020, at 00:29, Tommy Pauly <> wrote:
>> 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.
>> Tommy
>>> 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
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: