Re: HTTPSSVC record draft
Ian Swett <ianswett@google.com> Tue, 09 July 2019 02:47 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 75BFD1200B7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 8 Jul 2019 19:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.251
X-Spam-Level:
X-Spam-Status: No, score=-10.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 6k0m7hMMOY9c for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 8 Jul 2019 19:46:58 -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 A3CDF12008B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 8 Jul 2019 19:46:58 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hkg7C-0006EC-86 for ietf-http-wg-dist@listhub.w3.org; Tue, 09 Jul 2019 02:44:22 +0000
Resent-Date: Tue, 09 Jul 2019 02:44:22 +0000
Resent-Message-Id: <E1hkg7C-0006EC-86@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 <ianswett@google.com>) id 1hkg7B-0006DX-0F for ietf-http-wg@listhub.w3.org; Tue, 09 Jul 2019 02:44:21 +0000
Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <ianswett@google.com>) id 1hkg78-0006ca-G6 for ietf-http-wg@w3.org; Tue, 09 Jul 2019 02:44:20 +0000
Received: by mail-wm1-x334.google.com with SMTP id w9so1309134wmd.1 for <ietf-http-wg@w3.org>; Mon, 08 Jul 2019 19:43:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YHa+0JiONhgtLL3yXjjfzIWuXG5ULdraVTOSnxz4xtU=; b=UpEyazu/cunjiYhvAr27eIJt+hEUUjBU60xvyp5/F+cqdlx2PmwVPhNivlk4yF5nZf yZ4arANh3aLYPoy7GYgKazbSEinXbmIHRdJQmfleeqj+U8jozBQsag2sq4TteFTkTJIP h6ZumN6Ui/Y0HWPbXq9zcbIAbBl0STEZSajkncBCSHu67E2V4EyUfxrssTKYqS5j20I6 i6FYp7TPOjfbjs4tLkbLWRSU7uH86iUufNpumKL8YWVtYNCXsdK5ISONmkdk9765+Beb hoKS07qpwoJKL4Vqul1qSfBmFZU0UvTVXnoa6a7FHIdV44Zc89ze6H/728Qu2pKk4Q3r lPtw==
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:cc; bh=YHa+0JiONhgtLL3yXjjfzIWuXG5ULdraVTOSnxz4xtU=; b=NWd2laAvP814lCsR7siKxHD0GRrHseEXeE59sWd470yezG9d0S/5qDRUvR74ALaboQ 3V6sxWw1BEcO1JkURqPDawfk8O/E/f3scKMxjoUmUgISqWthhJ5y9a1An4iW9Mn38yjZ 8Rutout6C99JIZU6cWRcaT6PxTdEnBMpGrANYA+ODdf542cR8iPTEfw8hJWiaoDzBTeL sQoHxZlzhQAHqxYVVeWQiilyOXKdX5VroK7Qh+sCyX1FEzsKrX2qLXDIHmEF1tjIE00O Rd7qxVwur8BK5K0hCDa9WmvDGEY2Drx7gMGH9Ab+1OvMi001HBzC09lo0grB8kuFdEV4 k5Bg==
X-Gm-Message-State: APjAAAUasQaRZ0mrxl9i2+2oDwK+8LJiNQcs4UqdQt9X6ZEzWQz+vfJM 97a1oFePMnbjYeeiUIn5NQgilxgoDF6usH3IQK48uPGOAn8=
X-Google-Smtp-Source: APXvYqw3K5LZbC867k/vyfKBph3qlTUkrZtgi7r2bql+iN8dkusBstzWVVnCdnWdr/KLbnGd8IjpU1iSeFvMdv4zumU=
X-Received: by 2002:a1c:f505:: with SMTP id t5mr18723415wmh.67.1562640235946; Mon, 08 Jul 2019 19:43:55 -0700 (PDT)
MIME-Version: 1.0
References: <CAKC-DJikByP+wX-GoD6ntpUWTbr6ioJzB4i8nGQL4NtPWePL3g@mail.gmail.com> <7B54D926-22C6-4283-B54C-6A53D22D2126@isc.org> <CAKC-DJi7+jq0m6wY2S+9aKXzHBeKXhWN_+UKx0D_RDKa5orPzA@mail.gmail.com>
In-Reply-To: <CAKC-DJi7+jq0m6wY2S+9aKXzHBeKXhWN_+UKx0D_RDKa5orPzA@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Mon, 08 Jul 2019 22:43:44 -0400
Message-ID: <CAKcm_gP2H5t+EuLgTmF8T9BqYE3WyyfAiGPJOJK89o6_RZdTRw@mail.gmail.com>
To: Erik Nygren <erik+ietf@nygren.org>
Cc: Mark Andrews <marka@isc.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Mike Bishop <mbishop@evequefou.be>, Benjamin Schwartz <bemasc@google.com>
Content-Type: multipart/alternative; boundary="0000000000002d76ca058d36885d"
Received-SPF: pass client-ip=2a00:1450:4864:20::334; envelope-from=ianswett@google.com; helo=mail-wm1-x334.google.com
X-W3C-Hub-Spam-Status: No, score=-18.3
X-W3C-Hub-Spam-Report: AWL=1.333, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hkg78-0006ca-G6 b6ff1184f20a73707eb626446e1bc9d0
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTPSSVC record draft
Archived-At: <https://www.w3.org/mid/CAKcm_gP2H5t+EuLgTmF8T9BqYE3WyyfAiGPJOJK89o6_RZdTRw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36769
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>
Thanks for the updates, this is a very exciting proposal that could greatly advance HTTPS, QUIC, encrypted SNI, and likely other future innovations. Is this going to be presented in any other working groups?(ie: dnsop?) I'd be interested in their feedback as well. Thanks, Ian On Mon, Jul 8, 2019 at 5:12 PM Erik Nygren <erik+ietf@nygren.org> wrote: > I've published a -03 for this draft: > > https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-03 > > Most significant changes based on feedback: > > * Remove the redundant length fields from the wire format. > * Define a SvcDomainName of "." for SvcRecordType=1 as being the > HTTPSSVC RRNAME. > * Switch from 302 to 307 redirect for HSTS equivalent. > > but there also some added examples and other clarifications based on > feedback received. > > While this is still an individual draft, we have been tracking it here: > https://github.com/MikeBishop/dns-alt-svc > but as always, commentary on the IETF lists is generally preferable. > > That's great to already see a bind9 prototype implementation! > (Does it already associate Additional records from the SvcDomainName > for recursive responses when that was already in-cache? I'm curious to see > if that is trivial or not to add in existing code bases.) > Reading through the implementation made it quite clear how desirable it was > to remove the redundancy from the wire format. > > Erik > > > > > On Fri, Jul 5, 2019 at 2:52 AM Mark Andrews <marka@isc.org> wrote: > >> A private type implementation is here for BIND. >> >> https://gitlab.isc.org/isc-projects/bind9/merge_requests/2135 >> >> Mark >> >> > On 4 Jul 2019, at 4:45 am, Erik Nygren <erik+ietf@nygren.org> wrote: >> > >> > >> > Ben, Mike, and I have submitted the first version of a proposal for an >> "HTTPSSVC" DNS record. >> > >> > TL;DR: This attempts to address a number of problems (ESNI, QUIC >> bootstrapping, HTTP-to-HTTPS redirection via DNS, SRV-equivalent for HTTP, >> etc) in a holistic manner through a new extensible DNS record, rather than >> in a piecemeal fashion. It is based on some previous proposals such as >> "Alt-Svc in the DNS" and "Service Bindings" but takes into account feedback >> received in DNSOP and elsewhere. >> > >> > Feedback is most welcome and we're looking forward to discussing with >> people in Montreal. >> > >> > Draft link: >> > >> > https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-01 >> > >> > >> > >> > From the abstract: >> > >> > This document specifies an "HTTPSSVC" DNS resource record type to >> facilitate the lookup of information needed to make connections for HTTPS >> URIs. The HTTPSSVC DNS RR mechanism allows an HTTPS origin hostname to be >> served from multiple network services, each with associated parameters >> (such as transport protocol and keying material for encrypting TLS SNI). >> It also provides a solution for the inability of the DNS to allow a CNAME >> to be placed at the apex of a domain name. Finally, it provides a way to >> indicate that the origin supports HTTPS without having to resort to >> redirects, allowing clients to remove HTTP from the bootstrapping process. >> > >> > By allowing this information to be bootstrapped in the DNS, it allows >> for clients to learn of alternative services before their first contact >> with the origin. This arrangement offers potential benefits to both >> performance and privacy. >> > >> > 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. >> > >> > -- >> > >> > Some likely FAQs (with some others listed in an appendix): >> > >> > Q: Why this is HTTP-specific? >> > A: This is because every protocol has different bootstrap >> requirements. This draft is concerned with improving the efficiency and >> security of bootstrapping HTTPS connections. This proposal does offer room >> for non-HTTPS protocols, but the nature of DNS requires underscore >> prefixing to support protocol-keyed answers within a single RRTYPE. It's >> also unlikely that a single RR format would be the ideal bootstrap >> mechanism for every protocol, and there's no reason that multiple protocols >> should have to share an RRTYPE. >> > >> > Q: Why is ESNI addressed directly? >> > A: This helps make a major motivation of this draft more clear. >> Splitting out those sections to a separate-but-associated "alt-svc >> attribute for ESNI keys" draft might make sense, but keeping it here helps >> work through some of the issues together. >> > >> > Q: Why does this try to address the HSTS case? >> > A: This is a unique opportunity to fix HTTPS bootstrap and avoid >> providing insecure defaults. We'd originally proposed a separate Alt-Svc >> attribute to indicate hsts-style behavior, but then realized that it would >> make sense to push on that as the default here. >> > >> > Best, Erik >> > >> > >> > >> > ---------- Forwarded message --------- >> > From: <internet-drafts@ietf.org> >> > Date: Wed, Jul 3, 2019 at 1:06 PM >> > Subject: New Version Notification for >> draft-nygren-httpbis-httpssvc-01.txt >> > To: Mike Bishop <mbishop@evequefou.be>, Erik Nygren < >> erik+ietf@nygren.org>, Benjamin Schwartz <bemasc@google.com> >> > >> > >> > >> > A new version of I-D, draft-nygren-httpbis-httpssvc-01.txt >> > has been successfully submitted by Benjamin Schwartz and posted to the >> > IETF repository. >> > >> > Name: draft-nygren-httpbis-httpssvc >> > Revision: 01 >> > Title: HTTPSSVC service location and parameter specification >> via the DNS (DNS HTTPSSVC) >> > Document date: 2019-07-03 >> > Group: Individual Submission >> > Pages: 22 >> > URL: >> https://www.ietf.org/internet-drafts/draft-nygren-httpbis-httpssvc-01.txt >> > Status: >> https://datatracker.ietf.org/doc/draft-nygren-httpbis-httpssvc/ >> > Htmlized: >> https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-01 >> > Htmlized: >> https://datatracker.ietf.org/doc/html/draft-nygren-httpbis-httpssvc >> > Diff: >> https://www.ietf.org/rfcdiff?url2=draft-nygren-httpbis-httpssvc-01 >> > >> > Abstract: >> > This document specifies an "HTTPSSVC" DNS resource record type to >> > facilitate the lookup of information needed to make connections for >> > HTTPS URIs. The HTTPSSVC DNS RR mechanism allows an HTTPS origin >> > hostname to be served from multiple network services, each with >> > associated parameters (such as transport protocol and keying material >> > for encrypting TLS SNI). It also provides a solution for the >> > inability of the DNS to allow a CNAME to be placed at the apex of a >> > domain name. Finally, it provides a way to indicate that the origin >> > supports HTTPS without having to resort to redirects, allowing >> > clients to remove HTTP from the bootstrapping process. >> > >> > By allowing this information to be bootstrapped in the DNS, it allows >> > for clients to learn of alternative services before their first >> > contact with the origin. This arrangement offers 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. >> > >> > >> > >> > >> > 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 >> >>
- HTTPSSVC record draft Erik Nygren
- Re: HTTPSSVC record draft Ilari Liusvaara
- Re: HTTPSSVC record draft Ben Schwartz
- Re: HTTPSSVC record draft Mark Andrews
- Re: HTTPSSVC record draft Mark Andrews
- Re: HTTPSSVC record draft Erik Nygren
- Re: HTTPSSVC record draft Ian Swett
- Re: HTTPSSVC record draft Mark Andrews
- Re: HTTPSSVC record draft Erik Nygren
- Re: HTTPSSVC record draft Ben Schwartz
- Re: HTTPSSVC record draft Mark Andrews