Re: [Ietf-dkim] x= and DKIM replay

Steve Atkins <steve@wordtothewise.com> Wed, 02 March 2022 20:10 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 4C9F43A0C3E for <ietf-dkim@ietfa.amsl.com>; Wed, 2 Mar 2022 12:10:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDh9kSwbvIyD for <ietf-dkim@ietfa.amsl.com>; Wed, 2 Mar 2022 12:10:11 -0800 (PST)
Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id DB6CB3A0ABA for <ietf-dkim@ietf.org>; Wed, 2 Mar 2022 12:10:11 -0800 (PST)
Received: from smtpclient.apple (unknown [37.228.236.130]) by mail.wordtothewise.com (Postfix) with ESMTPSA id C2D299F149 for <ietf-dkim@ietf.org>; Wed, 2 Mar 2022 12:10:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1646251811; bh=PF3k5w4oZEkKYxxz+R00IuFouBOrrPuVzD4Esi5EozE=; h=From:Subject:Date:References:To:In-Reply-To:From; b=NHewuNhGQfIat96ELJ2bN4mXOmGp4XCSdbPX60L+N5hFO3ka9bniSa+B2aGViKZrQ /cnkSehqorIevSVYUDtjjGfg+HPQ3LBFt6hBeaL0USly9Ov8EWBB/uTtUF/ONc4gzS Q+/QgJZdY4notHVGTGnl+VynKpqfmxPvRhurmSuw=
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 15.0 \(3693.20.0.1.32\))
Date: Wed, 02 Mar 2022 20:10:07 +0000
References: <CAPxNA7gHd7NPi8fZk3OgTY5H7ewLVBu9HSpJLMrR2v8tnfe7+g@mail.gmail.com>
To: ietf-dkim@ietf.org
In-Reply-To: <CAPxNA7gHd7NPi8fZk3OgTY5H7ewLVBu9HSpJLMrR2v8tnfe7+g@mail.gmail.com>
Message-Id: <BF263774-5129-4D8A-BCD8-5EFFD3FD7232@wordtothewise.com>
X-Mailer: Apple Mail (2.3693.20.0.1.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-dkim/xBcYs9WcYX-vkTg3pCkrN5DQZCg>
Subject: Re: [Ietf-dkim] x= and DKIM replay
X-BeenThere: ietf-dkim@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 02 Mar 2022 20:10:18 -0000


> On 2 Mar 2022, at 19:42, Evan Burke <evan.s.burke@gmail.com> wrote:
> 
> 
> Hi,
> 
> I'm reading the section in rfc6376 on the x= tag, specifically - 
> 
> INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay defense.
> 
> Could anyone shed some light on the reasoning for this, by chance? I note that the spec for x= says "Signatures MAY be considered invalid [if past expiration]", which isn't particularly strong guidance for how verifiers should behave, but from my perspective, signature expiration could in theory be an effective tool (among other defenses) to help reduce the viability of replays.

I think the reasoning was that a malicious replay attack could get a signed message and resend it very quickly, much quicker than the 90% bounds of how long it takes a typical bulk message to be queued and delivered - so setting expiration soon enough to prevent a malicious replay attack would also invalidate a lot of normally delivered mail.

So x= can’t be used to defend against competently handled, intentional replay attacks.

If I recall correctly (and I may not, it was a long time ago) the sort of lazy replays we’re seeing now weren’t really part of the threat modeling. Is x= potentially useful there? Could be.

It’d be worth looking at - whether DKIM checkers enforce it, what the spread on message sign time vs delivery time is, what the delay between original delivery and replay is. And whether the folks currently doing replays are likely to modify their behaviour if x= has any effect on them. I’d hate to roll out yet another mechanism that damages reliability of legitimate email while being trivially avoided by senders of malicious email.

Cheers,
  Steve