[Ietf-dkim] Thinking About DKIM and Surveillance

Jon Callas <jon@callas.org> Wed, 02 October 2019 19:29 UTC

Return-Path: <jon@callas.org>
X-Original-To: ietf-dkim@ietfa.amsl.com
Delivered-To: ietf-dkim@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 04805120052 for <ietf-dkim@ietfa.amsl.com>; Wed, 2 Oct 2019 12:29:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=callas.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 74PRxn1_DnRA for <ietf-dkim@ietfa.amsl.com>; Wed, 2 Oct 2019 12:29:29 -0700 (PDT)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F48120867 for <ietf-dkim@ietf.org>; Wed, 2 Oct 2019 12:29:29 -0700 (PDT)
Received: by mail-pf1-x430.google.com with SMTP id q12so11080580pff.9 for <ietf-dkim@ietf.org>; Wed, 02 Oct 2019 12:29:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callas.org; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=mYLnUTOsW2x+tGI5rb4LMPKKP7AXfM9rTqAmLaBymPY=; b=Iv+hhjUxP/h/YhqIg9t27jOPpvyr5zf4Cuq3TjmROIyrGuojwar7N1XhHHZIiWPY7B t60E/elAmhupPn78+IOmbUgy+seR1serYHunaNcuoZsR/lnrmH1aR4A8L0CvRUJlC/u0 CMExtRKODy4i/bej96ZlX/vOUdb4o3Bmc/CHEo8nTtdwIVUbR0/3s0drUxOIb7cU+lPD 9hA2fZH0pxLLmEDfNOhYjVbTQkVNj83Clky4G8vtaYrMyUj4pL+y0JYOeNhSfvjghkIP xl/67H6+KkeIiaAthjWwm7b5hhRV5HqkDWv99jkdUPmc6ByORwlIDQT+0y+EIcM/32wt SbrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=mYLnUTOsW2x+tGI5rb4LMPKKP7AXfM9rTqAmLaBymPY=; b=H1x2otFw/AeZabUX9HR95Yz8oRubVxcfDA2jSG+BaA9Q6EEhkPc7OXmZ9pF12QRQfO vD9mRytC8AYuM6m3M6aNALsA38rvouzF6XpQCOvZAYZ21dFDiX9VZc5TbOEi9EP+Jg2C +Jf7GrT0tUrOtZfLZ285ltXzJIsTCeIgQw0O83PnIQqDGcjcigkXWztP3r4J9PfVuWZS bbzmdzZ2sfH6/LxJ11i2xNfLnWCB6/mzIIiuZVxkaNhdb/z8hEfuV1KUA64r7dv815Tt htns3aW+T+npcIv2iEhlcfJ5tHwSV6i3A8q+vL9AVxpZqmMZG+TuQVoSnEsUgX9tvEzV LE0Q==
X-Gm-Message-State: APjAAAVzaNOQgjxElJB/rRYMTnho6Vs9Rv35Kj4EkX5031fopT31TxLJ jB3VhFQMzGot32wa5bAB/ogFaFBbF4GL3w==
X-Google-Smtp-Source: APXvYqwERlV9PEqt9txi9yKfexbXaSsTB4vplDIejkKd0cXG9rZNIo/gh353USCQYNBptUNVdGpJhw==
X-Received: by 2002:a62:4e0f:: with SMTP id c15mr6587408pfb.42.1570044568052; Wed, 02 Oct 2019 12:29:28 -0700 (PDT)
Received: from [] (67-207-120-150.static.wiline.com. []) by smtp.gmail.com with ESMTPSA id m22sm167102pgj.29.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Oct 2019 12:29:27 -0700 (PDT)
From: Jon Callas <jon@callas.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <B0CC594E-7B2A-46D2-BEBD-C4E20FF6D1D6@callas.org>
Date: Wed, 2 Oct 2019 12:29:25 -0700
Cc: Jon Callas <jon@callas.org>
To: ietf-dkim@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-dkim/eWKbWdYmkX_d2ki_lAbczVSj8qY>
Subject: [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 19:29:31 -0000

I know that I've written about this before, so please bear with me a bit. A continuing concern of mine is the way that DKIM contributes to overall surveillance smog that the Internet has.

When we designed DKIM, this was something we considered; it was a concern. It wasn't so big a concern that we thought it should derail DKIM, and it wasn't even a concern when it was taken over by the IETF. Nonetheless, it was an issue, is an issue, and becomes a bigger issue nearly every day. The most notorious failure here is the Podesta email dump, where the stolen emails were verified against the DKIM signatures. This is precisely what we didn't want to happen -- that DKIM was used for things beyond fighting inauthentic emails. We ought to do something, the question is what. 

When I think about how to reduce the tracking and surveillance issues, the solution space includes: (1) Better management of the keys (e.g. lifecycle management of some sort); (2) Better management of the emails (e.g. strip out surveillance-friendly headers in an MDA between the MTA and MUA -- think procmail filter that removes information leaks); (3) Better crypto. If I wave my magic wand and can cause software to appear and be deployed, I'd do them all. None of them are perfect. A crawler that would collect all DKIM keys would blunt the benefits of better key management; building and deploying better header handling is a huge task; better crypto needs an addendum to the DKIM standard.

Nonetheless, I recently came across an interesting article, "KeyForge: Mitigating Email Breaches with Forward-Forgeable Signatures". It's on the IACR eprint archive at <https://eprint.iacr.org/2019/390.pdf>. I think that everyone here should look at it. The TL;DR is that they have a signing mechanism that blunts attributable signatures and introduces some interesting new concepts. They call it, "Delayed universal forgeability." Yes, that's vague, and it's my point; consider that an advert for the paper. It's an interesting way to look at better crypto that allows for spam-fighting without open-ended tracking.

I don't know that their solution is the answer, but I do know that it's asking the right questions. In 2005-7, we were concerned about surveillance smog, but we didn't have a good answer (or even consensus, but this was pre-Snowden). The stated answer of the day was proper key management of keys, but it's not clear that anyone has ever deleted a DKIM key out of DNS. (Okay, I'm exaggerating for effect.) They have very good comments about that; I'm not sure I agree, but I really like what they're saying. We also briefly considered some sort of ring or group signature to blunt attribution. That a mediocre mitigation at best, and one of our core goals was to boil the crypto down to essentials, using bare keys rather than certs or any other uniforms for the keys. It's DKIM, not DCIM.

I think their signatures take that *intent* -- a mix of math and operation -- and creates something really worth considering. Even if it's not the answer, the questions that we punted on in 2005 are vital for 2020 and beyond.

Thus, any discussion of it is good. I really liked it. Please read it.