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

Paul Hoffman <paul.hoffman@icann.org> Mon, 10 May 2021 22:46 UTC

Return-Path: <paul.hoffman@icann.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 510713A2DD9 for <dnsop@ietfa.amsl.com>; Mon, 10 May 2021 15:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Hzibu_hX-XeM for <dnsop@ietfa.amsl.com>; Mon, 10 May 2021 15:46:26 -0700 (PDT)
Received: from ppa5.dc.icann.org (ppa5.dc.icann.org [192.0.46.78]) (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 849B43A2DD8 for <dnsop@ietf.org>; Mon, 10 May 2021 15:46:26 -0700 (PDT)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa5.dc.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 14AMkOR9011843 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <dnsop@ietf.org>; Mon, 10 May 2021 22:46:24 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.5; Mon, 10 May 2021 15:46:23 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0858.010; Mon, 10 May 2021 15:46:23 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: dnsop <dnsop@ietf.org>
Thread-Topic: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Thread-Index: AQHXO6R2YAMi99z2YEWrYLGKwIWwLqrQzMYAgACXiQCAARuvAIABr8mAgAAThgCAAtmpgIAAJ3GAgAAjKwCAAOvjAIAAXHqAgALkOACAAGuHgIAAU+mAgAAEbACAAQbJgIAAA2aAgAAWvoCAAGG6gA==
Date: Mon, 10 May 2021 22:46:23 +0000
Message-ID: <25971B7D-718C-42E3-8F04-2D235776C66B@icann.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>
In-Reply-To: <CAHbrMsD+uiaYQ8i58VRjF=3AtW9uAoAtgbKzNzrPZC3QCmD2pQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_5FAC7939-1D5D-4CA6-9378-1DC72D08642E"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-10_14:2021-05-10, 2021-05-10 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/OSldUhgzYk6zPHgFzlKL3DuhvvA>
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 22:46:30 -0000

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.

> 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