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
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
