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

Mark Nottingham <mnot@mnot.net> Wed, 08 July 2020 05:51 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 5E1E73A0922 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 7 Jul 2020 22:51:05 -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=a3FveqRT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jCDFKSeF
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 cQ21RTIKCCV3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 7 Jul 2020 22:51:01 -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 EC9CE3A0927 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 7 Jul 2020 22:51:00 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jt2vu-0005hp-B9 for ietf-http-wg-dist@listhub.w3.org; Wed, 08 Jul 2020 05:47:50 +0000
Resent-Date: Wed, 08 Jul 2020 05:47:50 +0000
Resent-Message-Id: <E1jt2vu-0005hp-B9@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 1jt2vs-0005gR-QH for ietf-http-wg@listhub.w3.org; Wed, 08 Jul 2020 05:47:48 +0000
Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mnot@mnot.net>) id 1jt2vq-0006zi-J5 for ietf-http-wg@w3.org; Wed, 08 Jul 2020 05:47:48 +0000
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 81BC55C0175; Wed, 8 Jul 2020 01:47:33 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 08 Jul 2020 01:47:33 -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=R J6A+wpe+DvqPb1wLZCPGrcN9hKGN4BhGnvTF5q2ED4=; b=a3FveqRTHmlLR4ohv 0SBvYCmt3REJJ53LwEn52A4nmp88utxLBjU0PkLE7bU4EQH8KLUh17JFIrFff0Sx Yx2yyY6agkp5z+PFJ0aj+G8bWcJxKLmmV9O/hKrGGhU0FF8nSnYMkFcZi/EneOdF emSqUPSwL3pUayBwv8kgCNtPCq+jmw/RdbT/jwmW+ZymLOi/F5aQ8f4GzlTVuaov hYb+gljbJAfUzIoxt9IUlo0VRhDJXIb/vJOzzt34VYLzS2OD7Nvve9MddzErwv9P jtSmlgNCzpjzlSqnirqt3iicIfQE230BsA06+VEOx0zId+zK2A/aB6dPcKW5h6MP CtC6Q==
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=RJ6A+wpe+DvqPb1wLZCPGrcN9hKGN4BhGnvTF5q2E D4=; b=jCDFKSeFoeudS5ZR/1/i2JE0pxAmXiv+8IVM7S1xesQYA1esy4Ar1s0FE vpBZHC/uF2g3Sq8fKdPk5HkmvlwDkVfgogq6Ml8t29z2/tPK6Vu1+niJ15QY3Hb2 pHwDrSbpRGPgZ64U43eww/IrFh6WxgGCIeBLVkpWfB+zpHgVQ+ldlAMmZ5dZ0N5z tNNcOsceSV40bqT8qrIQrJBbwU0VFyAAflDbKdxVWVpOEzlbuRIqRnmgU7w0rBgo yHnL1eDNKh6Nt9cP49weiJx83SuMJdlwauE6pS47G8MMOxNBeAh7AAn2sQaxWOC3 mf6ApXSnRy34kC89tdh00/acpi/6g==
X-ME-Sender: <xms:8l0FX4deeZH8INhsfEgkEl5DVWX4ijO83MyLHIMOk9Cq_sck4_Gy7w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeigddutdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeeludffffejfefgtdehtdfhudffuedvueefveejteffkeehkeethfdvudetfffh geenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhhthhtphhsihhsthhhvghonhhlhi gvgigrmhhplhgvthhhrghtihhsihhnihhtihgrlhhlhihsphgvtghifhhivggurdguohdp ihgvthhfrdhorhhgnecukfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhn vght
X-ME-Proxy: <xmx:8l0FX6OlBHpQRHFLcTT10pX1saP2YD9h36jNaW9pX33Knl5thPoxvg> <xmx:8l0FX5hQbyRHQQtzKssSI0h4NxB0bts-820I8O3hpjUpL8vHbyZH6g> <xmx:8l0FX99M0ebhwMQ8eNR9XwCKu24qNRFrNLlLIgqsy0EzhjxrKdY3vg> <xmx:9V0FX-VX5M5Bl3FqIRtx_XjpvIsGA7CUqdwDr2DBMdHbItXErSbYZA>
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 5D0B930600A3; Wed, 8 Jul 2020 01:47:28 -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: <CAHbrMsDRxJy6uvhYCaHb05YBjej1mBY-LW8rp5vsGVvGSFd4EQ@mail.gmail.com>
Date: Wed, 8 Jul 2020 15:47:25 +1000
Cc: Erik Nygren <erik+ietf@nygren.org>, "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: <ACC64884-309D-45E2-8679-37C27E228A2B@mnot.net>
References: <159199313530.13520.7556914670094066150@ietfa.amsl.com> <CAKC-DJgGoPirEoRW=E2qvYnsgx8s7Zyni=YxJEZNLMmTagwNMQ@mail.gmail.com> <58D7F9FB-363C-4EA0-8841-49E713C0D5D1@mnot.net> <CAHbrMsDRxJy6uvhYCaHb05YBjej1mBY-LW8rp5vsGVvGSFd4EQ@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Received-SPF: pass client-ip=66.111.4.26; envelope-from=mnot@mnot.net; helo=out2-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 1jt2vq-0006zi-J5 cecadec7af944b94d1837787c697dc36
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/ACC64884-309D-45E2-8679-37C27E228A2B@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37854
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>


> On 25 Jun 2020, at 12:20 pm, Ben Schwartz <bemasc@google.com> wrote:
> 
> On Tue, Jun 23, 2020 at 1:48 AM Mark Nottingham <mnot@mnot.net> wrote:
> 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?
> 
> Analyzing the interaction between Encrypted ClientHello (ECH), SVCB, and Alt-Svc became extremely complex, and the resulting behaviors seemed likely to be brittle.  One key point is that Alt-Svc was designed to be optional (fallback to direct connection is always allowed), but this is not true for any medium that can transfer ECH public keys ("ECHConfigs"), due to the need for downgrade-attack resistance.  Retrofitting a no-fallback mode onto Alt-Svc raised concerns about ECH key rotation (Alt-Svc cache lifetimes are very long), ALPN negotiation, and CDN transitions/multi-CDN.
> 
> You can see a much more detailed discussion here:
> https://github.com/MikeBishop/dns-alt-svc/issues/105.
> https://github.com/MikeBishop/dns-alt-svc/issues/60
> https://github.com/MikeBishop/dns-alt-svc/issues/58
> 
> * 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).
> 
> SVCB is designed for use with URIs, so a scheme is required.  (Section 10, "The scheme SHOULD have an entry in the IANA URI Schemes Registry".)  URIs that concern a domain name presumably have an "authority" in their URI that contains a "host", and might contain a "port".
> 
> If you can think of a better name for "scheme, host, and port-if-applicable", we can certainly adjust.

I think it's fine, it might be good however to call attention to the fact that this is for URI-based protocols early on...


>  * 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...
> 
> There's no explicit connection to SRV.  Personally, I view SVCB as a successor to SRV, but it's certainly not intended to replace SRV where SRV is already working well.

Fair enough.


> * Did you consider publishing these as two separate documents? That might make the layering more clear.
> 
> It would of course be possible to separate them, but I think it might be confusing, because SVCB's design choices are easiest to understand in the context of a realistic example, and HTTPS is the only example that is initially specified.
> 
> * 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.
> 
> I believe we do.
> 
> * Section 7.5 gives the HTTPS record effective HSTS semantics. Has there been engagement with / review from the security community on this?
> 
> I would say so, e.g. https://github.com/MikeBishop/dns-alt-svc/issues/87
>  
> In particular:
>   * Are the presumably shorter DNS TTLs suitable for HSTS use cases?
> 
> TTL is not strictly relevant here.  Unlike the HSTS header, this semantic works perfectly well even with TTL=0.  The HSTS header relies on the user having had a "clean network path" in the (recent) past.  The HTTPS-upgrade here instead relies on the user currently having a "clean DNS path", e.g. inside DoH.
> 
>   * Are there any other fixes / enhancements to HSTS that we want to layer in?
> 
> Suggestions welcome!
>  
> 
> 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/
> 
> 

--
Mark Nottingham   https://www.mnot.net/