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

"Murray S. Kucherawy" <superuser@gmail.com> Tue, 16 May 2023 15:53 UTC

Return-Path: <superuser@gmail.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 A1D1AC37A7DA for <ietf-dkim@ietfa.amsl.com>; Tue, 16 May 2023 08:53:13 -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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XduIzjclCVR5 for <ietf-dkim@ietfa.amsl.com>; Tue, 16 May 2023 08:53:13 -0700 (PDT)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20627C37A7CB for <ietf-dkim@ietfa.amsl.com>; Tue, 16 May 2023 08:53:13 -0700 (PDT)
Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-94f9cd65b1aso389167566b.0 for <ietf-dkim@ietfa.amsl.com>; Tue, 16 May 2023 08:53:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684252391; x=1686844391; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Rcr3v/D0vFd6VrfvSHowJEKZqeOaUN5KScdvbpGn7+Q=; b=GNAxW7xTyw7HLLcy/HBVRCZSaXTtSnfttDD55Jf2NCazOQoQzrSr/+bJAUlKxBf9nu tAaxTGzopgQp8c61Tdp0daJ7tNuqCE9YLh1XS2CtSHbRPLHbjNibrLelv8ZvQZc1uBby tWz3a8jNdSL8YXaXK3Vd83oVkk9yewgWDnRakFSSKLbViWO0vQDBPnSlMaqnYldIGguX NUXUvU3ll9RvzwMx8rEIvCKw7XA0hlMWRNiQ2wNQhaxZDZiro9CumMdkeVPMIFeVwvMj Bi+7gTPUQr/HHXWfFW/1nmH776R7KYUnvd1gOBji3R+mFevBudGr/i1/OiDgcbHZIysA M6MQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684252391; x=1686844391; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Rcr3v/D0vFd6VrfvSHowJEKZqeOaUN5KScdvbpGn7+Q=; b=MY+zOqN7cvkDM0XiUwd3o5nCB7XWXnnji6cWryMC8WgB16FppVSMkSTr/sL4IcXZyG D5so2I7M0bvZIBD0z/kiqbje2NiwdlBgvNPiH9nOq9iEgqtbb45KxZaE51CFDxPrAc34 MrQGoVRSrBFPBvlXX7tQL0iaG7enQxJLppR4WCLcWfJBCVypYz1P5I/fQC4e8v9JTKtZ 5sImMIBW1UWJWrhg0XlmtRcqqos3pnlv1FJW6702ZDL86oXoCzxQuCXorMpYzN8+QpK7 jkvOAPYDKOYkfqDSrVEjyEgZF4RPgi0QKCzbOlhSuGAArygByfJ+oK5nPPYRcM0CjeoS k01w==
X-Gm-Message-State: AC+VfDzX1231dTJrTFdj9S1zC/XOypUk9SDAX90M8//Eaf2On/83Tp1f 5mVp9D4MJKts9zbF1bqF/6MTpx3ipExanr3bsOk=
X-Google-Smtp-Source: ACHHUZ7zWoPm7Vhj706qiBNh5dBMRDohKHxSDm30paa9HZg8HdopUAixsJUUdW1VyegIakdOVkliYWeCIPobp0Bf1/8=
X-Received: by 2002:a17:906:72d3:b0:92e:f520:7762 with SMTP id m19-20020a17090672d300b0092ef5207762mr2820843ejl.6.1684252390926; Tue, 16 May 2023 08:53:10 -0700 (PDT)
MIME-Version: 1.0
References: <e2afdc9b-3c71-a045-8fff-0cd9095a8464@dusatko.org>
In-Reply-To: <e2afdc9b-3c71-a045-8fff-0cd9095a8464@dusatko.org>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Tue, 16 May 2023 08:52:58 -0700
Message-ID: <CAL0qLwbDufOOKrVSj4zwKvAgpmUNU7c0sWGjS-V380q1E0X1tA@mail.gmail.com>
To: Jan Dušátko <jan=40dusatko.org@dmarc.ietf.org>
Cc: ietf-dkim@ietfa.amsl.com
Content-Type: multipart/alternative; boundary="000000000000792d1505fbd191bf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-dkim/vAl_92qwB2k9ASZ6nw9N-TPzPcY>
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 15:53:13 -0000

On Tue, May 16, 2023 at 7:00 AM Jan Dušátko <jan=
40dusatko.org@dmarc.ietf.org> wrote:

> 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.
>

I don't get the impression that identifying a record that contains a valid
DKIM key record is hard.  The ABNF is pretty clear.  It's certainly easier
to say "does this start v=DKIM1;?" than it is to run a full parser on it,
but I imagine if you try to stuff a random string through a DKIM key
parser, it'll know pretty quickly most of the time that the record isn't
valid given the second character pretty much has to be "=" which is going
to trim a lot of cruft right away.

Also, a change to make this REQUIRED would take forever for the world to
adapt.  There's a great deal of inertia out there, and the benefit of such
a change isn't going to be obvious to the broader community, so you're
going to find records in the current format for years to come, and
implementations would justifiably accept the old format for some long
transition period.

Are you talking about DKIM records out in the general Internet, or only
within domains you control?


> 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.
>

I disagree that this is ambiguous.  An empty string isn't a valid DKIM key
record.  An empty "p=" value is a valid DKIM key record indicating "there
was a key here, but it's been revoked".


> 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. 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.
>

I also disagree that this is ambiguous.  The RFC is pretty clear about what
an empty "p=" means.

-MSK