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

[Dick Franks <[e-mail]>]

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
________________________