Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Mark Andrews <marka@isc.org> Mon, 10 May 2021 23:14 UTC

Return-Path: <marka@isc.org>
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 A21633A2E91 for <dnsop@ietfa.amsl.com>; Mon, 10 May 2021 16:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=isc.org header.b=XUFb6hRG; dkim=pass (1024-bit key) header.d=isc.org header.b=Eh0UEJjF
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 Rn5oKDd9Ew7a for <dnsop@ietfa.amsl.com>; Mon, 10 May 2021 16:14:31 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 BEB453A2E90 for <dnsop@ietf.org>; Mon, 10 May 2021 16:14:31 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 09A863AB027; Mon, 10 May 2021 23:14:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1620688469; bh=zMqzS9g417/sxMNXKkFJbqeZbxL1b4c6JJUVViZwPWE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=XUFb6hRGT1mrUs8gNC65LS4MQ8EJ9iiME+yA9XJ0VcwlaD/xmuK3ea5qHCpbgS0Xp dGxlX+uGbVGgI2r9VFJrA/gz90OceblIg51PiWqjokxC3hS7pQNcDFdq0RGLrotc9C lc6Tehd70Zn2KC906KFXrcGCwuaM31C+pDKNuoK0=
Received: from zmx1.isc.org (localhost.localdomain [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id EF7AB160099; Mon, 10 May 2021 23:14:28 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D825F160090; Mon, 10 May 2021 23:14:28 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 zmx1.isc.org D825F160090
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1620688468; bh=3YjtNXiD/7379uxXN0cumgBAwS5l2UPzbAUrhYM2c+4=; h=Content-Type:Mime-Version:Subject:From:Date: Content-Transfer-Encoding:Message-Id:To; b=Eh0UEJjFt/GIVOpW5v/hYU7UiucSzjJWMNB2lyaAr2qNRyamTR3fipEFXsUYlMTNy Z0F75Bzr9k204M+GhjhHt2ZunLIdCKn5j4QqTvAOg9uFQTvH7SPWXl/fU3Q7T44ej0 uFdu/0oySst+k2DHmL2qA+rQtXY6QKVw8COGQW2E=
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vWJHoWlKE--n; Mon, 10 May 2021 23:14:28 +0000 (UTC)
Received: from [172.30.42.67] (n49-177-132-25.bla3.nsw.optusnet.com.au [49.177.132.25]) by zmx1.isc.org (Postfix) with ESMTPSA id 06BE316008D; Mon, 10 May 2021 23:14:27 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <25971B7D-718C-42E3-8F04-2D235776C66B@icann.org>
Date: Tue, 11 May 2021 09:14:25 +1000
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4312DB4B-A9E0-48E8-BD79-7358080065F4@isc.org>
References: <F4CE48A1-7AB0-45D0-97FF-158CE3A04EE1@icann.org> <3EE971EE-0777-44D6-9CD2-771B92FFE938@hopcount.ca> <1d822219-8ab9-2cb7-d0a4-9b8afc39058d@powerdns.com> <2952D408-117B-40D0-B859-7A8E4111629E@hopcount.ca> <CAHbrMsD+uiaYQ8i58VRjF=3AtW9uAoAtgbKzNzrPZC3QCmD2pQ@mail.gmail.com> <25971B7D-718C-42E3-8F04-2D235776C66B@icann.org>
To: Paul Hoffman <paul.hoffman@icann.org>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/p_zRbY6AmNdys_iy0MxddcYjhNM>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
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: Mon, 10 May 2021 23:14:37 -0000


> On 11 May 2021, at 08:46, Paul Hoffman <paul.hoffman@icann.org> wrote:
> 
> On May 10, 2021, at 9:56 AM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
>> 
>> I don't support breaking the SvcParams into separate RRs across the RRSet.  This would be an extremely inefficient encoding in wire format, and would conflict with the usual understanding of resource records as independently meaningful alternatives.  
> 
> Fully agree. It is a large change in the DNS protocol for a receiver to have to internally group multiple RRs based on matching (priorty | target) tuples and make security decisions based on the group, not on the record.
> 
>> It would also require a dramatic rewrite of a specification that is now widely deployed.
> 
> Er, screw that. The fact that some developers deployed this even though it hadn't even completed WG last call, much less had a wider IETF review, is a problem for those developers to solve.

Actually, the process problem is that record format keeps changing AFTER the code point has been assigned and the record format THEORETICALLY been FIXED.  When you go down the template route for code point assignment that FIXES
the wire and presentation formats.

A. Submission Date:  2020-06-18

B.1 Submission Type:  [ X ] New RRTYPE  [ ] Modification to RRTYPE
B.2 Kind of RR:  [ X ] Data RR  [ ] Meta-RR

C. Contact Information for submitter (will be publicly posted):
   Name: Erik Nygren
   Email Address: erik+ietf&nygren.org
   International telephone number:  +1 617 444 3938
   Other contact handles:

D. Motivation for the new RRTYPE application.
   Please keep this part at a high level to inform the Expert and
   reviewers about uses of the RRTYPE.  Most reviewers will be DNS
   experts that may have limited knowledge of your application space.

   The "HTTPS" DNS RR type facilitates the lookup of information
   needed to make connections for origin resources, such as for HTTPS
   URLs.  HTTPS RRs 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.  By providing more information to the
   client before it attempts to establish a connection, these records
   offer potential benefits to both performance and privacy.
   For example, the presence of an HTTPS RR indicates that clients
   should upgrade insecure "http" URLs to secure "https" URLs prior
   to establishing a connection.
   

E. Description of the proposed RR type.
   This description can be provided in-line in the template, as an
   attachment, or with a publicly available URL.

   See https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-00
   
F. What existing RRTYPE or RRTYPEs come closest to filling that need
   and why are they unsatisfactory?

   (from I-D.draft-ietf-dnsop-svcb-https-00 #appendix-A)

   The SRV record [RFC2782] can perform a similar function to the SVCB
   record, informing a client to look in a different location for a
   service.  However, there are several differences:
   o  SRV records are typically mandatory, whereas clients will always
      continue to function correctly without making use of HTTPS RRs.
   o  SRV records cannot instruct the client to switch or upgrade
      protocols, whereas HTTPS RRs can signal such an upgrade (e.g.. to
      HTTP/2).
   o  SRV records are not extensible, whereas HTTPS RRs can be
      extended with new parameters, such as for
      TLS Encrypted Client Hello keys.

G. What mnemonic is requested for the new RRTYPE (optional)?

   HTTPS

H. Does the requested RRTYPE make use of any existing IANA registry
   or require the creation of a new IANA subregistry in DNS
   Parameters?  If so, please indicate which registry is to be used
   or created.  If a new subregistry is needed, specify the
   allocation policy for it and its initial contents.  Also include
   what the modification procedures will be.

   Yes, per I-D.draft-ietf-dnsop-svcb-https-00#section-12:

   * Create a new "Service Binding (SVCB) Parameter Registry"
     with an initial population of entries.  This would
     be shared with the SVCB RR type.
   * Add an _https entry to the  DNS Underscore
     Global Scoped Entry Registry.

I. Does the proposal require/expect any changes in DNS
   servers/resolvers that prevent the new type from being processed
   as an unknown RRTYPE (see [RFC3597])?

   No.  While DNS servers and resolvers may perform performance
   optimizations described in the I-D, these are optional
   and do not preclude processing as an unknown RRTYPE.

J. Comments:

   The plan is to bring draft-ietf-dnsop-svcb-https to Working Group
   Last Call during Summer 2020.  A early code point allocation
   for the SVCB RRtype and HTTPS RRtype is requested to enable interop
   testing between multiple implementations that are in-progress.


>> As for the question of commas, I continue to believe that the current text is preferable.  I believe that the behavior Dick is advocating for is in fact the one that was present in the draft until -02 [1], changed here [2].  We changed this text after receiving complaints from WG members that the algorithm as specified was too complicated, along with my own experiences attempting to implement it in multiple codebases that apply char-string decoding during or before tokenization.
> 
> This is central to the problem of SVCB: it is more complex than traditional DNS RRtypes, and different developers have different views of what would make it simpler for them to implement and/or simpler for zone operators to type into zone files.
> 
> I hope Dick's proposed simple addition is useful. I'm not a developer, and I don't write into zones very often, but I suspect that "it's all in one record that has an addition to the parsing" will be easier and safer to implement than "the receiver has to handle groups of records in a new way".
> 
> --Paul Hoffman_______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org