[Dcrup] hashing and privacy

Brandon Long <blong@google.com> Mon, 10 July 2017 23:23 UTC

Return-Path: <blong@google.com>
X-Original-To: dcrup@ietfa.amsl.com
Delivered-To: dcrup@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331E0131945 for <dcrup@ietfa.amsl.com>; Mon, 10 Jul 2017 16:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=google.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 B6X4U76gZHpi for <dcrup@ietfa.amsl.com>; Mon, 10 Jul 2017 16:23:32 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 8FE2C131757 for <dcrup@ietf.org>; Mon, 10 Jul 2017 16:23:32 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id w19so64601567uac.0 for <dcrup@ietf.org>; Mon, 10 Jul 2017 16:23:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OkUemNH3wBWTbREz1wsYl2R30OCEKMiYOk28T4FrB5o=; b=q6G2FPTojNqadQghvgT765fc9EWjXoxGOSgmtVmYyNAS6BJZfZRXEu1vVHO6WIAZRZ qILdELkK5RBIEFb9L7QhOao3R9Nm+RHGKUNyhBhwCULrj4uF7qnuB9a0N1aNU+2Tdug7 d7p7BDL2XOK+G/9XzuGIgyvQJrBih3dyCFRyYhqEMefi9cSOw0eYxHXfwhrmoyDbvZYr Pukakgdt5kfCMfExSI1WtHQtsx8wioVPVS1gPW5WUeeudFiHEPecn+Glmi5iRsBuq1ny 7lLTpIDX2F3qwHsKjdw7RvrxJovw6Cce5XtNhuH/IlceG7JIf1G+sfT8+pfYEhcH03IN EdZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OkUemNH3wBWTbREz1wsYl2R30OCEKMiYOk28T4FrB5o=; b=SWOuvrVI/NK0JGFDtYlvBONawhyyMiUvjFtpuKGGz3h5U+X5vCtIfI12xBiPWSxnrK UjKk42ou2h9/8JIs8tFQkS534q2AZ2c6wegL1EZReBxDdaWIzkhClFQ1ml4mw2NhVQV5 +THCuBhEmreKPpsplj7am4GmQQtPj29+ybDHPmG5PA884BsBXDeWxiXtYgpg3/Muiigg 62QRAv+4TZukBLrY628JT9nvBI2/kWkDiXsue2QBx+IXUsQS+E/iiIg3JzrQlTujP8M3 mNmNYk0qgAYXJUVjtsRokkKwVGmCM87liJZNlBHWVxvDcftO8FPpJ9VLBb+GUIjbauxp RzTw==
X-Gm-Message-State: AIVw112rTZiRBMqfI1R6MJb9tJJyrIpVllj2n68qIlGSDUk2T6sRg/iF o7K2dKjx2CUkzjVsm87/ET0ClXE/Dm9Xrhk=
X-Received: by 10.176.16.75 with SMTP id g11mr10327076uab.40.1499729011104; Mon, 10 Jul 2017 16:23:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.140.1 with HTTP; Mon, 10 Jul 2017 16:23:30 -0700 (PDT)
From: Brandon Long <blong@google.com>
Date: Mon, 10 Jul 2017 16:23:30 -0700
Message-ID: <CABa8R6sN+mNk82wn3z9O6vWjbqwDiTa+zn12Q2ehkAMTK8S5Og@mail.gmail.com>
To: dcrup@ietf.org
Content-Type: multipart/alternative; boundary="f403045e1d20f7d3930553fedea6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dcrup/nhnL8_uSEPRrWnV9rt10JwA1IJM>
Subject: [Dcrup] hashing and privacy
X-BeenThere: dcrup@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DKIM Crypto Update <dcrup.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dcrup>, <mailto:dcrup-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dcrup/>
List-Post: <mailto:dcrup@ietf.org>
List-Help: <mailto:dcrup-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dcrup>, <mailto:dcrup-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jul 2017 23:23:34 -0000

There has been a concern that long term DKIM keys allow for some type of
possibly privacy violation by allowing leaked data to be verified.

I'm not sure I share this concern, but if take it as a given, then the
following occurs to me for the new proposed hashing schemes.

The schemes propose that the key be always included, and the hash of they
key be available in DNS.

On rotation, the hash will be gone... but, one would be able to verify that
the key was the "right" key by looking at any other mail from the same
system at the same time.

Now, it's possible that people are already logging DKIM keys in DNS for
long term retrieval for the next one of these leaks, in which case, that
cat is already out of the bag anyways.

Brandon