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

Paul Hoffman <paul.hoffman@icann.org> Sun, 09 May 2021 23:26 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 25AA23A249D for <dnsop@ietfa.amsl.com>; Sun, 9 May 2021 16:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 1IeI6eq4dqdA for <dnsop@ietfa.amsl.com>; Sun, 9 May 2021 16:26:45 -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 B74C93A24A8 for <dnsop@ietf.org>; Sun, 9 May 2021 16:26:45 -0700 (PDT)
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa5.dc.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 149NQhmI031065 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <dnsop@ietf.org>; Sun, 9 May 2021 23:26:43 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; Sun, 9 May 2021 16:26:42 -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; Sun, 9 May 2021 16:26:42 -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+mA
Date: Sun, 09 May 2021 23:26:41 +0000
Message-ID: <F4CE48A1-7AB0-45D0-97FF-158CE3A04EE1@icann.org>
References: <CAKW6Ri4EwbH8fNgXZtSot4mU9Y4K3ktX7sRoAOxhmndpRUeBNg@mail.gmail.com> <0822E56B-E118-4BB9-964A-822750EBD6A1@nohats.ca>
In-Reply-To: <0822E56B-E118-4BB9-964A-822750EBD6A1@nohats.ca>
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=_DD5A888B-CCB3-411A-9247-0F596670FF3F"; 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-09_14:2021-05-06, 2021-05-09 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GCSjJfeC-bvBkQRONQxpn0-8ybU>
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: Sun, 09 May 2021 23:26:59 -0000

On May 9, 2021, at 11:26 AM, Paul Wouters <paul@nohats.ca> wrote:
> This is all pretty terrible. I agree with Tim that we should not inflict this onto the users. Or perhaps we can already pre-allocate some CVE numbers for the security issues this will generate.
> 
> Keep the record simple, we are not going for Turing complete here. I recommend to authors take this discussion as advise to improve / simplify this aspect of the draft.

I don't think this request is actually doable. The requirements for the SVCB Rdata are:
1. Must be entered by the zone operator as ASCII text (not all a jumble of hex values)
2. Is a list of key/value pairs
3. Values are likely to be a list of items

Given these three things, it seems that there will *always* be an escaping problem for the item delimiter in #3. In the current draft, the item delimiter is a comma, so there has to be a way to escape a comma that is in an item. Few types of items would ever need a comma in their values. If a different character is chosen for the item delimiter, it too will need to be escaped.

If I'm wrong about this being as good as it can be, there must be an item delimiter that is better than a comma. I am not thinking creatively enough to figure out what might be better than a comma. I'd be happy to hear proposals for a better item delimiter. 

--Paul Hoffman