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

Ben Schwartz <bemasc@google.com> Thu, 09 July 2020 18:07 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 5B1913A0D9F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 Jul 2020 11:07:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 MQK7io2sLpIG for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 Jul 2020 11:07:17 -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 0DD333A0D9C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 9 Jul 2020 11:07:16 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jtauF-0002kj-UJ for ietf-http-wg-dist@listhub.w3.org; Thu, 09 Jul 2020 18:04:23 +0000
Resent-Date: Thu, 09 Jul 2020 18:04:23 +0000
Resent-Message-Id: <E1jtauF-0002kj-UJ@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 <bemasc@google.com>) id 1jtau6-0002TB-EC for ietf-http-wg@listhub.w3.org; Thu, 09 Jul 2020 18:04:14 +0000
Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <bemasc@google.com>) id 1jtatd-0006PB-R5 for ietf-http-wg@w3.org; Thu, 09 Jul 2020 18:04:14 +0000
Received: by mail-wm1-x334.google.com with SMTP id j18so2903953wmi.3 for <ietf-http-wg@w3.org>; Thu, 09 Jul 2020 11:03:40 -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=Mb/WRmg1TgvuZ1OHu4OQ0rRFZ8r9U6rlBYm2LsTTE1k=; b=X6iAincTQsehbX4niOGXHXX9rRG/L18p8HPllCbcUPbAKKO1wGGD5TKPDxz7qHHcxL RL5Qka2pJpAyx9ptP9Is9zwz+5pPVs2kckRfmMW6ASsrQ0NhUiqP6ehkm3XFzzNVwTZG nfYqeIZgynIZ5/Vr27tDNrOubV7RD8Ru0bYQ+Fz9ExT5n46mY2ldp/kMGXjbvNYpeUrO ISMjFkBajyeTsC7VGw8K1Qq65eti/ECt4p+vg+veh7o3RyAe99pVAjsoNmf/VDxsjZP3 xvNw0tjd1ok1ntSTMaFUfS0CMbXSh63LOZfxbg3WFSiIUxuw1TP6DSXlM7RLlmJymST+ cUhg==
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=Mb/WRmg1TgvuZ1OHu4OQ0rRFZ8r9U6rlBYm2LsTTE1k=; b=rqUIjcrVcax6MNnHxaHAtZweZKOI5aV11pGYXGZuZLx16AZU1HHMs1Se4J54ibsVHL ST7k1XHVvCIsdjTDVsM9NEvmz1j0gsONyNUxigw2KbVPiI5uxU4sc/pJW/SxJQlRfoWw f95ygVLWkt2fphoRUyAge25dr3LOgMvGEj5GuLP9s1r8l4SFv9nFZFzS086YWI23zRO2 BsBbUD0JVryIf+hk5t7sNYyW1ruymUKyt7DffCIDXf2lmLSeA82lmK2Ttpl901IekaLd fiWjiwUOCI7mKaMTQT9U4Asv+LP5HHHGpcliyd7BESQKSxDINJlCHZ4PmPXJGtp/gukM WzLg==
X-Gm-Message-State: AOAM533r7k6iAT3q9rDQz5ml7AojC8EW9D5BvSwTS/hca76mQqK0mPQY MKP65q0nO3vtSNQvRhyGSRcmQmO21YdL55l2elbjOw==
X-Google-Smtp-Source: ABdhPJxYa7ER5mstuW1rMS6ajiCj5PYFjA5NAYzTuhq/kECluPxJYGh08f8uI4BY+5Bf7d3IyVBDgObc3xe5TP0F+Ww=
X-Received: by 2002:a1c:bc8a:: with SMTP id m132mr1132800wmf.1.1594317809027; Thu, 09 Jul 2020 11:03:29 -0700 (PDT)
MIME-Version: 1.0
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> <ACC64884-309D-45E2-8679-37C27E228A2B@mnot.net>
In-Reply-To: <ACC64884-309D-45E2-8679-37C27E228A2B@mnot.net>
From: Ben Schwartz <bemasc@google.com>
Date: Thu, 9 Jul 2020 14:03:17 -0400
Message-ID: <CAHbrMsB3JFP0kPr0TXk+5oB668yunzmrhYeBLb7bz6P7wz-0Sw@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
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-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000b3830b05aa060a3a"
Received-SPF: pass client-ip=2a00:1450:4864:20::334; envelope-from=bemasc@google.com; helo=mail-wm1-x334.google.com
X-W3C-Hub-Spam-Status: No, score=-20.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1jtatd-0006PB-R5 837d5874e3f7305643c55771bc3f7068
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/CAHbrMsB3JFP0kPr0TXk+5oB668yunzmrhYeBLb7bz6P7wz-0Sw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37864
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>

FYI, I've written a proposed change that avoids using "origin" for this
purpose, and emphasizes the connection to URIs:
https://github.com/MikeBishop/dns-alt-svc/pull/204.  Comments welcome.

On Wed, Jul 8, 2020 at 1:47 AM Mark Nottingham <mnot@mnot.net> wrote:

>
>
> > 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>gt;, 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/
>
>