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

Tom <tom@nlnetlabs.nl> Fri, 07 May 2021 07:57 UTC

Return-Path: <tom@nlnetlabs.nl>
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 ECB023A0F61 for <dnsop@ietfa.amsl.com>; Fri, 7 May 2021 00:57:21 -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, HTML_MESSAGE=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=nlnetlabs.nl
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 zZBJhsqZPos7 for <dnsop@ietfa.amsl.com>; Fri, 7 May 2021 00:57:17 -0700 (PDT)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 466173A0F44 for <dnsop@ietf.org>; Fri, 7 May 2021 00:57:16 -0700 (PDT)
Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 7707960EF2; Fri, 7 May 2021 07:57:13 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1620374232; bh=Y+kG2PySyMyXXZfKwCNaYUYGifJcvmy9SW2pEq5/Vgw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ZmP3M3dh5DMQa4yB+aKnZUnavSXLqa7XiUHgoyFBfxnlUDAsscN++9axXJBsMEMwE QmFOw0nTM7xpWqh9siKU1CWtptptOgOQBJGyo615PTcRFqeBeT240nis6D30aypkoM Y2/qzJIEEEm1gDPeX31AAMPeekT2JyAwXaOndU1jPXnAnineHONINDG+LpGrb7Z+WD Wp015GnuKbQV4X6SErMUyTYI4K5vKCda1wfD0UBC39O3GrBTqo0xayh6yYIXYX/V0n igXnX4K4jiOzucqhz0zI9FaChSkvRqt+JRTHzsnYKnDduYqe50kGu8zJyZJBv3VMgu nhZE9Ybfw935g==
MIME-Version: 1.0
Date: Fri, 07 May 2021 09:57:10 +0200
From: Tom <tom@nlnetlabs.nl>
To: Dick Franks <rwfranks@gmail.com>
Cc: Ben Schwartz <bemasc@google.com>, dnsop <dnsop@ietf.org>, Paul Hoffman <paul.hoffman@icann.org>
In-Reply-To: <CAKW6Ri6BPXPeb_jExwoUk2MNccCVTwPTZRahqSouEUcMeskA=g@mail.gmail.com>
References: <161901308063.21005.875603362157576926@ietfa.amsl.com> <CAHbrMsA4TMfE+3LAT+un0FF3DGXKsYB1zAtvUwf2YKr97mJ+sQ@mail.gmail.com> <87B615B4-9CA3-4060-93C2-E4B953C11FB2@akamai.com> <CAHbrMsDaqrQ+XDO4z395tC_yOH4MBH8OmoH8zTXWEHfcDC1+Ew@mail.gmail.com> <6245BB4F-4E2F-435F-ABC0-18C0420C8541@akamai.com> <CAHbrMsDGq0usDiqr0HtbFCR4Y8swtyv_0i7UOFf=C_ExW+0FNQ@mail.gmail.com> <303AD4A1-A9BE-4C31-B730-7B4D42587206@akamai.com> <CAHbrMsCj8OToEhjo7O0YkW4WGosGK7stBYTneYHUoX_KckY7Uw@mail.gmail.com> <80539395-F1F6-4BA1-8AFF-667DDF7604B1@icann.org> <CAHbrMsAC3Mb+e18Gv361XnCU3kBOWqCbUXPujuuqOULh4e-v=g@mail.gmail.com> <CAKW6Ri4Yi2v+owa7KABATBoRmEB9u0k_hxd235iDL0ngbGhuLA@mail.gmail.com> <B0F5B473-9A40-447D-9555-F549F54CE0B5@isc.org> <CAHbrMsDNUKzYC__R1z6yzt_9xxyp4Eov1FekumT9sDpFkmPVPw@mail.gmail.com> <CAKW6Ri6bybyLTZOPFjR=Gpus96OYz1_DcxsJe8r+K9u7z=_LXQ@mail.gmail.com> <CAHbrMsCgShoeTbSruFH_zigYtXEQEoEOihjE6kjSUmfW5VSVUw@mail.gmail.com> <CAKW6Ri6HWTv_7_qcJX5mnxJODfwGsDmc1X2UW4kxPi=ZfZBDcA@mail.gmail.com> <CAHbrMsCYFmmM+WfS8VQWfSvRQgp4wXHEsOJcHi3Nvunb++wuHg@mail.gmail.com> <CAKW6Ri6BPXPeb_jExwoUk2MNccCVTwPTZRahqSouEUcMeskA=g@mail.gmail.com>
Message-ID: <09c0c6161abd82389e65d9820fa5a4e0@nlnetlabs.nl>
X-Sender: tom@nlnetlabs.nl
Organization: NLNet Labs
Content-Type: multipart/alternative; boundary="=_7b1e90ded4be8c508f5ae57610807775"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Sk2sXjVeyOEr1qTL_2wVOOOgYjI>
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: Fri, 07 May 2021 07:57:22 -0000

Hi Dick, Ben,

I'm the (new) developer at NLNet Labs who implemented SVCB in NSD. While 
I have no strong opinion on the double escaping matter, I will pitch in 
that NSD currently adheres to the draft (as far as I'm aware).

Best,
Tom

On 2021-05-06 22:16, Dick Franks wrote:

> On Thu, 6 May 2021 at 19:11, Ben Schwartz <bemasc@google.com> wrote:
> On Thu, May 6, 2021 at 8:50 AM Dick Franks <rwfranks@gmail.com> wrote: 
> But that is precisely what you are NOT doing.
> You have assigned a special significance to the character sequence
> "\\," contrary to RFC1035.
> 
> The language of RFC1035 is crystal clear that an escaped character is
> parsed as plain text, independently, without regard to context, and
> that any special meaning does not apply.
> 
> Strict application of the RFC1035 rules causes string   "...\\,..."
> to be equivalent to "...\092,...".
> 
> I'm not sure what you're describing.  Those two inputs are universally 
> equivalent in zone files under the current draft.  They are both 
> reduced to {'\', '"'} by char-string parsing, which is applied 
> uniformly and without modification to all SvcParamValues.

... and the '\' without any special meaning fails to protect the comma
from the attention of the argument splitter.

> Each SvcParamValue has its own input format.  For some SvcParamValues, 
> '\' and ',' may not be allowed characters.  For others, they may be 
> ordinary characters to be copied into the output, or they may have 
> special significance.
  ... and I might, or might not, have a boiled egg for breakfast!

>> BIND, NSD, and Net::DNS are all able to arrive at implementations of
>> SVCB using the RFC1035 standard escape conventions, which demonstrates
>> beyond reasonable doubt that recognising "\\," is not an essential
>> requirement.
> 
> I disagree: what you are proposing is a deviation from RFC1035 escape 
> conventions, and what the draft does is specifically to ensure that no 
> such deviation is required.

I am advocating strict adherence to RFC1035 escape conventions.  You
are the one proposing to deviate.

> ...  I have now encountered multiple codebases where modifying the 
> RFC1035 char-string parsing in the way that you suggest would be 
> prohibitively complex, and that complexity will only grow over time as 
> new SvcParamValues are defined.

If the development cost is prohibitive, the obvious solution is to use
BIND, NSD, or one of the other respectable implementations which are
certain to be not far behind.  If Google cannot afford the license
fee, a six line perl Net::DNS script could be used to translate
RFC1035 compliant SVCB RRs into RFC3597 format at nil cost.

> The "value-list" format is a bit like a (much simpler) cousin of the 
> SPF macro language (https://tools.ietf.org/html/rfc7208#section-7.1).  
> In both cases, the char-string decoder's output contains embedded 
> commands that allow the next processing stage to distinguish between 
> delimiters (comma and space, respectively) and escaped delimiters ("\," 
> and "%_", respectively).

That is no justification at all.   SPF people can do whatever they
like within the arguments of a TXT record.

--Dick

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop