Subject: [dane] Improving DANE S/MIME Privacy

From: Alice Wonder <[email-masked]>
Date: Tue, 11 Apr 2017 10:16:04 -0700

Hello,

This is respect to DNSSEC validation for S/MIME

When generating a hash for use in DNS, the draft for DANE/SMIME 
currently only uses the username portion of the address.

The obvious (and noted) privacy implications are that someone could 
discover e-mail addresses by rainbow table DNS queries and/or zone walking.

I believe this can be mitigated.

S/MIME makes use of x.509 certificates, so I suggest using the serial 
number from the x.509 certificate as a salt with the username before 
taking the hash.

This could be done optionally rather than mandatory, though I certainly 
would want to do it on mail systems I administer.

One of the things I worry about is spammers discovering valid e-mail 
addresses through the DANE S/MIME and then using the public key of that 
user to send encrypted malware that can not be filtered on the SMTP 
servers because it is hidden.

If the serial number for the x.509 certificate is a salt for the hash, 
then spammers can not determine the validity of an e-mail address from 
DNS but those who already have the certificate can use DNS to DANE 
validate the certificate.

Thank you for your time,

Michael A. Peters (aka Alice Wonder)

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 11 Apr 2017 13:38:55 -0400

> On Apr 11, 2017, at 1:16 PM, Alice Wonder <[email-masked]> wrote:
> 
> 
> One of the things I worry about is spammers discovering valid e-mail addresses
> through the DANE S/MIME and then using the public key of that user to send
> encrypted malware that can not be filtered on the SMTP servers because it
> is hidden.

The simplest solution is to publish only "2 1 1" records in the DNS that
identify the CA that signs the user's certificate, and does not vend the
underlying public key.

Then a first-contact message to any recipient goes in the clear, signed
by the originator, along with the originator's certificate.

The recipient can then respond with an encrypted and signed message that
makes it possible for all further communication to be fully protected.

If the sender is a spammer, the recipient should not respond with a
message that enables further communication to be encrypted.

Note also that the problem you're concerned about already exists with
PGP keyservers, but the authenticity of the data on those servers has
much lower assurance.  DANE SMIMEA records are largely an improvement
on the PGP keyserver model.

If the design were up to me, I'd not have published per-user keys.
Instead a site-wide trust-anchor record scales better to large user
communities, and mostly addresses your concerns.

Of course user keys can leak by various means (posting signed messages
to a list, replying to a spammer, ...).  Preventing that entirely seems
impossible, but policy mechanisms in the MUA could make accidential
leakage less likely (e.g. not signing messages that are not addressed
to someone in the user's "address book", so a conscious manual step
would need to be taken to leak a public key that enables encryption in
the reverse direction).

Today's MUAs support End-to-End email encryption very poorly.  Much
usability work needs to happen before End-to-End email encryption
is more than a curiosity.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 11 Apr 2017 14:39:56 -0400

> On Apr 11, 2017, at 1:38 PM, Viktor Dukhovni <[email-masked]> wrote:
> 

I should note that one can of course implement one's SMIMEA deployment
in exactly this way, something along the lines of:

   *._smimecert.example.net. IN SMIMEA 2 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

would associate the same TA public key digest with every user, and would
not enable user enumeration.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 11 Apr 2017 15:15:00 -0400 (EDT)

On Tue, 11 Apr 2017, Alice Wonder wrote:

> If the serial number for the x.509 certificate is a salt for the hash, then 
> spammers can not determine the validity of an e-mail address from DNS but 
> those who already have the certificate can use DNS to DANE validate the 
> certificate.

Except the whole point of this record is to publish that certificate, so
clearly the spammers have a copy of the serial number too :)

Paul

---

From: "John Levine" <[email-masked]>
Date: 11 Apr 2017 20:01:51 -0000

>discover e-mail addresses by rainbow table DNS queries and/or zone walking.

There are a lot easier ways to find e-mail addresses, and the problem
of probing servers to see if addresses are valid has been around for
20 years.  To the extent that we worry about it at all, the mail
community has a lot of countermeasures that we needn't rehash here.

>number from the x.509 certificate as a salt with the username before 

Uh, what?  If you already have the cert, why do you need to do the
lookup?  And if you don't have the cert, where do you get the salt?

>servers because it is hidden.

This is not a new or particularly interesting concern.  Many people
have noted that with encrypted mail, all of the spam body checks have
to happen after it's decrypted.  Malware signatures are just one
example of that.

R's,
John

---

From: Alice Wonder <[email-masked]>
Date: Tue, 11 Apr 2017 15:25:15 -0700

> clearly the spammers have a copy of the serial number too :)

Okay I think my perspective on this is different.

Due to epilepsy, I do not drive and require more sleep than most people 
and frequently must lie down. Not conductive to a good income, so I 
never used S/MIME simply because I did not want to pay for certs for my 
various e-mail addresses.

I tried OpenPGP but found the web of trust to be too complex for most 
people I communicate with and found the procedure for revoking a private 
key that may have been compromised too awkward.

I saw S/MIME with DANE as a way to use self-signed x.509 certs with 
confidence (more confidence than I personally have in the CA system 
where fraudulent certs are not uncommon, and where software like content 
filters and superfish often insert a root authority into user's trusted 
list) and saw S/MIME DANE as a way to validate those self-signed 
certificates, not as a way to distribute them.

I am sorry, I misunderstood the purpose.

That being said, the suggestion of using 2 1 1 or even 2 0 0 entries may 
give the privacy I seek.

If a * wildcard works with DNSSEC (I've never tried personally tried 
them) then the e-mail domain could be the certificate authority for 
x.509 certificates on the domain and sign certificates for the users 
that could then be DANE validated without DNS giving positive 
confirmation to the existence of an address or revealing the public key 
needed for a spammer to bypass the content filtering when sending 
malware to random users.

That is probably a better solution than using a serial number as a hash, 
and probably is easier to manage too as it only requires one DNS entry 
for every user on the system.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 12 Apr 2017 12:19:16 -0400 (EDT)

On Tue, 11 Apr 2017, Alice Wonder wrote:

> That being said, the suggestion of using 2 1 1 or even 2 0 0 entries may give 
> the privacy I seek.

It will, but you will then have to come up with a lookup system to find
the SMIME cert for a given user. If I want to email you without having
prior contact, how do I find your SMIME cert? Sure, if you email me you
can attach it, but then the problem moves from me to you on the first
email message.

And when you create some other lookup mechanism to find my key, you can
use that lookup mechanism to harvest email addresses.

In the end, email addresses are a point of contact and hard to keep
secret.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 12 Apr 2017 12:29:04 -0400

> On Apr 12, 2017, at 12:19 PM, Paul Wouters <[email-masked]> wrote:
> 
>> That being said, the suggestion of using 2 1 1 or even 2 0 0 entries may give the privacy I seek.
> 
> the SMIME cert for a given user.

No lookup system required, the certificate comes along with any signed
reply to the first contact message.  If that message is signed, then
the reply can also be encrypted.

> If I want to email you without having prior contact, how do I find
> your SMIME cert?

You don't, and this is a feature, because Alice did not want S/MIME
certificate publication to be an easy anti-spam/anti-virus filter
bypass mechanism.  With "SMIME 2 1 1 ..." first contact is in the
clear.

> Sure, if you email me you can attach it, but then the problem moves
> from me to you on the first email message.

1. Alice sends Bob a signed mesage:

   - Bob can use the "SMIMEA 2 1 1" record of Alice's domain to
     verify the signature on Alice's message.  Bob caches Alice's
     public key (certificate).

   - Bob can now use Alice's public key to encrypt replies.

2. Bob sends a signed (optionally encrypted) reply to Alice.

   - Alice can use the "SMIMEA 2 1 1" record of Bob's domain to
     verify the signature on Bob's message.  Alice caches Bob's
     public key (certificate).

   - Alice can now use Bob's public key to encrypt replies.

Lack of support for encryption on first contact can be seen as a
feature, not a bug.

-- 
	Viktor.

---

From: Phil Pennock <[email-masked]>
Date: Thu, 13 Apr 2017 03:59:03 +0000

> not enable user enumeration.

FWIW, I did something similar to this.  Of course, there's a chicken/egg
problem in _getting_ the CA cert for private CAs, unless you put the
whole cert into DNS.  And wildcards for something that large would be
cache-unpleasant, but I did the same thing I do for TLSA records: define
one SMIMEA record and CNAME to it elsewhere.  Much more cache friendly.

I never thought I'd see the day that I willingly chose to deploy a
wildcard CNAME.   :^D

$ORIGIN spodhuis.org.
*._smimecert            CNAME   _globnix-smimea
_globnix-smimea         SMIMEA  (       ; GlobnixCA5 PKIX-less trust anchor
        02 00 00
; SKIP: binary blob for an ECDSA CA
        ; SMIMEA DANE-TA CERT FULL
        )

I can't attest that this _works_.  As far as I know, it's entirely
draft-spec compliant.

If anyone has tooling which actually _uses_ SMIMEA, I'm happy to send
you a test mail, or be given pointers to how to try it out.  So far, I
have an SMIME setup to theoretically let others verify mail I send, and
that's it.

-Phil

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 13 Apr 2017 00:21:46 -0400

> On Apr 12, 2017, at 11:59 PM, Phil Pennock <[email-masked]> wrote:
> 

Note, that provided your MUA includes the issuing certificate in the
signature block (you can always make it an intermediate CA issued
by a throw-away root whose private key has been destroyed, and then
the MUA should include at least all the intermediates), there's no
need to use "SMIMEA 2 0 0" with the "large" DNS payloads that this
entails.  You get the same mileage from "SMIMEA 2 1 1".

That said, ECDSA certificates are often considerably smaller than
is the case with RSA, so "2 0 0" may be sufficient small to avoid
issues with UDP MTUs.

Still, I'd just go with "SMIMEA 2 1 1".

-- 
	Viktor.