Subject: [dane] A novel idea on the local-part problem for both SMIMEA and OPENPGPKEY?

From: Pieter Lexis <[email-masked]>
Date: Wed, 25 Mar 2015 16:32:03 +0100

Hi WG,

This whole local-part problem (aliases, folding and authority) has been
nagging in the back of my head the last couple of days. And I realized
this might be an issue that shouldn't be solved on the DNS-side of things.

Even though the DNS is a very nice, sturdy and fast protcol, I feel it
is not flexible (enough) for the things we are trying to do with it.
We've not reached the limit of the protocol, but what we're trying to do
feels like a hack.

The local part issues we're running into are essentially part of a
larger discovery problem that should not be solved in the DNS.

Now, the IETF has standardized a mechanism to do discovery like this in
the form of webfinger, RFC7033[1]. This would allow an MTA/MUA to lookup
the full recipient address (in the format given by the end user) at the
webfinger server of that domain. This server could do the
casefolding/aliasing using the defined 'aliases' field in the response body.

This allows also for easy expansion of e.g. the [email-masked]
addresses, as webfinger can return the canonical address
([email-masked] in this case) as the 'subject' in the response body
(see section 4.4.1 of RFC7033).

Webfinger also allows 'properties' to be set in the response body,
allowing it to send the public key in the response.

Webfinger is standardized to use HTTPS only, we could further strengthen
this by requiring a TLSA record for the host the MTA/MUA is connection to.

Using Webfinger has several advantages and disadvantages, off the top of
my head:

Advantages:
- No hashing involved
- Usage of existing technology (and providing a use-case for it)
- Administration of both SMIMEA and OPENPGPKEY information can still be
  done by different entities within an organisation
- No weird shoe-horning things into DNS
- Casefolding can be resolved by the receiving end in a dynamic fashion

Disadvantages:
- MTAs will need to talk HTTPS
- It's not DANE (more like 'DNS-Assisted')
- It kind-of defeats the purpose of this WG
- No NSEC3-like protection from address leakage (see sections 9.2 and
  9.3 of RFC7033)

I assume there'll be a lot of comments on this, what are your ideas
about this?

Best regards,

Pieter Lexis

1 - https://tools.ietf.org/html/rfc7033

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Mar 2015 11:57:29 -0500

> - No NSEC3-like protection from address leakage (see sections 9.2 and

No, if you discover the lookup service using DNSSEC and the service's
public keys with DANE, then the lookup service is as an extension of the
DNS, and it can provide secure non-existence answers.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 25 Mar 2015 17:55:22 +0000

> > - It kind-of defeats the purpose of this WG

No, not really.  DANE secures the location of the lookup service.

> DNS, and it can provide secure non-existence answers.

One way to understand that is to think this a new type of DNS
delegation, instead of NS+DS records securely delegating queries
to an authoritative server that still speaks DNS, you have TLSA
(or similar if the lookup protocol is over something more light-weight
than TLS) RRs that delegate the lookup to an authoritative server
that speaks a different protocol.

Either way, queries from the client go to the domain that controls
the names.  Either way, there's scope for "directory harvesting
attacks".  If we don't force the queries into the DNS:

    * We don't explode DNS caches with negative TTL replies for
      100's of millions of user names.

    * We can eliminate hashing (needed to deal with case folding
      and limits on DNS label lengths).

    * Eliminating hashing makes it possible for the owner domain
      to perform lookup key canonicalization.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Mar 2015 14:34:01 -0400 (EDT)

> DNS, and it can provide secure non-existence answers.

If the lookup service is on port X, and the attacker blocks port X, you
do not know whether there is a service interruption or an active attack.

Any lookup mechanism must remain within the DNS.

Paul

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Mar 2015 13:36:26 -0500

> do not know whether there is a service interruption or an active attack.

How is that different from the attacker blocking DNS?

> Any lookup mechanism must remain within the DNS.

This lookup service would be like an extension of DNS.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Mar 2015 14:42:46 -0400 (EDT)

> casefolding/aliasing using the defined 'aliases' field in the response body.

Any email address oracle service will find its biggest consumer to be
spammers. I do not think anyone will deploy such on oracle/service.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Mar 2015 15:25:15 -0400 (EDT)

> How is that different from the attacker blocking DNS?

We have a security policy for "indeterminate" and "bogus". That is, we
know we are under attack. Having a TCP connection just "not work" does
not have that property.

Additionally, DNSSEC as a transport has a much better penetration rate
than a new auxiliary protocol on a new unknown port.

Additionally, an SMTP extension using port 25 is out because many ISP's
do not allow you to connect to port 25 on the internet and force you to
go through their port 25 instead.

Paul

---

From: "John Levine" <[email-masked]>
Date: 25 Mar 2015 20:03:19 -0000

>spammers. I do not think anyone will deploy such on oracle/service.

This is certainly true.  The SMTP protocol has always had oracle
commands VRFY (does this address exist?) and EXPN (what are the real
address(es) for this address?)  The number of MTAs that currently
provide support either of those rounds to zero.

On the other hand, I think that a lookup service that takes an address
and returns a key would be workable.  Yeah, spammers will try to
scrape addresses from it, but it's the same attack as RCPT TO probing
and we have workable defenses against that.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 25 Mar 2015 20:17:05 +0000

> >spammers. I do not think anyone will deploy such on oracle/service.

The key acquisition protocol in no way changes the fact that
existence of keys discloses existence of addresses.

It makes NO difference what protocol is used to find the address
-> key mapping.  Using something other than DNS just makes it easier
to rate control clients, because they are not proxied by their
ISP's DNS cache.

> and we have workable defenses against that.

Actually, for the spammer, the DNS is a more attractive oracle,
because queries are cheaper and proxied by ISP caches.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Mar 2015 16:30:36 -0400 (EDT)

> to rate control clients, because they are not proxied by their

You mean it makes it easier to DDOS with a botnet. Either it will
be some UDP protocol with no state, vulnerable to spoofing, or
it will be some TCP protocol with state, vulnerable to resource
starvation.

Attacks will just take out the oracle to induce plaintext, or will
spoof causing a lockout of real clients inducing those end up using
plaintext.

> because queries are cheaper and proxied by ISP caches.

Recursors and Authoritative servers supporting OPENPGPKEY or SMIME could
rate limit the sending of NSEC3 chains if there are too requests for
non-existing records - causing them to need to go back to the current
RCPT TO practise.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 25 Mar 2015 20:45:57 +0000

> it will be some TCP protocol with state, vulnerable to resource

We've designed the protocol yet.  The server can be UDP/stateless,
and yet not be subject to spoofing, and can vend client cookies
(for example) to protect against origin spoofing.  The issues you
raise are important when considering the choice/design of the protocol.

> spoof causing a lockout of real clients inducing those end up using

Taking out the oracle will not induce plaintext any more than
performing the same attack on the authoritative DNS server for the
domain.  User keys would have very short TTLs (positive and negative,
to address cache explosion), so a large fraction of queries will
go end-to-end from the MUA to the authoritative server.

> rate limit the sending of NSEC3 chains if there are too [many] requests for

Will the recursive servers do that?  In practice they'll not have
any code to support these RR types specifically, the new RR types
will just be handled by the generic RR code.

Any harvesting defense is I think more likely to be deployed
effectively at the target server, rather than by thousands of
proxies operated by 3rd parties.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Mar 2015 16:00:49 -0500

> go end-to-end from the MUA to the authoritative server.

Not only that, but it will be easier for MUAs to give the user feedback
as to what went wrong in such a protocol than in DNS.

> > non-existing records - causing them to need to go back to the current

Not having to worry about zone walking for this is a plus.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 25 Mar 2015 21:17:40 +0000

> casefolding/aliasing using the defined 'aliases' field in the response body.

THe problem with canonicalizing addresses (akin to EXPN) is that
most sites simply won't want to publish this data.  Returning a
key is very different from returning a "canonical address".

Any alternative protocol should just return the SMIME or PGP key
for the address, and avoid returning any intermediate "canonical"
addresses used to locate those.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Mar 2015 17:58:45 -0400 (EDT)

> addresses used to locate those.

You realise the openpgp key will likely contain any correct IDs right?

So if your protocol maps [email-masked] to [email-masked] and returns
the pgp key, they will know the "canonical" address. The more helpful
you are mapping to a key (like for "[email-masked]" ?) the easier it
is to obtain email addresses.

Email addresses (like DNS data) are simply not a secret. Those who
value hidden email addresses without OPENPGPKEY support can surely
continue to operate as they do now.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Mar 2015 18:12:10 -0400 (EDT)

On Wed, 25 Mar 2015, Nico Williams wrote:

>> domain.

DNS servers are pretty good at withstanding attacks. Entire business
models have sprouted up deploying this. We have redundant DNS servers
and redundant MX hosts. So it's basically mandatory to run redundant
oracle servers. This whole oracle idea is gaining FTE's pretty fast in
both design and implementation and it is an insane cost for a pretty
imaginary use case of typing in an email address that might be wrong
which must be corrected.

>>  User keys would have very short TTLs (positive and negative,

I think you should let cache management policies be decided by the
cache? For privacy reasons, some publishers might want to use a high
TTL. Revocation is not much of a problem since most of these keys
are years or decades old without people updating those keys before using
them again to see if the key was revoked.

> as to what went wrong in such a protocol than in DNS.

Which user? openpgpkey-milter operates without an interactive user.

> Not having to worry about zone walking for this is a plus.

Again, no one is making this mandatory to deploy. If you rather have
your users semi-hidden with plaintext email, keep calm and continue
as you are now.

If there are people who want to design and deploy oracles, go ahead and
write a document. OPENPGPKEY should not _require_ one and still work
without any user mapping. And implementations can later be extended to
use this new oracle protocol.

Paul

---

From: "John Levine" <[email-masked]>
Date: 25 Mar 2015 22:36:18 -0000

>DNS servers are pretty good at withstanding attacks.

Mail servers aren't?  We've been under a continuous DDoS from spammers
for the past decade and a half.

>imaginary use case of typing in an email address that might be wrong

At yesterday's session, the "mail crowd" made it pretty clear both
that address guessing is not on the table, and the range and usage of
variant addresses are far larger than you believe them to be.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 25 Mar 2015 23:11:52 +0000

> You realise the openpgp key will likely contain any correct IDs right?

I'm aware of the current design possibly returning usernames in
addition to key material.  Not clear whether that's a feature, but
in any case that happens only for users with keys.  I was responding
only to a suggestion of running a pure canonicalization service,
which would then canonicalize also names with no keys.

Similarly SMIME certs often contain email addresses.  Though with
SMIME (CMS), the recipient info from which key copies are decrypted
is identified by "IssuerAndSerialNumber" or "SubjectKeyIdetifier"),
so one *can* create certs for SMIME encryption that contain only
opaque identity information.

I don't know how recipient key copies are identified in PGP.

-- 
	Viktor.