Re: [TLS] Fwd: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

Ben Schwartz <bemasc@google.com> Tue, 24 September 2019 15:15 UTC

Return-Path: <bemasc@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A141200B2 for <tls@ietfa.amsl.com>; Tue, 24 Sep 2019 08:15:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 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, 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_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 39f3lAKNkeSp for <tls@ietfa.amsl.com>; Tue, 24 Sep 2019 08:15:53 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 397751208EF for <tls@ietf.org>; Tue, 24 Sep 2019 08:15:52 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id a1so5347021ioc.6 for <tls@ietf.org>; Tue, 24 Sep 2019 08:15:52 -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=QKbvJ3uUb6uSibWuj75VaWg/4O4+ByU5T5w/qcd6iWo=; b=bsD35EvZmntSPjieEUlwBmgmRjJWZDIyEfz0Kx4aP/MJ7XJYrpUDRNyu9sBn3pCr+S VId9gFXhEAZ/T1oXQOQGrWnkR1v9TDOGPDDbfZtZf3e3N0L0NlPoMfH80sUQKON0Uy+I L5MGDFmINzhVtijwS0Rtth6yTPEEx5zZsdwQtVEUr1Q9RQMbRRs9SAFNQTL5v7XF6bFr TSXl1ji4qWsh+0z9dADHgyhM5EbD5Fre4ZU6ZXhDIzDluONUovHvyfC45Fk6LfSy87e2 IzJiacbS8NYNPGgFqdHS6IWuAyIMdKOECjTHFtbLuPyYjuwPisWsmClE4GkW2u55PzTV DM7Q==
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=QKbvJ3uUb6uSibWuj75VaWg/4O4+ByU5T5w/qcd6iWo=; b=BJRL6FfsJtpF9hlFE3f1uOXfP5xiKr9MSFnZ4Qnde6phLy0LAGGXoogfN8oZACSmX1 RDEcCqlcjfLf+xNUD6J6iWFTXDqXbVtH8+1H5M390CpGgiakzIr8z9gN/AsjhpUr5UKX IEwix9kJp1zOGx5TRms/aylya+bc6LJrqp5duvrSkdAFrU6AeDokq8+jOHafim223IpJ PgqKRuZ8eXARHI2etnet62la0BTdzGs0Nok8loKQ5iYlPB9FkCS3Pu3mi08DbJGnIFeX OUMxjiQR1otHNprsOYw14HhK+RmQDS7vGzQshX5YfsxrTt/PRFnY5GXFdIhg69sIBqs7 di2Q==
X-Gm-Message-State: APjAAAVtoBayURAPhWxHYwTQH2u9zI9wRY04Wd04NoI51uo06O2+SLEB OCzH+GN1nAR3uiSPo0Rtl/z6yqVwOZINCwlHXom2tHPWYGI=
X-Google-Smtp-Source: APXvYqzC+W0HYzurJJKWpP08Y8JmHd5/LX3Fa01YcUwBOr6I4xARv0w+sOxOU3p5vO2LGcbMnnxJrYTAEXDBS8ijR+E=
X-Received: by 2002:a6b:7b4a:: with SMTP id m10mr3971201iop.163.1569338151825; Tue, 24 Sep 2019 08:15:51 -0700 (PDT)
MIME-Version: 1.0
References: <156927967091.17209.1946223190141713793.idtracker@ietfa.amsl.com> <CAKC-DJi4EHz5CCAqRj_cYTVygiuo0s2QGaPLCct6e9Bh1mXaXQ@mail.gmail.com> <CAKC-DJgUt-H4-EQ3pvBL8_-UEUty3kQwTyh_Adtp3ORtiZOySg@mail.gmail.com> <571a9639-304f-8c30-efe4-d472bfd2631f@cs.tcd.ie>
In-Reply-To: <571a9639-304f-8c30-efe4-d472bfd2631f@cs.tcd.ie>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 24 Sep 2019 11:15:39 -0400
Message-ID: <CAHbrMsCkTts62L1Jhio=C9Ny-Fxw7ujYL9R-XWmROXb+-V5Htw@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Erik Nygren <erik+ietf@nygren.org>, "<tls@ietf.org>" <tls@ietf.org>, Mike Bishop <mbishop@evequefou.be>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000001bfefe05934e03d5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/r8ILejlyrqnTb7CXAyvFFMjh5Ms>
Subject: Re: [TLS] Fwd: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Sep 2019 15:15:58 -0000

On Tue, Sep 24, 2019 at 10:32 AM Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hi Erik,
>
> FWIW, if browsers preferred this to an ESNI RR and
> we could forget the ESNI RR then I'd be ok with that.
> I'm not clear if they do or not though. In the meantime,
> assuming this went ahead instead of or in addition
> to an ESNI RR, I've a few questions below...
>
> On 24/09/2019 14:21, Erik Nygren wrote:
> > Following the discussions in Montreal (as well as with some of the ESNI
> > authors),
> > we refactored the HTTPSSVC draft to make it more general.  The hope is
> that
> > it could be an alternative (or replace the need) for a distinct ESNI
> record.
>
> So I think the basic ESNI case where there's no
> name changes nor alt-svc etc would be as below in
> presentation syntax, am I reading that right?
>
>    example.com. 7200  IN HTTPSSVC 0 . ( esnikeys="/wHrAh..." )
>

For HTTPSSVC, the "alpn" parameter is mandatory (Section 7.2), so the
minimal record is

example.com. 7200  IN HTTPSSVC 0 . alpn=h2 esnikeys="/wHrAh..."

I'm also not clear if that's the exact same as:
>
>    example.com. 7200  IN SVCB 0 . ( esnikeys="/wHrAh..." )
>
> ...is it? If so, which'd be preferred or would
> clients be expected to be able to handle both?
> And I don't get why two ways to say the same thing
> are useful.
>

SVCB records are always on underscore-prefixed names, and are prohibited
for HTTP or HTTPS.  However, if you have a protocol called "example" that
runs over TLS, you could publish a record like

_8080._example.example.com 7200  IN SVCB 0 . esnikeys="/wHrAh..."

(This would require the "example" protocol to define an SVCB binding.)

Secondly, ESNIKeys currently supports versions,
> multiple keys, cipher_suites, extensions and even
> dns_extensions. And we could have >1 rrdata for
> ESNI or for SCVB/HTTPSSVC.
>
> Would you envisage adoption of SVCB/HTTPSSVC meaning
> that we could drop some of the generality that's
> present in ESNIKeys? If so, what?
>

The dns_extensions field is in ESNIRecord, not ESNIKeys, so that is
excluded.  I wasn't expecting to remove any of the other fields.

I'd like if ESNIKeys were made simpler FWIW, so if
> this had that effect, then I'd be more for it. If,
> OTOH, this just added complexity (for a library
> implementing ESNI), which currently seems to be the
> case, then it'd be less attractive, to me at least.
> (I guess I'm agreeing with Rich there:-)
>

I imagine a TLS library implementation of ESNI taking an IP address, an
SNI, and an ESNIKeys struct, as input to connection initiation.  In that
model, the choice of DNS representation has no effect on the library.

An HTTP client [library] that is using such a TLS library would be
responsible for performing the requisite DNS resolution.  This is indeed
more complex than the proposed ESNI RR type, but I believe it's a more
logically sound match for the HTTP origin model, and offers several
concrete benefits (such as triggering HTTP->HTTPS upgrade).


> Thanks,
> S.
>
>
> > The draft generalizes to a protocol-agnostic SVCB record, but also
> specifies
> > an HTTPSSVC record for the HTTP(S) use-case.
> >
> > Based on discussions with various chairs, the plan is to call for
> adoption
> > in the DNSOP WG.
> >
> > Comments/feedback are most welcome.
> >
> >       Erik
> >
> >
> > ---------- 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>, Ben Schwartz <bemasc@google.com>, 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
> > record).
> >
> > 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
> > implicit)
> > * 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
> > for HTTPSSVC).
> > * 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
> > use-case).
> >
> > 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
> > quickly.
> >
> >        Erik
> >
> > ---------- Forwarded message ---------
> > From: <internet-drafts@ietf.org>
> > Date: Mon, Sep 23, 2019 at 7:01 PM
> > Subject: New Version Notification for
> > draft-nygren-dnsop-svcb-httpssvc-00.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-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
> > (DNS SVCB and HTTPSSVC)
> > Document date:  2019-09-22
> > Group:          Individual Submission
> > Pages:          33
> > URL:
> >
> https://www.ietf.org/internet-drafts/draft-nygren-dnsop-svcb-httpssvc-00.txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-nygren-dnsop-svcb-httpssvc/
> > Htmlized:
> > https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00
> > Htmlized:
> > https://datatracker.ietf.org/doc/html/draft-nygren-dnsop-svcb-httpssvc
> >
> >
> > Abstract:
> >    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",
> >    "SVCHTTPS", "HTTPS", and "ALTSVC".
> >
> >
> >
> >
> > 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
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>