Re: [Ietf-dkim] DKIM issues (tag "v=DKIM1", tag "p=")

Steve Atkins <steve@wordtothewise.com> Tue, 16 May 2023 14:35 UTC

Return-Path: <steve@wordtothewise.com>
X-Original-To: ietf-dkim@ietfa.amsl.com
Delivered-To: ietf-dkim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF33C1524AC for <ietf-dkim@ietfa.amsl.com>; Tue, 16 May 2023 07:35: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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT1IjmXMF-_P for <ietf-dkim@ietfa.amsl.com>; Tue, 16 May 2023 07:35:54 -0700 (PDT)
Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DD9C1522DA for <ietf-dkim@ietfa.amsl.com>; Tue, 16 May 2023 07:35:53 -0700 (PDT)
Received: from smtpclient.apple (unknown [176.61.50.187]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 469929F21A for <ietf-dkim@ietfa.amsl.com>; Tue, 16 May 2023 07:35:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1684247750; bh=N0HN4b8+LEL/1Xg3Y9nJDLMFZrmt90aiexHoVkFw+B8=; h=From:Subject:Date:References:To:In-Reply-To:From; b=WGfn5gz10914XVfEtc3SDn/wGUCcxgjs+XETggShjOliVyhTDtcbDgb6u+L0tYuHc dMSMx/ExndAYwReicHapoBTBMLmtclrP6K5H7Ip+YDdYB5+pj7/2iWb5OViptzZf7U Pz1srR0xt+A5oA1C3bCvN2YT4ISFcZ3qM/CWqw/I=
From: Steve Atkins <steve@wordtothewise.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
Date: Tue, 16 May 2023 15:35:38 +0100
References: <e2afdc9b-3c71-a045-8fff-0cd9095a8464@dusatko.org> <C6C00692-2B0B-41DA-9E8E-48044F8AF24C@wordtothewise.com>
To: ietf-dkim@ietfa.amsl.com
In-Reply-To: <C6C00692-2B0B-41DA-9E8E-48044F8AF24C@wordtothewise.com>
Message-Id: <8BE1BF5F-8D73-4D68-A34D-05AC0957D6CF@wordtothewise.com>
X-Mailer: Apple Mail (2.3731.500.231)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-dkim/0abInXJ6Te7VgGI2_wgcnNzPCI8>
Subject: Re: [Ietf-dkim] DKIM issues (tag "v=DKIM1", tag "p=")
X-BeenThere: ietf-dkim@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DKIM List <ietf-dkim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-dkim>, <mailto:ietf-dkim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-dkim/>
List-Post: <mailto:ietf-dkim@ietf.org>
List-Help: <mailto:ietf-dkim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 May 2023 14:35:58 -0000


> On 16 May 2023, at 15:16, Steve Atkins <steve@wordtothewise.com> wrote:
> 
> 
> 
>> On 16 May 2023, at 15:00, Jan Dušátko <jan=40dusatko.org@dmarc.ietf.org> wrote:
>> 
>> Hi,
>> I would like to ask how you feel about the possibility of changing the conditions for DKIM keys stored in DNS. Best in some future RFC release about DKIM itself. I have a practical experience during review and cleaning of thousands of domain, which is exhausting. And discussion about that keys also with 3rd party is sometimes hard. In situation that you would like to discuss that, I can provide kind of examples.

(hit send too soon).

The historical reason for v=DKIM1 not being mandatory, AIUI, is backwards compatibility with DomainKeys keys. There are still people out there signing with DomainKeys, and there are still people using DomainKeys public keys to sign with DKIM.

While it would be nice for it to be used the only way to require it would be to make any mail signed with a public key without v=DKIM1 fail it’s DKIM signature. That would cause a lot of legitimate, signed mail to suddenly be unsigned, and that’s not going to happen.

You can mechanically recognize TXT records as potentially valid DKIM keys, even if they’re not published under the _domainkey zone, by looking for a p= field that is either empty or contains a base64 encoded value that’s a valid rsa key (or other type as defined by the k= field). If it has that then it’s usable as a DKIM or DomainKeys key.

Cheers,
  Steve

>> 1) At this moment, the use of the tag "v=DKIM1;" is only RECOMMENDED and if this tag is used, it must be the first. Unlike, for example, SPF and DMARC, this is not a REQUIRED (MANDATORY) record. In case of an attempt to identify DKIM records, then there is a situation where it is not possible to determine which records are DKIM keys. Often, these keys are in other places where they allow to create CNAME to the expected location of the selector. These locations may be application dependent or may be with third parties configuration. From my perspective, MANDATORY record "v=DKIM1;" could help to identify DKIM keys much easily.
> 
> A DKIM key will only ever be found in DNS under a name of the form <selector>._domainkey.<something_else>. If you find a TXT record under a name like that it’s either a valid domain key record, or it’s invalid. No other sort of TXT
> record will live there. See section 3.6.2.1 of RFC 6376.
> 
> If you publish wildcard TXT records then you may end up inadvertently publishing other TXT records underneath the _domainkey record. Don’t do that.
> 
>> 2) Is it possible to specify precisely under which conditions the DKIM key is valid? Some third party records contain only an empty record "", others contain only revoked key like "p=" or it is a reference to a non-existent record. Unfortunately, RFCs do not provide unambiguous information on under which conditions this record is invalid. From my perspective, use of non-existing records or empty strings can draw that key useless, but rules specifying that in RFC or BCP will be welcome.
> 
> It must be a TXT record that lives under the hostname I described above, and it must contain a (possibly empty) p= field. An empty TXT record is not a valid DKIM public key.
> 
> It’s - obviously - possible to create a TXT record of that form that’s unusable. A DKIM validator will return a not signed result in that case.
> 
>> 3) The "p=key" information containing the key material information encoded by Base64 should occur in the key exactly once. I did not find a condition in RFC for the existence of this record.
> 
> Section 3.2 of RFC 6376 says “ Tags with duplicate names MUST NOT occur within a single tag-list; if a tag name does occur more than once, the entire tag-list is invalid.”
> 
> Section 3.6.1 of RFC 6376 describes the p= value as REQUIRED.
> 
> So there must be exactly one p= in a valid DKIM public key (in text format, as would be published via DNS, anyway).
> 
>> I found only information on implementation behavior, when "p=", i.e. an empty key material, is considered revoked. However, it is not unambiguous whether this approach is acceptable. Also specification of that rules can make my life much easier.
> 
> Cheers,
>  Steve
>