Re: [DNSOP] HTTPS and SVBC key names.

Dick Franks <rwfranks@gmail.com> Wed, 22 July 2020 20:28 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 D7C0C3A0958 for <dnsop@ietfa.amsl.com>; Wed, 22 Jul 2020 13:28:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=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 cMa1itB1SsFI for <dnsop@ietfa.amsl.com>; Wed, 22 Jul 2020 13:28:57 -0700 (PDT)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 663D33A0900 for <dnsop@ietf.org>; Wed, 22 Jul 2020 13:28:57 -0700 (PDT)
Received: by mail-io1-xd2e.google.com with SMTP id t131so3974994iod.3 for <dnsop@ietf.org>; Wed, 22 Jul 2020 13:28:57 -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; bh=FIMskQjrk9sp4wme4+0ec7Ugdf9ltKzz35PrOSAVUnY=; b=lD4l4qBHMCcWcA7kVCjCXC2ftAzyGXa/T8lg4y7n3z451abmoxFfKt/7Xs8q/SG0Ui HY4RkqGZ4vF41QkJRdg+7F3dkdahxJfV2L3Z/lnSd9CTHqu4a672143hUArrjmH1/XLq CECXvxYO96ItX8jvtxO4Mo4cm8H01Eh6FYQZv5VwdOUwmMVF4dtYs5NbAOm4VAiKatW9 llfBj1uw6yJL2pstY0jP58afAXlrc/ec9QQo48DFNOh4KMfkxZvv0OxRBJ7DNsRYfqHv RorJdYFqOhx/x85tFb2ksfZLY+kWZ+ivOLLow96Sw8TEPRqgpAq9evpCkDrIjchrr1KJ efYA==
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=FIMskQjrk9sp4wme4+0ec7Ugdf9ltKzz35PrOSAVUnY=; b=iEt1cPm0ZHtgRMcZpuRqvo1YVqrrBDdqnNLe4czwpVaZJUulbG9JGT7rw1hXXDrA8/ BjRISTldRjTLbbDu8+zu+4FsY77YCItegFlwhmCkFbv+0oRD/uN9uAFVcYnwgQ7i43WH WK+4d/eMsFk4v0lmqY3W0ZqPPkTpQ76kzYJEhbh33LKAtpvOrnHaWarTlHw8a2jIk8oa Ufhoq0h8ihqeQiJ7zDqeuNGjEl2suQAjlgbcLEUY5HVpnRY+RqL+I3ttrsTb47Zu4aA9 DbHpoLW8eIoODtdLZapjXefFzg109lsDEeMfsbMv4vvMtXzLsVfLXW2jG740OIh/9Vbr 277w==
X-Gm-Message-State: AOAM5315lWPW86qCpZi3stgF1BY0kq7f+KrnpU4pMcdsNQl/Ijk5AloL V+d5P5OFhbNjTvuLzHHxlODJvByr59WAXWKxH2E=
X-Google-Smtp-Source: ABdhPJxNaCRyGx94SWiiQcRUg1wzrB8CzEgulxqcqJkbQC+VuZ3qY/+n5myrL0eo5ESe4jTHUtJFm0oVX8MGd1WlZFI=
X-Received: by 2002:a02:aa1b:: with SMTP id r27mr998808jam.89.1595449736615; Wed, 22 Jul 2020 13:28:56 -0700 (PDT)
MIME-Version: 1.0
References: <23FA2BA0-43B9-49A3-B288-3ADFCE1D1DB1@isc.org> <CAHbrMsDOyTXyJydro8enSePy9COOfK7AVL6Pqv94YGAGhg41Hg@mail.gmail.com> <CAKC-DJiBw7vDr_KA1sb+ephuagRCT84f1B0PGXJptPiZTh2CSg@mail.gmail.com> <CAN6NTqxGLF0tZ17TX8jy2YWPf=qHhW93=fKETJ4kScJbQUUgxw@mail.gmail.com> <CAKC-DJiMngJonCp2EPrHTWMHwV0VAGquf733YcTZ9JSTFtwAhA@mail.gmail.com> <CAH1iCipbR9D_Tqc4dW5zARpEgjZ=-b3d6ZywPzo0=jfBedppYw@mail.gmail.com> <CAKW6Ri7K7efEj81nKJq7W0MKyn9rDOL7bLt-zVUokodVfrjAwA@mail.gmail.com> <CAHbrMsC-5wvxsmrzHnrnfUZOG1wQsGmEF2m2jMt4a5vieK7Nyg@mail.gmail.com> <CAKW6Ri7aF0knx2SFJgx4OxxVJfeNWYJ3pJBmxXQH+UMZ0P4_Rw@mail.gmail.com> <CAHbrMsBTnFmJdj9KYfzGajKmbWJ1+XF_f8BGMPnLy=MFAhCygg@mail.gmail.com> <CAKW6Ri7Cmt43uH_yV0Hjz64b3PynR9WS3NgLf5YZ1K9kwEzXFg@mail.gmail.com> <CAHbrMsC2rpKL8WA-bwHMGaiNoC-NGNY3JVu7SAShFxPWBOU9kA@mail.gmail.com>
In-Reply-To: <CAHbrMsC2rpKL8WA-bwHMGaiNoC-NGNY3JVu7SAShFxPWBOU9kA@mail.gmail.com>
From: Dick Franks <rwfranks@gmail.com>
Date: Wed, 22 Jul 2020 21:28:20 +0100
Message-ID: <CAKW6Ri7boAZyTB662AC2f7yLFGPC7v2EMDTBwD7V2OTcvF1ScA@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
Cc: dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cedc2f05ab0d96c4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UpPwYUoScdgYsBybaKRotWOTWzA>
Subject: Re: [DNSOP] HTTPS and SVBC key names.
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: Wed, 22 Jul 2020 20:28:59 -0000

On Mon, 20 Jul 2020 at 22:54, Ben Schwartz <bemasc@google.com> wrote:

The unknown-key format is designed more for authoring than reading.  As an
> author, it works somewhat better than your example.  For instance, your
> key1 could be written as
>
> key1=\005h3-29\005h3-28\005h3-27\002h2
>

It is not as easy as you might think.  This all needs to work on EBCDIC and
UTF8 platforms.
I plan to kick the problem into the long grass for now.

 That seems more intelligible than hex or base64.

Am I correct in thinking that the key5 base64 is decoded at RR creation,
not by the eventual consumer?

In short, the unknown-key format is fairly usable for authoring fields
> whose values are plain text or numeric octets, since a human author can
> choose escape codes or ASCII characters as appropriate.  A renderer (by
> definition) has no idea what the contents mean, so it can work well for
> plain text or numeric octets but not both.
>

Exactly!   Which is why I am where I am.

With the addition of comments for the recognized keys and fields, I think
> you're probably right.  However, when authoring a zone file I would hate to
> have to use RFC 3597 hex for the whole record just to add one key that my
> parser doesn't support yet.  Also, if most future keys turn out to have
> ASCII plaintext values (e.g. URLs), an unknown key renderer that uses ASCII
> symbols where possible might turn out to work quite well.
>

I am not suggesting that you fish about in RFC3597 format.

If you are authoring from scratch than you can use this form:

my $rr = new Net::DNS::RR <<'END';
    example.net.        300     IN      HTTPS   1 target.example.net.
        alpn=h3-29,h3-28,h3-27,h2
        no-default-alpn
        ...
        key65333=...
    END

If thou coverteth thy neighbour's RR in RFC3597 format (contrary to Exodus
20:17), there are the necessary tools to modify it:
        $value = $rr->keyNN();          # access a value (in your favoured
format)
        $rr->keyNN($value);             # assign a value
        $rr->keyNN(undef);              # delete a key

--Dick

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