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

Paul Wouters <paul@nohats.ca> Mon, 10 May 2021 21:38 UTC

Return-Path: <paul@nohats.ca>
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 5DAC13A2C00 for <dnsop@ietfa.amsl.com>; Mon, 10 May 2021 14:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 49mVyuTKc7i7 for <dnsop@ietfa.amsl.com>; Mon, 10 May 2021 14:37:54 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 41A483A2BFA for <dnsop@ietf.org>; Mon, 10 May 2021 14:37:54 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4FfDtR4x3lzKKP; Mon, 10 May 2021 23:37:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1620682671; bh=JHVHp6U9FK4/DIBTHiIZ0Yno+x2XWLwZOeWIEV1JWW4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=axb4MH7itc8psua3xg5Kz38BsL3cxlJJuF134BtJDerLUCeoMIOVkcrsbT1Qxhari ifjbCr32s8wjUe+EBCt3vzTOICZXiEuBq5xOkYDnmbBLSsAKySlYTz4zuX6Mk9LmjQ nG5fPBsV29XWPh/zJ2Q7NK4rqiVJ9FR6sc8A3vkI=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id gBtj3SNhT9Nx; Mon, 10 May 2021 23:37:50 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 10 May 2021 23:37:50 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3D65F573D8; Mon, 10 May 2021 17:37:49 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 39DFC573D7; Mon, 10 May 2021 17:37:49 -0400 (EDT)
Date: Mon, 10 May 2021 17:37:49 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <CAHbrMsD+uiaYQ8i58VRjF=3AtW9uAoAtgbKzNzrPZC3QCmD2pQ@mail.gmail.com>
Message-ID: <66f2b379-3c83-f096-8067-db5c5a9d8b0@nohats.ca>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/j2NVy6rF3f-T35DRU1-rxUCAkTY>
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 21:38:00 -0000

On Mon, 10 May 2021, Ben Schwartz wrote:

> It would also require a dramatic rewrite of a specification that is now widely deployed.

The IETF is not a rubber-stamp factory for corporate proposals though.

The tendency for corporation to bring up something at the IETF that is
"too far gone" for modifications during the IETF process as a trend
is worrying, and does make me personally feel less sympathetic towards
those kind of deployments.

Did you reach out to SecDir for an early review request? I cannot find
anything in the SecDir archives related to HTTPSVC or SVCB.

DNS records have been using _prefix labels for a while now to split up
RR information to be more specific related to targetted DNS requests.
This RR type is unfortunately not using that, and thus the complexity
and securtity issues are popping up now.

> To see why I favor two-pass, consider a SvcParam whose wire format value is defined to be CBOR, represented as JSON in the zone file.  JSON is defined as UTF-16, and allows strings
> containing any character from the Basic Multilingual Plane.  It also allows various kinds of backslash escaping including " \" " for quotes within strings, and "\uD834\uDD1E" for
> extended unicode codepoints.  A one-pass parser must somehow integrate this into the flow of zone file parsing.  The easiest way is to simply disable all RFC1035-style escapes

Or to simply disable all JSON/COBR/UTF-16 et all ? Do we really need
emoticons in our transport definitions ?

> I also think these behaviors would be confusing to users, who would have to try to understand how this new integrated escaping works in order to author zone files

If that is the main argument, what's wrong with plain ascii limitations?

Anyway, I think this issue deserves a full discussion, without taking
into account the current wide deployment. Also bacause everything out
there that does not support SVCB also continues to work, so it is not
the end of the world if SVCB needs to go through some changes. But
as Mr.Abley said (and I paraphrase) "we can burn an RR type allocation
easilly".

Paul