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

Mark Nottingham <mnot@mnot.net> Tue, 23 June 2020 05:48 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 54A543A177C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 22 Jun 2020 22:48:03 -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=mnot.net header.b=GYVsxldf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GC3zgcbX
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 4CncRtT3uhmR for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 22 Jun 2020 22:48:00 -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 2BF023A173E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 22 Jun 2020 22:47:59 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jnbk0-0006iw-KL for ietf-http-wg-dist@listhub.w3.org; Tue, 23 Jun 2020 05:45:04 +0000
Resent-Date: Tue, 23 Jun 2020 05:45:04 +0000
Resent-Message-Id: <E1jnbk0-0006iw-KL@lyra.w3.org>
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 <mnot@mnot.net>) id 1jnbjx-0006i9-P3 for ietf-http-wg@listhub.w3.org; Tue, 23 Jun 2020 05:45:01 +0000
Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mnot@mnot.net>) id 1jnbjv-0002ix-JZ for ietf-http-wg@w3.org; Tue, 23 Jun 2020 05:45:01 +0000
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 68F735C03FE; Tue, 23 Jun 2020 01:44:44 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 23 Jun 2020 01:44:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=a V//8tIZQghr8M/C9TX2f93XYw6sRt8UiiXrYbf1AG0=; b=GYVsxldft1hN2hwD/ grAexWPq9GckGB6rlhmqiobiVM6VbqcSYTV9A7IcmznUNQ+OPs6fzMvsKNK/5ruh JWEzFCkUN8lms2D2qYibc0lvNRa9xvRchZutJP6DDoxTXr+gl4QZta5rI8m0NIbF 1tYLVl6XzgwWhA3MYEQcSPuwtFV6/qR1/JbZiLJUGnxBw+3yHu5xY1guiyL7GInj /ECC4tY7s4oU21SaE8tjmjmlxG+ux7gz/7yMfXBI046e8RVTT/UF55gkNvHmxBNZ zC/MVBsE1htaAhNW3xl3/PHVccXlve8K+Fz3sugDCi3JalxJ+FRG0mQqND1svqjA xGg2A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=aV//8tIZQghr8M/C9TX2f93XYw6sRt8UiiXrYbf1A G0=; b=GC3zgcbXoc9QksS+bQpWxSJC0ey+9OhbBkXTnnUlS1QwWbhxiZD3gW4K7 fJzBCMn5ABMky1fvZ3nQaCvn49O/HodwQqU1vmRkDyvfPToaL0csCH589Ug9xxBh +xcd16AkVwg8EbC1aW64TuNqaOg7t2/joztEWoJGLmh0o2InwaMntW5/GtaeDq0d RGfQFLhr9qSx8+udq3yL0XqfE64z2Ei0Bos1hHzZ5ed3yExjHrSu7dexHWPHgsLs FNGfVcsi3R+zB/iaqv+9YaAD7otukT2KAIZ8zPpfnWorZemaH1UrPDhGDJv8qVwq KDj28FfMnU3fTPBw/uGjoogHO5hCA==
X-ME-Sender: <xms:xpbxXi9sBk8a0f2qHcdhkeTUaUVy3O1whImuK5x6rYFDt5dA1XGVtg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekfedgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeegteffteeigffhheffvdehtdfgheetgffgvedtgffghffgfeekffelffduueeu ueenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhivghtfhdrohhrghenucfkphepud duledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:xpbxXitmODAxB5-4cxjp6pUjJ5Ti6LK5_9uOLwOeEWlorqhHsXlrHw> <xmx:xpbxXoB60qT71f4xZM1G3l7tW7E904pnJ4bqpoyjwYNskmHCPTMCFw> <xmx:xpbxXqeUkHrI_cRR7DpAo_EeycCxDbLdjieH9-V1mA-D-wXPvRIv1g> <xmx:zJbxXsrh0zPnsDkUsEK2h101sv3p9M_Ve7NuXwfO32D4LMmc79RGuA>
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 4A6213280059; Tue, 23 Jun 2020 01:44:35 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAKC-DJgGoPirEoRW=E2qvYnsgx8s7Zyni=YxJEZNLMmTagwNMQ@mail.gmail.com>
Date: Tue, 23 Jun 2020 15:44:33 +1000
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Mike Bishop <mbishop@evequefou.be>, "Ben Brown (ubrgroup1@charter.net)" <ubrgroup1@charter.net>, tjw ietf <tjw.ietf@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <58D7F9FB-363C-4EA0-8841-49E713C0D5D1@mnot.net>
References: <159199313530.13520.7556914670094066150@ietfa.amsl.com> <CAKC-DJgGoPirEoRW=E2qvYnsgx8s7Zyni=YxJEZNLMmTagwNMQ@mail.gmail.com>
To: Erik Nygren <erik+ietf@nygren.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Received-SPF: pass client-ip=66.111.4.29; envelope-from=mnot@mnot.net; helo=out5-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_H3=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: titan.w3.org 1jnbjv-0002ix-JZ 267a2cf67f74bec7a448349cea1a9370
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/58D7F9FB-363C-4EA0-8841-49E713C0D5D1@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37811
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 that. Reading through the document for the first time in a while, a few questions pop to mind:

* For those who haven't been following, can you explain why it was thought best to decouple form Alt-Svc?

* The introduction talks about SVCB 'provid[ing] clients with complete instructions for access to an origin.' 'origin' is a Web-specific term; is there a more neutral term you can use to distinguish it from HTTPS? I see in Terminology that you justify this for alignment with Alt-Svc, but that seems to assume that other protocols will have an origin concept -- in particular, a scheme (I'm not against aligning all potential protocols to this model, just a bit surprised that it's got this far).

* That brings to mind the SRV framework; is there any attempt to relate the SVCB framework to it -- especially since this appears to embed the ALPN view of the world? I'm sure some will want to know...

* Did you consider publishing these as two separate documents? That might make the layering more clear.

* Do we have statements of support for the delegation use cases from client implementers? This was a key purpose for Alt-Svc, but it wasn't implemented by clients widely.

* Section 7.5 gives the HTTPS record effective HSTS semantics. Has there been engagement with / review from the security community on this? In particular:
  * Are the presumably shorter DNS TTLs suitable for HSTS use cases?
  * Are there any other fixes / enhancements to HSTS that we want to layer in?

Cheers,



> On 18 Jun 2020, at 12:48 pm, Erik Nygren <erik+ietf@nygren.org> 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
> * 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:
> 
>    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>rg>, 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-svcb-https-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-sConsider a "mandatory" key rangesvcb-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 Nottingham   https://www.mnot.net/