Fwd: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

Erik Nygren <erik+ietf@nygren.org> Tue, 24 September 2019 13:26 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 0421012006E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 24 Sep 2019 06:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 68i39whf1ExB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 24 Sep 2019 06:26:03 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (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 372B0120048 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 24 Sep 2019 06:26:03 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iCkmj-0002Q3-89 for ietf-http-wg-dist@listhub.w3.org; Tue, 24 Sep 2019 13:23:17 +0000
Resent-Date: Tue, 24 Sep 2019 13:23:17 +0000
Resent-Message-Id: <E1iCkmj-0002Q3-89@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <nygren@gmail.com>) id 1iCkmf-0002PD-Av for ietf-http-wg@listhub.w3.org; Tue, 24 Sep 2019 13:23:13 +0000
Received: from mail-wm1-f43.google.com ([]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <nygren@gmail.com>) id 1iCkmd-0002vk-Ex for ietf-http-wg@w3.org; Tue, 24 Sep 2019 13:23:13 +0000
Received: by mail-wm1-f43.google.com with SMTP id x2so53790wmj.2 for <ietf-http-wg@w3.org>; Tue, 24 Sep 2019 06:22:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/aF1kU2wyy27n6yr/Qc1hLAZMUtO7dGQGpDPrDzeFkY=; b=AAXhU89xHmh/hfsCu8BeIUaUTlOTQN4JlNt6d9XI1L+k/FfsAoJyTA4Kgn/QmJlAAE Ho/iBLT0zMb+M9OY7AQnQ0jtDuXFFFwnIKDAsIZySq1FLk9xhAJayljpNpII9uOCr+lO qeiWDSJyOESC9YrH2OVu4EvRmWNoiwv4MVviPUjUW0TXF+TkqrRSv/0et5fVSz0QgPOC B/1157MWfHH1bDaV7m60uW9PWg1BK+v6gpTYMN4UoHz8SvlHoxtaY7Nbd5nd4aKhEyz3 LUzZXeul3I2F9ZsP9wbZ++us9x0J4c1UZML4A4u/oUvF5EVj6ZUMDvW9iH0j7BOp5+c+ hGpw==
X-Gm-Message-State: APjAAAXzaRt+Z2/rswaqrfQE6czicJKuG0gfm5pdhMPC+n2MSsHghQOB 5qlERBu//fy/FLW8FZ6pys/vomHCBuwkW30HRAC1AZT5
X-Google-Smtp-Source: APXvYqwkCySPj1y/tFLNQWn4BDir+YY0v9lS7VZQy7mPUdMU8vnUB/9Cw+veQzv5CKqYVWn+laePSC70Q22UBRZgpPE=
X-Received: by 2002:a7b:c74a:: with SMTP id w10mr16839wmk.30.1569331369619; Tue, 24 Sep 2019 06:22:49 -0700 (PDT)
MIME-Version: 1.0
References: <156927967091.17209.1946223190141713793.idtracker@ietfa.amsl.com> <CAKC-DJi4EHz5CCAqRj_cYTVygiuo0s2QGaPLCct6e9Bh1mXaXQ@mail.gmail.com>
In-Reply-To: <CAKC-DJi4EHz5CCAqRj_cYTVygiuo0s2QGaPLCct6e9Bh1mXaXQ@mail.gmail.com>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Tue, 24 Sep 2019 09:22:38 -0400
Message-ID: <CAKC-DJiUyNwpsBUbWC9QoPzZJ+Lebng+qpMM9+kTasEbZGiE5g@mail.gmail.com>
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Mike Bishop <mbishop@evequefou.be>, Ben Schwartz <bemasc@google.com>
Content-Type: multipart/alternative; boundary="000000000000d2369505934c6e3f"
Received-SPF: pass client-ip=; envelope-from=nygren@gmail.com; helo=mail-wm1-f43.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Scan-Sig: mimas.w3.org 1iCkmd-0002vk-Ex 2753475979e7cfdd5d187fb30b0c5418
X-Original-To: ietf-http-wg@w3.org
Subject: Fwd: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
Archived-At: <https://www.w3.org/mid/CAKC-DJiUyNwpsBUbWC9QoPzZJ+Lebng+qpMM9+kTasEbZGiE5g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37034
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>

Following the discussions in Montreal (as well as with some of the ESNI
we refactored the HTTPSSVC draft to make it more general.
The draft generalizes to a protocol-agnostic SVCB record, but also specifies
an HTTPSSVC record for the HTTP(S) use-case that continues to have
specific bindings to Alt-Svc.

Based on discussions with various chairs, the plan is to call for adoption
in the DNSOP WG.

Comments/feedback are most welcome.


---------- Forwarded message ---------
From: Erik Nygren <erik+ietf@nygren.org>
Date: Tue, Sep 24, 2019 at 9:17 AM
Subject: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
To: dnsop WG <dnsop@ietf.org>rg>, Ben Schwartz <bemasc@google.com>om>, Mike
Bishop <mbishop@evequefou.be>

Following discussions around the "HTTPSSVC" record proposal in Montreal
with the DNSOP, HTTP and TLS WGs, we've updated what was previously
"draft-nygren-httpbis-httpssvc-03".  The new version is
"draft-nygren-dnsop-svcb-httpssvc-00".   This incorporates much of the
feedback from the WG discussions, as well as feedback from discussions with
the TLS WG (as we'd like to see this replace the need for a separate ESNI

In particular, it generalizes the record into a new "SVCB" record which
doesn't have any protocol-specific semantics.  It also defines an
"HTTPSSVC" record that is compatible with SVCB (sharing a wire-format and
parameter registry) and which defines the HTTP(S)-specific semantics such
as bindings to Alt-Svc.  Other protocols can either define bindings
directly to SVCB or can define their own RR Type (which should only ever be
needed if there is a need to use the record at a zone apex).

We'd like to see this adopted by the DNSOP WG.  Until then, issues and PRs
can go against:  https://github.com/MikeBishop/dns-alt-svc

Major changes from "draft-nygren-httpbis-httpssvc-03" include:

* Separation into the SVCB and HTTPSSVC RR Types  (and separated all of the
HTTPS-specific functionality and text to its own portion of the document).
* Elimination of the SvcRecordType field (and making the SvcRecordType
* Changing the wire format of parameters from being in Alt-Svc text format
to a more general binary key/value pair format (with a mapping to Alt-Svc
* Adding optional "ipv4hint" and "ipv6hint" parameters.
* Quite a few cleanups and clarifications based on input (and we
undoubtedly have more left to go)

This retains support for all of the use-cases that the previous HTTPSSVC
record had (such as for covering the ANAME / CNAME-at-the-zone-apex

Feedback is most welcome.  If the TLS WG is going to use this instead of a
separate ESNI record, there is a desire to make progress on this fairy


---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Mon, Sep 23, 2019 at 7:01 PM
Subject: New Version Notification for
To: Mike Bishop <mbishop@evequefou.be>be>, Erik Nygren <erik+ietf@nygren.org>rg>,
Benjamin Schwartz <bemasc@google.com>

A new version of I-D, draft-nygren-dnsop-svcb-httpssvc-00.txt
has been successfully submitted by Benjamin Schwartz and posted to the
IETF repository.

Name:           draft-nygren-dnsop-svcb-httpssvc
Revision:       00
Title:          Service binding and parameter specification via the DNS
Document date:  2019-09-22
Group:          Individual Submission
Pages:          33

   This document specifies the "SVCB" and "HTTPSSVC" DNS resource record
   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 keying material for encrypting TLS SNI).  They also
   enable aliasing of apex domains, which is not possible with CNAME.
   The HTTPSSVC DNS 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: The specific name for this RR type is an open topic
   for discussion.  "SVCB" and "HTTPSSVC" are meant as placeholders as
   they are easy to replace.  Other names might include "B", "SRV2",

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