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

Bob Harold <rharolde@umich.edu> Tue, 24 September 2019 14:24 UTC

Return-Path: <rharolde@umich.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA96C120147 for <dnsop@ietfa.amsl.com>; Tue, 24 Sep 2019 07:24:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=umich.edu
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 8lGKuu_1P23r for <dnsop@ietfa.amsl.com>; Tue, 24 Sep 2019 07:23:59 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 1322212001A for <dnsop@ietf.org>; Tue, 24 Sep 2019 07:23:58 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id 72so1564205lfh.6 for <dnsop@ietf.org>; Tue, 24 Sep 2019 07:23:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5zL/f3tAa5Owd/R4xC6iBWk219d8M5fv8WeL8TPVPHA=; b=NSEvncaYDoR3NhORomJgUjEZjKECZo6HXF5Laj6tEbHdqANmN1jrQstrfY5DVAKhtj j6Q6j56p0w5l89w/mWZfq7WWz/buxqBY+mBIu1cqmscIFT9R+0l/lTGxFq8b6xwcGKV8 Li4bX7nJUaxx1y0yqXR615HRcxcKZwNv1OKNCyrNWdvNgwKzIc5B1JHG3Sht4UiYYrhJ zr88tXDzzBmTMnYYddpraDpU82unTt4qb9U8JTDyEZRgrTpSY4cdzRTmK+3qbBqa8D4b Mgq3Q7PisCQ5aNE9KZXojqpmnpRERt+XYex90peu7A4MoqmgtZ8egv23M+L+Ya/A/rm2 /6UQ==
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=5zL/f3tAa5Owd/R4xC6iBWk219d8M5fv8WeL8TPVPHA=; b=a3sqbbYCpdCFZcOz2a/3Kwh9AJXB7VATUd8SYrVKQyhNC/IVpVE61tKJJRWYdFaUu9 Fa+SR8pyF0EIJ53wplXzvMusSLOsZxPpZ4KERw/du49xuS6L4+Ae4lNUEGNty1xRF1/H DEEGjAl/x2VuUdlVIupFpjbLpP0KIPIW437XyjqKoqJHz4SHFOCj+mEe0CgWbSRt+klc K+fBlAg2ALsUQyhBJL20Hjl4bgPZJrPhWZyX6H2fLRUnAl2GWhBT0uh//J3D8u2hzUio vIux+g12MuKYIiCfVrUH3nXtbpL5Vhm3ItIew/uibYiUvuz+5DDKJpzeI4swjnPMH87U 0Tpw==
X-Gm-Message-State: APjAAAX5sH+TqznMcZ7UkBgqPWegY1gkrCI3MqIAbxDQYgEhnvaIG9KV XzNCaRgDVHa3wFLNRxAAkRSsrL2Rv5hExX4yJzqyLA==
X-Google-Smtp-Source: APXvYqwl7EHOvWFf7QzQdhLrowJwQLwLOaBu1vZJqpTFqEYAZz7/GU1jyoj1w7qh4t7F20fhhUlXt1gnMlS+Ac/jj8U=
X-Received: by 2002:a05:6512:202:: with SMTP id a2mr2020845lfo.175.1569335036886; Tue, 24 Sep 2019 07:23:56 -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: Bob Harold <rharolde@umich.edu>
Date: Tue, 24 Sep 2019 10:23:45 -0400
Message-ID: <CA+nkc8CS+GtExP_UUPLAp2fU2kPR8qYAFqXUiU+pxT547OoiUw@mail.gmail.com>
To: Erik Nygren <erik+ietf@nygren.org>
Cc: dnsop WG <dnsop@ietf.org>, Ben Schwartz <bemasc@google.com>, Mike Bishop <mbishop@evequefou.be>
Content-Type: multipart/alternative; boundary="00000000000068570105934d4927"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QJvrkrK4ICAgsg1hiBd_D3bdCwM>
Subject: Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Sep 2019 14:24:03 -0000

On Tue, Sep 24, 2019 at 9:18 AM Erik Nygren <erik+ietf@nygren.org> wrote:

> 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>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
> (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".
>

Looks good to me, hope it gets used!

Several places have text like:

4. DNS Server Behavior
2.
"If at least one record is in AliasForm, ignore all other SVCB records in
the RRSet."

While the records must be 'ignored', it might be noted that they must still
be included in the DNS response, if DNSSEC is in use, so that the
signatures work, I think?

And my opinion - it should encourage use of DNSSEC.

-- 
Bob Harold