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

Ben Schwartz <bemasc@google.com> Tue, 04 May 2021 20:18 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 B093E3A11A5 for <dnsop@ietfa.amsl.com>; Tue, 4 May 2021 13:18:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Level:
X-Spam-Status: No, score=-17.6 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 R0YuuklQ1xK4 for <dnsop@ietfa.amsl.com>; Tue, 4 May 2021 13:18:32 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 90BF83A11A3 for <dnsop@ietf.org>; Tue, 4 May 2021 13:18:32 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id l13so9130240wru.11 for <dnsop@ietf.org>; Tue, 04 May 2021 13:18:32 -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=LbLhHXbWyAEBZ/h8Q6TK+v+GC2UI8gLvZaa7I05c6GY=; b=htGT69SEPwSwi8kckrwO4HVoRXfxxFQSNAWJrWUVCGym1Q4wyW6Tp9uvR/KaOaP5am bKwn00RDuxD8t6DwfBwlKq1o78w6LfdoOnNfvLVLzVpVKsrpLGNqVREXAq/Kv3Frds7I r4d77dldDgYJ1FF5GYYVWiMWG9Zi0r264LU91IxPVc29m3Y8g0hqpMR7rnmzWhgODtpX efthawtaXinGbh1pOR0w0U4mIDyDoOpbPL242AHGNWOIwdmQ9wcblCPE33Al4eaU9t0e 3LgUlgtShPgKWobpLOdckbFojqtqT4+W0gyMs6/Hce63DbImdztmBcuC+Tj2xeaZCexW 60XQ==
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=LbLhHXbWyAEBZ/h8Q6TK+v+GC2UI8gLvZaa7I05c6GY=; b=C2VxmMroGv+eVMuAt20mzBBRKqEl5J79mNVbWxbJbShyR6iefNwv3OLurucYRQRgUQ PQsNBpfZBQEnyb/yFl/+U53/pAPMTts8PA3Ao+zq3WUW3QCP7fvQpaoYNMCM2yiS/iWf oWGkkYIwfRocCETnJCWCFWWyV5hkZ2+CNfIcGb/j5hit349uhkl0eDmlgXm4tcOJiRdG hp7++d8ZcDX1+KmaLkEIIQ6c89i14q22M30agczGCmPx5bKBlYLYl659UFrQlQqVNXW3 7oguj+xSskY0ocDUDMocOvCaOaYd48CKlxs2lqHW5FpVLzHoT1DZ/R7E28Tst2Xb40cS EdYQ==
X-Gm-Message-State: AOAM531lCyppc24x4gK3cNXfkRlp+qUk+qdCHAnapXYjEZGQDqTaZHsC 3MCOL5YZsDnNrIBYv5K7PM+2O3YJ6Pa+Oj6EKmg86g==
X-Google-Smtp-Source: ABdhPJwg8Wp767uKqW5ALhQ7lFTL5aie6D0W/U8aX6wm2iMQcViaL7T6iky2Fgp9SUsDGM6uU3rYm6ZhZI2hOaZIrRI=
X-Received: by 2002:adf:dfd1:: with SMTP id q17mr32646082wrn.177.1620159510231; Tue, 04 May 2021 13:18:30 -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>
In-Reply-To: <CAKW6Ri6bybyLTZOPFjR=Gpus96OYz1_DcxsJe8r+K9u7z=_LXQ@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 04 May 2021 13:18:18 -0700
Message-ID: <CAHbrMsCgShoeTbSruFH_zigYtXEQEoEOihjE6kjSUmfW5VSVUw@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="0000000000001d3f1f05c186c8c9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-YTLbo8HLEbqBvWtinafLOmXQng>
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: Tue, 04 May 2021 20:18:35 -0000

On Tue, May 4, 2021 at 12:09 PM Dick Franks <rwfranks@gmail.com> wrote:

> The brutal reality is that the char-string parser has already
> obliterated the distinction between escaped and unescaped commas
> before the value-list parser is invoked.
>

Yes, hence the use of "\\," for embedded commas in value-list values.


> > If we use single-layer escaping, this arrangement is not possible.
> Instead,
> > (1) we would need to add complexity to the char-string parser that is
> shared by many RR types.
> > (2) we would need to integrate key-type-specific behavior into the
> tokenizer, complicating the interface between the parsing function and the
> SvcParams implementation.
>
> >
> > In the draft's arrangement, those implementation choices are allowed,
> but not required.
>
> By publishing test vectors including escaped escapes effectively makes
> these required,


To be clear, it is the text of the document, not the test vectors, that
creates this requirement.  The test vectors merely complement the normative
requirements, which already detail this arrangement.

...

> 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.
Lifting comma-handling up into the char-string parser would result in SVCB
using a _different_ escape convention from all the other RR types.  This
arrangement ensures that, to the extent possible, SVCB uses the _same_
escaping as all the other RR types.  It also ensures that all the SvcParams
use the same basic parser.

Value-list parsing is a detail, not of SVCB, but of certain SvcParam types
within SVCB.  Consider a future SvcParam whose presentation value is
defined to be JSON.  Shall we require that the zone file parser switch to
JSON mode based on the key name, to parse jsonThing={"foo": "quote: \""}?
No, we will declare that this value is wrapped in a char-string as
jsonThing="{\"foo\": \"quote: \\\"\"}".  Yes, this is less convenient to
type by hand, but the alternative is to have a "char-string parser" that
mixes in all the syntaxes of all the SVCB value types.  That way lies
madness.