Subject: [Dcrup] hashing and privacy

From: Brandon Long <[email-masked]>
Date: Mon, 10 Jul 2017 16:23:30 -0700

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Jul 2017 16:26:14 -0700

On Mon, Jul 10, 2017 at 4:23 PM, Brandon Long <[email-masked]> wrote:

> 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.
>

I'm not sure I follow the attack you are proposing here. Can you walk me
through the exact flow?

-Ekr

> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup
>
>

---

From: Brandon Long <[email-masked]>
Date: Mon, 10 Jul 2017 16:40:42 -0700

> I'm not sure I follow the attack you are proposing here. Can you walk me

Wikileaks drops a large number of raw email messages with DKIM signatures
using a hashed algorithm.  Each message has the key in it, which can be
used to verify the individual message has not been tampered with.  If the
DKIM key was rotated, then the hash in DNS no longer matches the key in the
messages, so all that can be proven is that they match the DKIM signature
on the message.

If, however, the domain had been already widely emailing with individuals,
then you can look at your own message archive to find out that all of the
messages in that time frame also had the same DKIM key in the message.  You
could even verify this with a large collection of people who also received
such messages.

Does that answer your question?  Or are you asking about why this is a
privacy attack?

Brandon

---

From: denis bider <[email-masked]>
Date: Mon, 10 Jul 2017 18:09:37 -0600

I think an ability to verify the authenticity of leaked messages is a
feature, not a bug.

If the "leakee" is honest, it protects them more than it hurts them. It is
easy to show if a "leaked" message was tampered with to try and make it
more damaging.

And if the "leakee" is dishonest, it benefits society more if they do not
have "protection".

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 11 Jul 2017 00:17:03 +0000

True or not, that doesn't make it a not a privacy concern.

Scott K

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Jul 2017 17:19:56 -0700

On Mon, Jul 10, 2017 at 4:40 PM, Brandon Long <[email-masked]> wrote:

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

And your point is you would need to otherwise archive the key out of the
DNS to verify that two messages were sent by the same person?

In that case, I would want to be sure that that's actually a property that
digital signatures have.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Jul 2017 11:31:35 +1000

> In that case, I would want to be sure that that's actually a property that

My understanding is that (for RSA at least) given a message and
signature it is possible to create a key that will produce the same
signature.  See the attacks on ACME.  The absence of key might lead to
some uncertainty about whether the message was originally signed by X,
or someone else.  Including the key removes that ambiguity, because it
is included under the signature.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Jul 2017 05:54:48 -0700

> is included under the signature.

I wonder if that property holds for >1 signatures.

-Ekr

---

From: "John Levine" <[email-masked]>
Date: 11 Jul 2017 16:51:03 -0000

>cat is already out of the bag anyways.

Given the existence of long term passive DNS, I am quite certain that
people are logging DKIM keys in the DNS for long term retrieval, with
or without wikileaks, so I don't think hashing makes things any worse.

Two other observations:

One is that in practice hardly anyone ever rotates DKIM keys, so this
is currently a largely hypothetical issue.  When Wikileaks released
the gmail messages from DNC staff, it was easy to verify the DKIM
signatures because gmail was still using the same DKIM key a year
later.

The other, due I think to Stephen Farrell, is that if you want to
invalidate a key, you can poison it by publishing the public key.
Since the point of that is to prevent interoperation it's not
something that would go in a standards track document, but I suppose
we could informally suggest that when you revoke a key by blanking
out the p= public key tag you add a pk= tag with the public key.

R's,
John

PS: I know the public key will not fit in 256 octets, but tough.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Jul 2017 12:38:04 +1000

> I wonder if that property holds for >1 signatures.

I don't know.  My intuition is that it is hard, but I can't really back that up.

Whether that matters depends on what you are trying to defend.  If I
give you a collection of messages with the claim that they are all
from the same sender, it would be hard for an attacker to include a
message that was signed by another entity even if the key wasn't
signed.  On the other hand, anyone can claim that they signed any one
of those messages unless the key was covered.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Jul 2017 12:39:48 +1000

> out the p= public key tag you add a pk= tag with the public key.

I assume that pk= private key?

> PS: I know the public key will not fit in 256 octets, but tough.

Private key here as well?

---

From: "A. Schulze" <[email-masked]>
Date: Tue, 18 Jul 2017 17:13:32 +0200

> invalidate a key, you can poison it by publishing the public key.
s/public/private/ ?

that make all future signatures denyable, or does it also capture old sigs?

> out the p= public key tag you add a pk= tag with the public key.
what does the standard say about unknown key "pk=",
"key must be not used" or "key must be ignored"?

> PS: I know the public key will not fit in 256 octets, but tough.
Yea, a published private key is no longer under operational restriction

Andreas

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 18 Jul 2017 15:20:41 +0000

Once the private key is published, all signatures can be forged.

---

From: "John R. Levine" <[email-masked]>
Date: 20 Jul 2017 12:31:07 +0200

On 11 July 2017 at 22:54, Eric Rescorla <[email-masked]> wrote:
> signature.

DKG pointed out that an easy way to divide the baby here is to make the k= 
tag optional for all signatures and mandatory for hashed ones.

If you're worried about this attack, put the key in the dkim-signature 
header. If a verifier wants to check that it matches the key in the DNS, 
it can do so.

R's,
John

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Jul 2017 13:48:03 +0200

This is a fine suggestion.

On 20 July 2017 at 12:31, John R. Levine <[email-masked]> wrote:
>> My understanding is that (for RSA at least) given a message and signature
>> it is possible to create a key that will produce the same signature.
>
>
> header. If a verifier wants to check that it matches the key in the DNS, it
> can do so.
>
> R's,
> John