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

Martin Thomson <mt@lowentropy.net> Tue, 23 June 2020 09:28 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 9BAE93A181F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Jun 2020 02:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=P0OHprqZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GS6f6ja9
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 cXxeuen6UL1H for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Jun 2020 02:28:50 -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 9D3473A181C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Jun 2020 02:28:50 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jnfBz-0004AP-Lq for ietf-http-wg-dist@listhub.w3.org; Tue, 23 Jun 2020 09:26:11 +0000
Resent-Date: Tue, 23 Jun 2020 09:26:11 +0000
Resent-Message-Id: <E1jnfBz-0004AP-Lq@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mt@lowentropy.net>) id 1jnfBy-00049Z-03 for ietf-http-wg@listhub.w3.org; Tue, 23 Jun 2020 09:26:10 +0000
Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mt@lowentropy.net>) id 1jnfBv-00069M-IT for ietf-http-wg@w3.org; Tue, 23 Jun 2020 09:26:09 +0000
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id CE3DCC11 for <ietf-http-wg@w3.org>; Tue, 23 Jun 2020 05:25:54 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 23 Jun 2020 05:25:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=wYC4neUPIHYWoO/BSZjK9kQTrIX1d+p yuqU+48w/izY=; b=P0OHprqZQDMjzeFXvjnR9jn1DdmE6RY/AmijdrCC3UGx1rd TiZfLs4CxyBqpYG+iJVwpfB3E7rP3fXQAZGVfuef0KWLIUeJr2jdOPayDofpKsF+ STGVJdWeJP9pzZHUdyt9C7+x9bV3pqmDvgWnLEyvC2G40RNdnCTLjP2LCTL4HMKq dhn2CpJvL0/kh0A79gRsiPJxtQKgw/TdsoQtR+qS8nKv8VdANkoM9Z2t59gltM3W 4TG0glcpJG0RgIS75N9dUvwEh+80Lrf16qublJtxkYhR1XoPVG7BmcjUDmyVPWfR N6yba9Q20DCmgt22+eb6ShiLVBYzlvSi/Db2fhA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=wYC4ne UPIHYWoO/BSZjK9kQTrIX1d+pyuqU+48w/izY=; b=GS6f6ja9do8MKkMW3XTLf7 /Ku9aGoK8PrmZJA29kOeP6Xli+45GjY3dF8OmRsrUgqCfx07Ve48qurrbnR/Q8fv JJgFOQ4A6vGd+xdIf/56qDfFrYsUJ93vofGHqgjBC6BoHHPoNIRl4ZBnzul+YBph ZWys7uc/hoaPkoQdIOoPtm4wonapk7Y+XqBx15PeK5sMX/c6o3DNqsp9NFeiMRBl B4q5WbAQPzKcA2dz8rS0tIp1iL5sBHL8KqdsTl1jMB+IRfGw9v/KYemvxdr1WlQq 1uM28hXIK+gnltMa9lOge6f5t9BmzdYzXyEM85iUOkjB+g4XVgNmtXV538DRbROA ==
X-ME-Sender: <xms:osrxXldAbh9HyZ02YRGMSh18tFPR6O6PNtZUhjlXaJL_YcVDIhHMNQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekgedgudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeffveekgeetvdeuvedtve evtdeuleegveejhfehgfetffeiiefgveefleffteeuleenucffohhmrghinhepghhithhh uhgsrdgtohhmpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:osrxXjOr6Xm6nM9NEuAJV9MlXWNqmjnKvcdddN7W0mREUU4NHP01tg> <xmx:osrxXugOstziUA7W7r919IFWf_asg8rY9ecEGAY6Ka83nbchUqZr9w> <xmx:osrxXu80-CMRa_Jwoanh7UIPuLovwZgkcYDNSdR4MyEVoUJBJ4cVUA> <xmx:osrxXqPfYLz3dwGc8QsnvuhGvg8CHprDlVtgDWQbTLeRkXqscGf1qA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 06107E00A8; Tue, 23 Jun 2020 05:25:54 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-543-gda70334-fm-20200618.004-gda703345
Mime-Version: 1.0
Message-Id: <00397886-f3b3-4788-b4c9-e64055802131@www.fastmail.com>
In-Reply-To: <CAKC-DJgGoPirEoRW=E2qvYnsgx8s7Zyni=YxJEZNLMmTagwNMQ@mail.gmail.com>
References: <159199313530.13520.7556914670094066150@ietfa.amsl.com> <CAKC-DJgGoPirEoRW=E2qvYnsgx8s7Zyni=YxJEZNLMmTagwNMQ@mail.gmail.com>
Date: Tue, 23 Jun 2020 19:25:32 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: ietf-http-wg@w3.org
Content-Type: text/plain
Received-SPF: pass client-ip=64.147.123.24; envelope-from=mt@lowentropy.net; helo=wout1-smtp.messagingengine.com
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_H4=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: mimas.w3.org 1jnfBv-00069M-IT bc54a7a67e05806654a8c7b29cb45e71
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/00397886-f3b3-4788-b4c9-e64055802131@www.fastmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37814
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>

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
> 
>