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

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 2 Aug 2015 05:37:38 +0000

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.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 04 Aug 2015 19:22:29 -0400

On Wed 2015-07-22 02:55:02 -0400, Keith Moore wrote:
> The way AQRY is written at the moment, a mail domain can outsource its
> AQRY redirect server to a different party than its mail service
> provider, so it's not having to trust their MSP with their private
> keys.

Maybe i've misread the draft, but isn't it possible to avoid trusting
your MSP with any private keys even without the redirection?  The MSP
needs to keep a mapping from account→pubkey/cert (and can obviously
spoof this mapping), but no private key access is needed.

Rather, it looks to me like the goal of the redirection is just
operational streamlining -- to make it possible to maintain this mapping
at a different location (or as a separate service) than the canonical
MTA.

can you clarify?

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 04 Aug 2015 19:38:34 -0400

On Fri 2015-07-31 11:51:49 -0400, Watson Ladd wrote:
> On Jul 31, 2015 8:49 AM, "Viktor Dukhovni" <[email-masked]> wrote:
>> If the *local/loopback* resolver happens to use the ISP as a
>> forwarder, that's not especially relevant, modulo the usual privacy
>> considerations.
>
> It absolutely is relevant. It means an OS provided component can
> completely change the security guarrienties of an application with no
> visible sign. I don't like that.

Isn't this always the case?  The OS can change out system libraries,
update local services, and can replace critical files (like default
trust anchor stores) already.

Viktor's proposal of always relying on a privileged port on the loopback
is a little scary, but it's certainly no scarier than the maintenance
quagmire of each application shipping its own complex DNSSEC
parsing/querying/validating stack.

         --dkg