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

Ben Schwartz <bemasc@google.com> Thu, 06 May 2021 18:11 UTC

Return-Path: <bemasc@google.com>
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 AFD8F3A2B58 for <dnsop@ietfa.amsl.com>; Thu, 6 May 2021 11:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 Pa5K-E6bc528 for <dnsop@ietfa.amsl.com>; Thu, 6 May 2021 11:11:16 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82423A2B56 for <dnsop@ietf.org>; Thu, 6 May 2021 11:11:15 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id o127so3858489wmo.4 for <dnsop@ietf.org>; Thu, 06 May 2021 11:11:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e5t9S+C7JOuOcu0859ItwkBSrBSLZ0N58riGZbAFiDE=; b=COwVdoZddPBMMOfTbMb3+xMoR5nCD/PDKD03qpB7kFq6Iadv6JWfQr4CfA1rdjPK+x Hrjg1KUIGSFLpCO/oRfsM/vz/hNAPjRt5MwHr+7mY7JVVX91AiUDWxTWmoT2tpROiaoB XBrqpNv7uWonPLxk7WBey55EZZc6Djpcua6c/GmmhIoVp7QrcK+qAWpYF8d/Uy3SqZIC i17jOfTji4Qar/ZM9F3AH81Iezx0N3zdv/XuylLlWfaFno3yOAWCL+Y2k8eI12bTPaiD zxR0YVb7H1J8X9+JrRt2WryAqzVzi00rFB16bz4usil5R58W/xpuePEhz0I1EO2EuEO/ lXnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e5t9S+C7JOuOcu0859ItwkBSrBSLZ0N58riGZbAFiDE=; b=pQmWGSsPQzx0B3cpce2/W6vPhOdd56KN/R8QKvkmzfv2C2dhCUFVAv5aeiWTrMQO/O ej4dckpiTNuuralnXmIBAYX0rGk8ApTHRRc5GFRAVcAwkgyB6eIeW8xcIHu67Pgq497X +J4scMkNNCIgbTvgcoF6Vpg09Ls3ZlOFnhe5tBN/zo/R6vjH0IEWi286dOAWf3rNVTyh A82rGynqs7jtMERX8Ta0jPFjgWwa/0tISSi2RsudJvBPFbS5tXOFiMvqgQkTftqGh1Zm 0omvtqbHc13p4R81yUkY+B9MwKj8CwTvymGBCtf1GGjkOU/Ju+SNxwR9gtffKUONimGw igxA==
X-Gm-Message-State: AOAM533RyQvgvdm/FhWOdKofy4EnhIYKE+FwNMDJXYPaPoqxYEtrT9Jd EF83+/RjgNWZsI8eaWe+gIxysAz+/v5h73CNDUMKHQ==
X-Google-Smtp-Source: ABdhPJwTwlv3IfZekDJVC+Kld6HOcMDYQIKT3M+h3GHdYVqPALDrs+LCjOK2SFtDaCb8QUS05Fe9IDopiN+++siJYsU=
X-Received: by 2002:a05:600c:3388:: with SMTP id o8mr16469016wmp.101.1620324672822; Thu, 06 May 2021 11:11:12 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAKW6Ri6HWTv_7_qcJX5mnxJODfwGsDmc1X2UW4kxPi=ZfZBDcA@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Thu, 06 May 2021 11:11:01 -0700
Message-ID: <CAHbrMsCYFmmM+WfS8VQWfSvRQgp4wXHEsOJcHi3Nvunb++wuHg@mail.gmail.com>
To: Dick Franks <rwfranks@gmail.com>
Cc: dnsop <dnsop@ietf.org>, Mark Andrews <marka@isc.org>, Paul Hoffman <paul.hoffman@icann.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="00000000000092648e05c1ad3cb7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/SK6SO0QWjxkAA6UCLKy5eMkg3uI>
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: Thu, 06 May 2021 18:11:21 -0000

On Thu, May 6, 2021 at 8:50 AM Dick Franks <rwfranks@gmail.com> wrote:

> On Tue, 4 May 2021 at 21:18, Ben Schwartz <bemasc@google.com> wrote:
>
...

> >> For the sanity of all concerned, SVCB should adhere to the same
> >> standard RFC1035 escape conventions as the other 50+ RRTYPEs.
> >
> > I think that's a good description of why this arrangement was chosen.
>
> 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.

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.

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 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.

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).