Re: [Uta] draft-moore-smtp-addrquery

[Viktor Dukhovni <[e-mail]>]

On Sat, Aug 01, 2015 at 01:31:02AM -0400, Keith Moore wrote:

> It's pointless to continue arguing about this.

Yes, we're done.  Contact me off-list to arrange a time to chat
when you're ready.  The below are just clarifications, not a
counter-argument.

> >I did not mention anything about resource constraints.  The contraints
> >are rather mobility in and out of captive portals and port 25
> >blocking.  With super-computers in every pocket, I'm not too
> >concerned about the cost of performing a couple of public key
> >operations now and then.  Much cheaper than streaming Neflix.
> 
> Agree about pocket super-computers.  Can you elaborate on what you mean by
> "mobility in and out of captive portals"?

MUAs on phones, laptops, ... inevitably find themselves on networks
on trains, at airports, in hotels, and even at home where middleboxes
proxy DNS and don't support RRSIG/DNSKEY/... and sometimes even MX
records!  Just A/AAAA/CNAME/PTR is about all you can get in many
of these environments.  And often only ports 80/443/587.

> Both X.509 DV and DNSSEC-signed TLSA records basically equate control over
> the domain with the required assurance.

Correct.

> That's already a leap because an email address really isn't a person's
> identity, the domain isn't really designed to be a CA (even for its own
> users), and the sender really wants to send to a person rather than whoever
> happens to be currently associated with an email address.   But let's
> accept that as a necessary limitation for now.

Intrinsic to the proposed approach to the key distribution problem
(unlike Web of Trust), is that in order to address scalability, it
delegates bindings of email address to key to the domain owner, so
that's who we have to authenticate.  Sometimes that's not ideal
(when emailing my parents it is them I want to reach, not some
particular mailbox at their provider).  Other times, I ready do
want to reach the bank branch manager at bank.example, and not the
person who happens to occupy that seat.

> X.509 DV has the additional problem that any trusted CA can sign any key.
> DNSSEC has better partitioning, as you point out, but trusting the AD bit is
> a hole big enough to fly a 747 through, and there are lots of known
> implementation bugs.

For the record, I must object to this as sheer FUD.  The AD bit
from my local nameserver is just fine.

> So the threats are different, but I can't make a case
> that in practice DANE is inherently more secure than X.509 DV.

It does a better job of verifying domain control.  That's all I
expect from it.  It certainly does not tackle typo-squatting, or
"identity", ...  Just lookup of data for a domain, that resists
modification in transit.

> No it doesn't, because there's no way to prevent abusive clients from
> talking directly to SMTP servers.   Port 25 blocking, while widespread, is
> far from universal.

For AQRY, can harden the protocol to only grant access to MSAs.
For example, the MSA might have to be listed in a suitable SRV
record (because this is anti-abuse, not data integrity, authentication
is not required).  One might also deny access to domains that are
too new, or have a bad reputation.  The point being that a small
number of legitimate MSAs are far easier to service while refusing
service to botnets.  Connections directly from each home user don't
lend themselves to this time of approach.

> >Indeed, if the MSA is compromised, users may see forged keys, but
> >the MSA would have to stay compromised indefinitely, or users would
> >later see unforged keys, and MUAs might let users know that keys
> >for a recipient changed, and that they might double check that this
> >happened with the correspondent.
> 
> So it's just like when using an ssh client that says "hey, the remote host's
> key changed".   Users learn to click "ok" and continue as if nothing
> happened.

I'm not designing UI here, just talking about one way in which
attacks can be tamper-evident.  Users who tune out authentication
failures will likely not be protected against targetted attacks by
any security technology.  The best we can hope for is that some
users will pay attention, and most of the rest will not be worthy
attack targets.

-- 
	Viktor.