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

Mark Andrews <marka@isc.org> Fri, 26 June 2020 08:04 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3780C3A11BD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Jun 2020 01:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level:
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uguZoH8zRhy for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Jun 2020 01:04:07 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D030C3A11C2 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 26 Jun 2020 01:04:07 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jojI3-0007wj-Cg for ietf-http-wg-dist@listhub.w3.org; Fri, 26 Jun 2020 08:00:51 +0000
Resent-Date: Fri, 26 Jun 2020 08:00:51 +0000
Resent-Message-Id: <E1jojI3-0007wj-Cg@lyra.w3.org>
Received: from www-data by lyra.w3.org with local (Exim 4.92) (envelope-from <marka@isc.org>) id 1jojHu-0007ty-6W for ietf-http-wg@listhub.w3.org; Fri, 26 Jun 2020 08:00:42 +0000
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <marka@isc.org>) id 1jnspc-0002dm-88 for ietf-http-wg@listhub.w3.org; Wed, 24 Jun 2020 00:00:00 +0000
Received: from mx.pao1.isc.org ([2001:4f8:0:2::2b]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <marka@isc.org>) id 1jnspZ-0007du-Sg for ietf-http-wg@w3.org; Wed, 24 Jun 2020 00:00:00 +0000
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 3DDF83AB002; Tue, 23 Jun 2020 23:59:44 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3013616005A; Tue, 23 Jun 2020 23:59:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1E0B516007D; Tue, 23 Jun 2020 23:59:44 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IPWb880TcQD9; Tue, 23 Jun 2020 23:59:44 +0000 (UTC)
Received: from [172.30.42.68] (unknown [49.2.101.160]) by zmx1.isc.org (Postfix) with ESMTPSA id 220B416005A; Tue, 23 Jun 2020 23:59:42 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <77BDDA62-DEFA-4C91-8D00-4F525F2C20C2@apple.com>
Date: Wed, 24 Jun 2020 09:59:39 +1000
Cc: Martin Thomson <mt@lowentropy.net>, ietf-http-wg@w3.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E3A8D025-A19A-4677-8AD2-2574FD23E7D5@isc.org>
References: <159199313530.13520.7556914670094066150@ietfa.amsl.com> <CAKC-DJgGoPirEoRW=E2qvYnsgx8s7Zyni=YxJEZNLMmTagwNMQ@mail.gmail.com> <00397886-f3b3-4788-b4c9-e64055802131@www.fastmail.com> <EE7C0812-720D-4598-93FC-E641D0888C7A@apple.com> <EB9B59AD-A5C0-4A73-8FF2-1A8413DE6553@isc.org> <77BDDA62-DEFA-4C91-8D00-4F525F2C20C2@apple.com>
To: Tommy Pauly <tpauly@apple.com>
X-Mailer: Apple Mail (2.3445.9.5)
Received-SPF: pass client-ip=2001:4f8:0:2::2b; envelope-from=marka@isc.org; helo=mx.pao1.isc.org
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1jnspZ-0007du-Sg 2ee49247a469795adfab31196474030a
X-caa-id: 1843d4e7a5
X-Original-To: ietf-http-wg@w3.org
Subject: Re: nearing completion for HTTPS RR type (and SVCB RR type)
Archived-At: <https://www.w3.org/mid/E3A8D025-A19A-4677-8AD2-2574FD23E7D5@isc.org>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37831
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Large test deployments can also be done with private values.  Been there, done that.  If the wire format remains stable you just tweak the type code value once it is assigned.  If it doesn’t then you don’t have interop problems with the old wire format.

Changing wire format of a allocated type should NEVER be done.  That is a real headache for everybody.  I’ve seen early allocation do this and it is not nice.

Mark

> On 24 Jun 2020, at 09:40, Tommy Pauly <tpauly@apple.com> wrote:
> 
> 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.
> 
> Thanks,
> Tommy
> 
>> On Jun 23, 2020, at 4:38 PM, Mark Andrews <marka@isc.org> 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 <tpauly@apple.com> 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 <mt@lowentropy.net> 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):
>>>>> 
>>>>> https://github.com/MikeBishop/dns-alt-svc/issues
>>>>> 
>>>>> The most relevant to the HTTP WG are:
>>>>> 
>>>>> * Consider SVCB-Used header 
>>>>> <https://github.com/MikeBishop/dns-alt-svc/issues/107>
>>>>> * Parameter to indicate no HSTS-like behavior 
>>>>> <https://github.com/MikeBishop/dns-alt-svc/issues/100>
>>>>> * Consider a way to indicate some keys as "mandatory" 
>>>>> <https://github.com/MikeBishop/dns-alt-svc/issues/166> 
>>>>> 
>>>>> 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:
>>>>> 
>>>>> https://github.com/MikeBishop/dns-alt-svc/blob/master/draft-ietf-dnsop-svcb-https.md
>>>>> 
>>>>> and latest published is at:
>>>>> 
>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-00
>>>>> 
>>>>> Best, Erik
>>>>> 
>>>>> 
>>>>> ---------- Forwarded message ---------
>>>>> From: <internet-drafts@ietf.org>
>>>>> Date: Fri, Jun 12, 2020 at 4:18 PM
>>>>> Subject: New Version Notification for draft-ietf-dnsop-svcb-https-00.txt
>>>>> To: Benjamin Schwartz <bemasc@google.com>om>, Erik Nygren 
>>>>> <erik+ietf@nygren.org <mailto:erik%2Bietf@nygren.org>>, Mike Bishop 
>>>>> <mbishop@evequefou.be>
>>>>> 
>>>>> 
>>>>> 
>>>>> 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: 
>>>>> https://www.ietf.org/internet-drafts/draft-ietf-dnsop-svcb-https-00.txt
>>>>> Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
>>>>> Htmlized: https://tools.ietf.org/html/draft-ietf-dnsop- 
>>>>> <https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-00>svcb-https-00 <https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-00>
>>>>> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-s 
>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https>Consider a "mandatory" key range <https://github.com/MikeBishop/dns-alt-svc/issues/166>s <https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-00>vcb-https <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-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:
>>>>> https://github.com/MikeBishop/dns-alt-svc [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 tools.ietf.org.
>>>>> 
>>>>> The IETF Secretariat
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org