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

[Keith Moore <[e-mail]>]

On 08/01/2015 01:14 AM, Viktor Dukhovni wrote:
> On Fri, Jul 31, 2015 at 06:49:59PM -0400, Keith Moore wrote:
>
>>> They'd also need new SMTP software to support
>>> AQRY.  That software would need to be well maintained too.  I trust
>>> the DNSSEC validation code in unbound and BIND more than I would
>>> trust the same to some application library.  The former are likely
>>> to get more relevant scrutiny.
>> And you might be right.   But what you find trustworthy, and what is
>> available to most users, are completely different things.
> Again what is available to users is largely irrelevant provided
> all the hard-lifting is done by the MSA.

It's pointless to continue arguing about this.

>> It _might_ be okay for an MUA running in a resource-constrained environment
>> to trust the MSA to do DNSSEC verification and signature verification on the
>> data.  But if an MUA implementor is going to go that route, it might as well
>> just be a split MUA and have the server side of that MUA responsible for
>> encryption.   I find it dubious that an environment that is too resource
>> constrained for key verification is not too resource constrained to do
>> public key encryption of the message.
> 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"?


>>> You can trust anything you want, but the DV TLS cert does not merit
>>> any trust.
>> Neither do DNSSEC-signed TLSA records, then.
> The logic escapes me.

Both X.509 DV and DNSSEC-signed TLSA records basically equate control 
over the domain with the required assurance.   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.   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.   So the 
threats are different, but I can't make a case that in practice DANE is 
inherently more secure than X.509 DV.

>> As far as I can tell, they're approximately equivalent in that respect.
> No DNSSEC is stronger than DV

Only if you ignore the other weaknesses in DNSSEC protocol and 
implementations.  See above.

>>> I call it a design feature.  I think AQPX makes this scale much
>>> better,
>> I don't see how.   It doesn't lessen the load on either the MX server or the
>> MUA client, and it increases network traffic overall.
> It facilitates controlling abuse, which would otherwide dwarf the
> volume of legitimate traffic.

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.

>>> The resolver on the MSA is part of the OS operated by the same
>>> sysadmin who operates the MSA.
>> Perhaps.  But axiomatically expecting the MUA to trust the MSA is still a
>> Bad Idea.  If the MSA host is compromised, it doesn't matter whether the
>> compromise is in the MSA code itself or in its resolver.
> 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.


Keith