Subject: [dane] Another SMIMEA draft review

From: "Rose, Scott" <[email-masked]>
Date: Sun, 19 Jul 2015 13:52:53 +0000

I have read the SMIMEA -08 draft and support it being "undeterred" and put back on track.  NIST also has some (old) test code that we want to host and have sponsored SMIMEA work in the past.  Our previous work has used the format described in the current draft.

I have heard of two potential privacy concerns that the WG may want included in the Security Considerations section:

First, if the _smimecert.<domain> is hosted by a service provider (i.e. not the domain owner), the service provider can see who may be receiving encrypted mail and may also learn the source IP address and other potential information.  Of course, the hosting provider also knows the whole list of (hashed) cert holders in the domain as well.  Pervasive monitoring may also discover this (source IP A is looking for a cert for person X in order to send them mail), but qname-minimization may mitigate this to a degree.

Second, clients looking to validate a digital signature using SMIMEA queries may also be signaling a read receipt.  If the original sender knows the recursive servers of the recipient, The sender could get an idea as to when the receiver MUA validated the digital signature by observing SMIMEA queries to their domain.  This isn't a showstopper IMHO as recipients with cached digital signature certs may not send queries.

To summarize as some suggested text (as a starting point at least - not happy with it, but it is the best my brain allows right now):

*****

In addition to the zone walking vulnerability, SMIMEA aware senders and receivers may also leak information when querying for SMIMEA RRs for validating digital signatures and discovering a recipient's S/MIME encryption certificate. SMIMEA RR queries may leak information about who is planning to send, or has receive S/MIME protected email messages.  DNS privacy techniques such as qname-minimization may mitigate some of the leakage.

*****

Scott

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 19 Jul 2015 14:57:40 +0000

On Sun, Jul 19, 2015 at 01:52:53PM +0000, Rose, Scott wrote:

> First, if the _smimecert.<domain> is hosted by a service provider (i.e.
> not the domain owner), the service provider can see who may be receiving
> encrypted mail.

Which they'll also learn by just looking at the zone data, if the
localparts are not hashed in the final spec.

I'd be more concerned above passive monitoring, because with
submission over port 587 with TLS, and forward hops from the MSA
to the destination also increasingly over TLS, there is often at
present no cleartext exposure of the envelope recipients.

With SMIMEA, passive monitoring of DNS queries will often reveal
the correspondent addresses.

> and may also learn the source IP address and other potential
> information.

That'll be less common, there will typically be iterative resolvers
between the user and the authoritative nameserver.

> Of course, the hosting provider also knows the whole list
> of (hashed) cert holders in the domain as well.  Pervasive monitoring may
> also discover this (source IP A is looking for a cert for person X in
> order to send them mail), but qname-minimization may mitigate this to a
> degree.

Query minimization does not help here, it only hides the data from
operators of parent domain nameservers.  Only encryption of DNS
traffic (ala DNScurve and at all zone cuts from the root down)
would help.

> Second, clients looking to validate a digital signature using SMIMEA
> queries may also be signaling a read receipt.  If the original sender
> knows the recursive servers of the recipient, The sender could get an idea
> as to when the receiver MUA validated the digital signature by observing
> SMIMEA queries to their domain.  This isn't a showstopper IMHO as recipients
> with cached digital signature certs may not send queries.

The cache lifetimes should be relatively short (not in excess of
the DNS TTLs of the TLSA RRs), so whenever there's a hiatus in
email flow between two correspondents (as opposed to a flurry of
immediate replies) it is quite likely that new conversations will
involve new DNS lookups.

> SMIMEA RR queries may leak information about who
> is planning to send, or has receive S/MIME protected email messages.  DNS
> privacy techniques such as qname-minimization may mitigate some of the
> leakage.

Qname minimization does not help against passive monitoring, unless
that passive monitoring is in (only) in front of the root or
gTLD/ccTLD nameservers, rather than on path somewhere between author
and target domain.

-- 
	Viktor.

---

From: "Wiley, Glen" <[email-masked]>
Date: Mon, 20 Jul 2015 07:02:14 +0000

>localparts are not hashed in the final spec.

Has there been any recent discussion about using a non-hashed LHS
encoding?  I don¹t think there has so we probably don¹t want to bring
that question into scope here.

>the correspondent addresses.

Obvious but worth a reminderŠpassive monitoring isn¹t a problem peculiar
to the SMIMEA approach, it is an issue for all elements of the email flow
that are not encrypted.

>gTLD/ccTLD nameservers, rather than on path somewhere between author

I think it is fair to say that QNM does help as it reduces the number of
points
at which a passive monitor can see traffic.  It is an incremental
improvement.
>
>-- 
>	Viktor.
>
>_______________________________________________
>dane mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dane

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Jul 2015 06:29:46 -0400 (EDT)

> that question into scope here.

There was some interested by the powerdns people for this, as they
implement an online signer and could deliver custom signed responses.
John Levine also prefered this approach in the past.

While I think the non-hash version is uglier, I don't think that is
a valid reason not to do it.

> to the SMIMEA approach, it is an issue for all elements of the email flow

I am assuming that SMTP traffic will be TLS for the majority, either
authenticated or opportunistic. So I think the concern is somewhat
valid. But we did say that the hash was not a security meassure. If we
are going to use it as a security meassure we might have to think about
making it stronger.

Paul

---

From: "Peter van Dijk" <[email-masked]>
Date: Mon, 20 Jul 2015 18:12:12 +0200

Hello,

> John Levine also prefered this approach in the past.

Indeed - *not* doing the hashing has many potential benefits (most of 
which do require online signing to fully reap), and few downsides. Split 
base32 massively increases the potential surface area for opportunistic 
encryption, while hashing strictly rules out those benefits. Besides the 
functional benefits, base32 also is easier for debugging.

So far I’ve seen two downsides to split base32 mentioned:
(1) split base32 has a longer maximum length than a hash (although in 
practice it will actually be shorter than a hash, for most addresses)
(2) privacy

As Paul mentions further down this thread, if we start caring about 
privacy we have more work to do.

> a valid reason not to do it.

I don’t think any of the options look pretty - including base32. This 
fate we have to accept when shoehorning things into the DNS!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: "Wiley, Glen" <[email-masked]>
Date: Mon, 20 Jul 2015 23:08:14 +0000

A few of us were chatting after the meeting and I suspect that the 64
octet limit for a label is going to create a problem with using split
base32.  It sounds as though we would end up limiting the LHS to 40
octets before the encoding.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 21 Jul 2015 03:12:04 -0400 (EDT)

> octets before the encoding.

how so?

$ ./lhs.py 
email string length:144
qname length:242
OBQXK3DIMFZWC5TFOJ4XMZLSPF3GK4TZOZSXE6LWMVZHS5TFOJ4XMZLSPF3G.K4TZOZSXE6LWMVZHS5TFOJ4XMZLSPF3GK4TZOZSXE6LWPFSXE6LWMVZHS5TF.OJ4XMZLSPF3GK4TZOZSXE6LWMVZHS5TFOJ4XMZLSPF3GK4TZOZSXE6LMN5XG.OZLNMFUWYYLEMRZGK43TNRXWGYLMOBQXE5A=._openpgpkey.nohats.ca.

#!/usr/bin/python

import sys
import base64

email =
"paulhasaveryveryveryveryveryveryveryveryveryveryveryveryveryveryvyeryv[email-masked]"

lhs, domain = email.split("@")
lhs32 = base64.b32encode(lhs.strip("="))
length = len(lhs32)
cur = 0
out = ""
splitsize = 60

while cur < length:
         if length - cur < splitsize:
                 nxt = length
         else:
                 nxt = cur + splitsize

         out += "%s."%lhs32[cur:nxt]
         cur += splitsize
rr = "%s_openpgpkey.%s."%(out,domain)
print "email string length:%d"%len(email)
print "qname length:%d"%len(rr)
print rr

---

From: "Wiley, Glen" <[email-masked]>
Date: Tue, 21 Jul 2015 11:06:28 +0000

Thanks Paul.  I was leaving out the ³split² part of ³split base32² (was
thinking about a split at the @ rather than the approach you captured in
The draft).

On 7/21/15, 3:12 AM, "Paul Wouters" <[email-masked]> wrote:

>OBQXK3DIMFZWC5TFOJ4XMZLSPF3GK4TZOZSXE6LWMVZHS5TFOJ4XMZLSPF3G.K4TZOZSXE6LWM
>VZHS5TFOJ4XMZLSPF3GK4TZOZSXE6LWPFSXE6LWMVZHS5TF.OJ4XMZLSPF3GK4TZOZSXE6LWMV
>ZHS5TFOJ4XMZLSPF3GK4TZOZSXE6LMN5XG.OZLNMFUWYYLEMRZGK43TNRXWGYLMOBQXE5A=._o
>penpgpkey.nohats.ca.
>
>#!/usr/bin/python
>
>import sys
>import base64
>
>email =
>"paulhasaveryveryveryveryveryveryveryveryveryveryveryveryveryveryvyeryvery
>[email-masked]"
>