Re: [DNSOP] meaning of tag "match" for CAA RDATA

神明達哉 <jinmei@wide.ad.jp> Wed, 07 February 2018 22:15 UTC

Return-Path: <jinmei.tatuya@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 D8EA5126CC4 for <dnsop@ietfa.amsl.com>; Wed, 7 Feb 2018 14:15:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 cb1NP9woFcG7 for <dnsop@ietfa.amsl.com>; Wed, 7 Feb 2018 14:15:53 -0800 (PST)
Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 CFB49124F57 for <dnsop@ietf.org>; Wed, 7 Feb 2018 14:15:52 -0800 (PST)
Received: by mail-wr0-x22c.google.com with SMTP id v31so2694748wrc.11 for <dnsop@ietf.org>; Wed, 07 Feb 2018 14:15:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=YyZWhJfmwqBecy+SxEFIdt//VRFNX35XskVt0SomPIA=; b=AD5qYLJ0W0UNlp83WaLRo0uSUyV6vdmfjSEnxdis8hSZokofN3x2ZG17qPOTPZtmoK FtZp6BmFRy3F4OFMzxwbW1r+Dv9QAVptpswtlJASPlwxUCyis0rDEzEMSaND+lFnAndG gMisrWABuFIotfyUPuW1WU8gM8UefbRhT4k3Yca0AP9x8kMPFw0r/OPvQcMLSyEmeUc3 4tjRTEPh/r9UKeSY6vIW+WFd0yVwf3SuCrwysupvcdMk/lZy/DbWL2cyAmQ+36ukd55c hQ4s9hRi9Ydvt8dE+d0QO/P1OozXzn8rz4XbxK+fV8JBsTjuOiA+JeGd/AFV01hbsj+Y acMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=YyZWhJfmwqBecy+SxEFIdt//VRFNX35XskVt0SomPIA=; b=cpyQXEMAWU7z1wXrq79ix4IkrhPzFzIpq7DeeInnkTMXrSp5QCKxtTLuXUF0gwqfAH SeLszlS74FINibDDwHp1MLKW0Usz3jo3M7WrtaP0RfzE02IZeAOUmlrzV3Fe4F+IFyJB Tj1C4PxyXjP/7KwU29WsTcvYUxeajZDZy2usoge5vuYnAsXiB3zdCVV5XF9JyU3KI5lB 5Omq3M2ScWiZXooCR/T6nkO7A6+3fkddCy9wiufXQ/rd2WXjwRjXFnUKNWRy2DlbXHhx /cuXkOxt4rdMmm+rBeC+KPIVK/bx/J502CsPb4RxO2sgSIZT/YyA3lL2rJhvgybAH62/ SC2w==
X-Gm-Message-State: APf1xPChFvjN70uxo2KCi/6GO5kvnH9WGrdMLbejCZzf08ULBbyHE5dd DSnTkkJf7Q57qbC7Op2gRRAVKKS1wyWLVZPXUOi3J1FC
X-Google-Smtp-Source: AH8x22674LafxkwV/58HHK0uGpf0XVL15Xr1HStNy+x+7HSlcCF2NA8NCJaMhNGDNNxIotMfT80oAO3JYXDHkjzvx1Q=
X-Received: by 10.223.161.15 with SMTP id o15mr6482208wro.274.1518041750908; Wed, 07 Feb 2018 14:15:50 -0800 (PST)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.223.133.189 with HTTP; Wed, 7 Feb 2018 14:15:50 -0800 (PST)
In-Reply-To: <1965473E-CDB6-44F9-89E0-33B12DF8D34E@isc.org>
References: <CAJE_bqfEvy6-YovKCrtXxm81ieGPTBxpLk2NDuq115eHk3xmEg@mail.gmail.com> <1965473E-CDB6-44F9-89E0-33B12DF8D34E@isc.org>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Wed, 07 Feb 2018 14:15:50 -0800
X-Google-Sender-Auth: UN4B7sBJXhie9b2GWyq8LDEO8og
Message-ID: <CAJE_bqfQ2Lon6=m_Yc0-6+XxUng4ChiuhUNrMhwh1qgCJGEbfw@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/K-e-XnJSSBRiGihoi1Ok9-Pva5M>
Subject: Re: [DNSOP] meaning of tag "match" for CAA RDATA
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 07 Feb 2018 22:15:55 -0000

At Thu, 8 Feb 2018 08:25:35 +1100,
Mark Andrews <marka@isc.org> wrote:

> > I happen to have this question while reading RFC6844: what does the
> > "matching" mean in the following description of Section 5.1?
> >
> >   Tag:  The property identifier, a sequence of US-ASCII characters.
> >
> >      Tag values MAY contain US-ASCII characters 'a' through 'z', 'A'
> >      through 'Z', and the numbers 0 through 9.  Tag values SHOULD NOT
> >      contain any other characters.  Matching of tag values is case
> >      insensitive.
[...]
> > Does this mean, for example, we should perform case-insensitive
> > comparison of this field when we compare CAA RDATAs?  (If so, at least
> > ISC BIND 9 isn't compliant to the spec; it doesn't care about the case
> > of the tag field when loading or serving or updating or signing a CAA
> > RR).
>
> Why should it care about the case? ABC is different to abc as far as
> DNSSEC and handling of unknown record types is concerned.  A signer
> that is CAA aware could remove “duplicates” that differ in the case
> of this field but nothing else can.

I didn't intend to say it (DNS implementation) should care about the
case.  My point (or question) was the RFC text can be ambiguous.  On
re-reading RFC3597 I now see it would clearly violate Section 6 of
RFC3597:

   specifications for new RR types MUST NOT specify
   type-specific comparison rules.

if it meant case-insensitive RDATA comparison.  But the current text
of RFC6844 made me think whether the RFC erroneously violated it or it
meant something else.  It would have been clearer if "Matching of tag
values is case insensitive" were somewhere after Section 5.1, or at
least it explicitly said this is about CAs that use the CAA, not for a
DNS implementation.

I'd also wonder what the "Canonical Presentation Format" means then:

   Tag:  Is a non-zero sequence of US-ASCII letters and numbers in lower
      case.

so, for example, we can't always safely dump a validly loaded zone
containing CAA whose tag has an upper-cased letter into a file in the
"canonical presentation format" and then re-load it, since the dump
can result in false duplicates.

...and now I see there was almost exactly the same discussion about 2
years ago:
https://www.ietf.org/mail-archive/web/dnsop/current/msg16810.html

Perhaps it's pretty clear that the current text of RFC6844 is very
confusing (if not wrong) and worth some errata again?

--
JINMEI, Tatuya