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

Dick Franks <rwfranks@gmail.com> Tue, 04 May 2021 19:09 UTC

Return-Path: <rwfranks@gmail.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 C38223A0DFC for <dnsop@ietfa.amsl.com>; Tue, 4 May 2021 12:09:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=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=gmail.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 JAGnLUlpI0UF for <dnsop@ietfa.amsl.com>; Tue, 4 May 2021 12:09:03 -0700 (PDT)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 B3CA63A0E02 for <dnsop@ietf.org>; Tue, 4 May 2021 12:09:02 -0700 (PDT)
Received: by mail-il1-x12e.google.com with SMTP id c3so7277652ils.5 for <dnsop@ietf.org>; Tue, 04 May 2021 12:09:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=i2d9xVpusl1Aklqdp/O18imK7xnBRvWQwvtrK8lqAuM=; b=lSiof0ouc1EPjRc6YPbFXoqRH84DZytDO43NteXYYroq/cj5qassLqLHgSDX/86LJM pVpfH/7gMgkx5TH4Ca3WDgNh6LtA7aOQMcc11z9/p7QGI6L+qAyHgRc6b1p5ACtZPz9n oYglEpXmKZtV6gdJ9AoyhDwif4vfsUQ013pq9Kg247hc+h6VowTSkCLI4fNW9aeGSMyM ZuFCKeZczgdhyodCq3ZilfJoqIKRQtG2McwT1vYBVwSNmRzSiZOFriXfNk4jRdnxDJau HVk1eHOuw3vLRv7sy7cVeffeA0DOMwds8G3k7TCqxEDWFdKonTGu6mV3o8zle6ULs/wI EnKg==
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:content-transfer-encoding; bh=i2d9xVpusl1Aklqdp/O18imK7xnBRvWQwvtrK8lqAuM=; b=SPeDg2cCuIoyz0ZTZRONsGOXHPt5NJmGvOxkeAe2D7KZBgQTeKR0JCP7uxAYIXHkf/ nZwldb1g9+bbX26BfXjn/O184eml5sfTJrxw04lSUZt4WCir488BhF3A8BPMI7aeCzUU X5YQFJS9cwvn5C8BAxSu/7vkCvu5BfnD66XL2PitstUz7VxlLdeKQ4qDWGpKMUUNDk9k C34sybsf8s1ibLsRlgLYA7CJMZ+HRg0u4KGvX23NB6VCrxGnGczSOaDp+4Tlc4F0TTPA bVwKI+mOWncIH/KPT2fIc7BUJ/kOoAD7ATiVW2z/vw6mwg/wkd4eiQb7xbO2EfZ3ke8r LTBg==
X-Gm-Message-State: AOAM533m9XBuvMJGBDCg18cGN5eEXhQP5O2OGX6UF5tdgQ5RQeWasGNY LeqoXfUIyCadlAAzy73e6PXhD8dglahBajZNVm1rVOS6gOM=
X-Google-Smtp-Source: ABdhPJzFw3/6E6HlvPx7nYqxmw1DWBfJtbgQ43dg0wiRlsn9zwzeA8Dmg1Zh6kaMlTubjNWVMLLoCoHvfre832yTTuM=
X-Received: by 2002:a05:6e02:685:: with SMTP id o5mr12211980ils.93.1620155341137; Tue, 04 May 2021 12:09:01 -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>
In-Reply-To: <CAHbrMsDNUKzYC__R1z6yzt_9xxyp4Eov1FekumT9sDpFkmPVPw@mail.gmail.com>
From: Dick Franks <rwfranks@gmail.com>
Date: Tue, 04 May 2021 20:08:25 +0100
Message-ID: <CAKW6Ri6bybyLTZOPFjR=Gpus96OYz1_DcxsJe8r+K9u7z=_LXQ@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Cc: Ben Schwartz <bemasc@google.com>, Mark Andrews <marka@isc.org>, Paul Hoffman <paul.hoffman@icann.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Hsoem4RfclHM_7frfqXVzQtdsZU>
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 19:09:14 -0000

On Mon, 3 May 2021 at 18:23, Ben Schwartz <bemasc@google.com> wrote:
>
> The purpose of this two-layer escaping is to allow key-independent tokenizing of SvcParam values.  For example, I just wrote an implementation of the parser that works as follows:
>
> 1. Tokenize
>   a. Scan forward looking for whitespace or "=".  This is the key name.
>   b. If "=" was found, run the standard char-string parser.  Its output is the SvcParam presentation value.
> 2. Create a SvcParam representing (key name, value).
>   a. Choose a value parser based on the key name.
>     - Parsers that use the "value-list" pattern call a subroutine with a tiny chunk of escaping logic for handling backslash and comma.
>   b. Run the parser on the value.

Thanks for the explanation.

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.

>
> 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, inflicting your questionable design choice on other
developers who opted for a different strategy.

>
> For the administrators, this all seems likely to remain irrelevant.  There is no known use case where escaping is or will be used in a value-list element.  The functionality is defined only to preserve ALPN as 8-bit-clean, as requested by some TLS experts, but there will likely never be a defined ALPN that contains these characters.

If you truly believe that, then the pragmatic solution is to accept
the unfortunate fact that your implementation is limited to
value-lists not containing escaped commas.  The residual risk that
someone, somewhere, will discover a need for an escaped comma is
likely to be small.  At worst, you will need to revisit your design,
at best you need do nothing at all.

For the sanity of all concerned, SVCB should adhere to the same
standard RFC1035 escape conventions as the other 50+ RRTYPEs.

Regards

--Dick

>
> On Sun, May 2, 2021 at 5:27 PM Mark Andrews <marka@isc.org> wrote:
>>
>> I agree with you Dick, but some developers complained that they "couldn’t
>> re-use their string parsers" (despite no existing parser supporting key=“value”)
>> so now we have to double escape backslashes.  I very much feel that this is tail
>> wagging the dog.
>>
>> > On 3 May 2021, at 01:25, Dick Franks <rwfranks@gmail.com> wrote:
>> >
>> > All,
>> >
>> > I have considerable difficulty with these test vectors at the end of
>> > Appendix D.2:
>> >
>> >        16 foo.example.org. alpn="f\\\\oo\\,bar,h2"
>> >        16 foo.example.org. alpn=f\\\092oo\092,bar,h2
>> >
>> >        \# 35 (
>> >        00 10                                              ; priority
>> >        03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target
>> >        00 01                                              ; key 1
>> >        00 0c                                              ; param length 12
>> >        08                                                 ; alpn length 8
>> >        66 5c 6f 6f 2c 62 61 72                            ; alpn value
>> >        02                                                 ; alpn length 2
>> >        68 32                                              ; alpn value
>> >        )
>> >
>> > which appear to be incompatible with RFC1035 5.1 paragraph 10:
>> >
>> >        Because these files are text files several special encodings are
>> >        necessary to allow arbitrary data to be loaded.  In particular:
>> >
>> >        ...
>> >
>> >        \X          where X is any character other than a digit (0-9), is
>> >                    used to quote that character so that its special meaning
>> >                    does not apply.  For example, "\." can be used to place
>> >                    a dot character in a label.
>> >
>> >        \DDD        where each D is a digit is the octet corresponding to
>> >                    the decimal number described by DDD.  The resulting
>> >                    octet is assumed to be text and is not checked for
>> >                    special meaning.
>> >
>> > The intention appears to be to include (a) a single arbitrary octet in
>> > the argument, and (b) a plain text comma not being a delimiter in the
>> > argument list. The specimen result is consistent with that assumption.
>> >
>> > Armed with the weapons supplied by RFC1035, the obvious way to
>> > represent such an argument is:   alpn="f\092oo\,bar,h2"
>> >
>> >
>> > A parser adhering strictly to RFC1035 zone file escape conventions:
>> >
>> >        #!/usr/bin/perl
>> >        use Net::DNS 1.31;
>> >        use Net::DNS::ZoneFile;
>> >
>> >        my $zonefile = new Net::DNS::ZoneFile(\*DATA);
>> >        while ( my $rr = $zonefile->read ) {
>> >            $rr->print;
>> >        }
>> >        exit;
>> >
>> >        __DATA__
>> >        rfc1035-compliant.example.  SVCB    16 foo.example.org.
>> > alpn="f\092oo\,bar,h2"
>> >
>> > produces the desired wire-format image:
>> >
>> >        rfc1035-compliant.example.  IN      SVCB    ( \# 35 0010    ; 16
>> >                03666f6f076578616d706c65036f7267 00         ; foo.example.org.
>> >                0001 000c 08665c6f6f2c626172026832 )
>> >
>> > Other parsers are available.
>> >
>> >
>> > The test vectors, as written, appear to rely upon somehow reactivating
>> > the special meaning of the escape character which is explicitly
>> > disallowed by RFC1035.
>> >
>> > The result in each case is:
>> >
>> >        non-compliant.example.      IN      SVCB    ( \# 37 0010    ; 16
>> >                03666f6f076578616d706c65036f7267 00         ; foo.example.org.
>> >                0001 000e 06665c5c6f6f5c03626172026832 )
>> >
>> > the escaped escape characters being inserted as uninterpreted text per RFC1035.
>> >
>> >
>> > Dick Franks
>> > ________________________
>> >
>> > _______________________________________________
>> > DNSOP mailing list
>> > DNSOP@ietf.org
>> > https://www.ietf.org/mailman/listinfo/dnsop
>>
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>>