Re: mail signing history, was Call for Community Feedback: Retiring IETF FTP Service

ned+ietf@mauve.mrochek.com Wed, 18 November 2020 21:41 UTC

Return-Path: <ned+ietf@mauve.mrochek.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D163A0D3B for <ietf@ietfa.amsl.com>; Wed, 18 Nov 2020 13:41:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 1Ro3IyZnjBgd for <ietf@ietfa.amsl.com>; Wed, 18 Nov 2020 13:41:40 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BFEF3A0D3A for <ietf@ietf.org>; Wed, 18 Nov 2020 13:41:40 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS5Q2O3WO000CCEM@mauve.mrochek.com> for ietf@ietf.org; Wed, 18 Nov 2020 13:36:38 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS4XGHZZF4005PTU@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf@ietf.org; Wed, 18 Nov 2020 13:36:33 -0800 (PST)
From: ned+ietf@mauve.mrochek.com
Cc: ietf@ietf.org, ned+ietf@mauve.mrochek.com
Message-id: <01RS5Q2L2D6Y005PTU@mauve.mrochek.com>
Date: Wed, 18 Nov 2020 13:26:22 -0800
Subject: Re: mail signing history, was Call for Community Feedback: Retiring IETF FTP Service
In-reply-to: "Your message dated Wed, 18 Nov 2020 16:19:36 -0500" <20201118211937.01A22278DC6F@ary.qy>
References: <01RS5CFAY5S0005PTU@mauve.mrochek.com> <20201118211937.01A22278DC6F@ary.qy>
To: John Levine <johnl@taugh.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/psBkI29T3i0IgwZL3J7Dxw7NEzA>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2020 21:41:42 -0000

> In article <01RS5CFAY5S0005PTU@mauve.mrochek.com> you write:
> >More specifically, we developed DKIM/DMARC as an anti-phishing measure for
> >commerical email. It was never intedned to be used for personal email, but
> >Yahoo deployed it in the personal email space and others have followed suit on
> >a massive scale. As a result a significant and growing percentage of email is
> >now signed, to the point where privacy experts are calling for DKIM key release
> >after rotation to at least partially mitigate the damage we have done.

> Urrgh. We correctly expected DKIM to be used for all sorts of mail,
> but without expecting the DKIM domain to match the From (other than
> the experimental and unused ADSP extension.) DMARC made "aligned"
> signatures treated specially, but the signatures didn't change.

> What we didn't anticipate is that large mail systems would never
> rotate their keys and use the same DKIM signing key for many years, so
> you can easily check old messages with old signatures. I suppose it is
> kind of a surprise that people use them for non-repudiation, but since
> the signatures aren't technically very different from S/MIME or PGP
> signatures, it shouldn't be that surprising.

FWIW, I actually pointed out this and other potential downsides of using
signatures way back when DKIM was originally standardized, but (a) We don't
have an alternative technology, or even an idea of what an alternative
technology would be, and (b) As you say, we didn't expect it to be this bad.

There's also no way to fully mitigate the issue: Someone can always immediately
apply an independent timestamping service to every message they see, making
subsequent exposure of the private key meaningless.

That said, a mechanism for publishing/expiring DKIM private keys is something
the IETF might want to standardize.

				Ned