Re: [Ietf-dkim] Thinking About DKIM and Surveillance

"Mark Delany" <sx6un-fcsr7@qmda.emu.st> Wed, 02 October 2019 21:01 UTC

Return-Path: <sx6un-fcsr7@qmda.emu.st>
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 CB4581200EB for <ietf-dkim@ietfa.amsl.com>; Wed, 2 Oct 2019 14:01:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.879
X-Spam-Level:
X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MISSING_HEADERS=1.021, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emu.st
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 NAvnxu3VQ6Pe for <ietf-dkim@ietfa.amsl.com>; Wed, 2 Oct 2019 14:01:34 -0700 (PDT)
Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9A88D12002F for <ietf-dkim@ietf.org>; Wed, 2 Oct 2019 14:01:34 -0700 (PDT)
Received: by f3.bushwire.net (Postfix, from userid 1001) id 0DEF13B105; Thu, 3 Oct 2019 07:01:32 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1570050092; bh=Hca19xfDlNSe4o9t+ESH66CKxBU=; h=Comments:Received:Date:Message-ID:From:Cc:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=V7MUWGGJOlwLNyO4dTX9z6EqShCXzkMnzaEgGL1Prlm9gyHGPnZ/CJ7OB6XoPQgvt ScAPWVKEZq5hY9F9SvQDcqy/MSxybmLX4a4cTCIO8puuQC6eAtKLMhnFSAK3/2uujY h5qnvYlKmG8SnsPXlCQdQPIUFum9KVdjpSEaSSnE=aSSnE=
Comments: QMDA 0.3a
Received: (qmail 10141 invoked by uid 1001); 2 Oct 2019 21:01:31 -0000
Date: 2 Oct 2019 21:01:31 +0000
Message-ID: <20191002210131.10140.qmail@f3-external.bushwire.net>
From: "Mark Delany" <sx6un-fcsr7@qmda.emu.st>
Cc: ietf-dkim@ietf.org
References: <B0CC594E-7B2A-46D2-BEBD-C4E20FF6D1D6@callas.org> <f2f17d02-ef15-1920-7d1a-a503a35b1ab5@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <f2f17d02-ef15-1920-7d1a-a503a35b1ab5@cs.tcd.ie>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-dkim/QyaQ6eS2cQ0_deFKMos3DebgwgY>
Subject: Re: [Ietf-dkim] Thinking About DKIM and Surveillance
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 Oct 2019 21:01:37 -0000

> publish previous private key values, also in the DNS perhaps

The private/public key swap idea is a nice simple way of creating
feasible key theft - not sure about plausible key theft. Probably for
a court to decide.

Key swap also won't offer much protection against email in archives or
backups which can be shown to have been plausibly created prior to
publishing the private key. A history of arrivals from a domain would
give a probably swap date so arguing against an archived domain might
be tough. For example using a public email service would not benefit
from this approach as many people in many places will have "archived"
signed email from that domain which would be easy to obtain.

Nonetheless I do like it as something very simple technically and
which is possibly of some benefit. There's a little administrative
dance as you need timing delays between last use and publishing to
protect emails in transit - perhaps a week or two, but otherwise it's
pretty trivial work.

What might give it more strength is if many people adopted key swap
otherwise a solitary Snowden-like operative publishing a private key
in an essentially obscure location on the Internet is unlikely to
convince a judge that security thru obscurity is ineffective. So if
private key publishing has legal plausibility value, then a standard
should strengthen that value.


Mark.