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.
> You can keep saying that as many times as you want, and it still won't be
> acceptable to impose that restriction.
We clearly disagree, and we'll have to find where the rough
consensus lies, John Levine IIRC was leaning towards minimal security
(ala DKIM), a trusted MSA is a fortress by comparison.
> 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.
And sure in some environments the MSA will not support key lookups
by users, or will vend a "gateway" key, and will virus scan, DLP
scan and archive the mail, before possibly encrypting to the final
recipient.
> I don't think we can stop people from building split MUAs that do encryption
> on the server side, any more than we can stop people from implementing
> webmail clients that do encryption and decryption on the server side. But
> that doesn't mean we should cripple our key distribution protocol to enforce
> that kind of restriction.
Not cripple, just trust the MSA to not lie, or not easily consistently
get away with it. This simplifies the model, and makes it much
more manageable.
> I'm not holding my breath to have DNSSEC and trustworthy resolvers for it
> widely deployed.
Not widely, just on MSAs that choose to support AQPX. Which can
choose to do WebPKI with selected peers or trust DV if they please
(but will not be able to query any of the domains with DANE-EE or
DANE-TA certs). We can only suggest a preferred authentication
model, we can't police it.
Even the BSI in Germany is recommending DANE/DNSSEC, it is not a
mandate.
> >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.
> As far as I can tell, they're approximately equivalent in that respect.
No DNSSEC is stronger than DV because the registrar definitively
knows who controls the customer domain. A certfificate from some
random stranger attesting that that seemed to be the case at a
passing glance is much weaker. Also TLSA records are service-specific,
while X.509 PKI certs name hosts conflating HTTPS certs with SMTP certs, ...
> >Chris has my Skype contact info. I'm in US/Eastern, let's try to
> >set something up.
>
> Let's work out the details off-list.
Sounds like a plan.
> >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.
> Actually, the current proposal requires the MUAs to track changes in AQRY
> response format. Even if the query uses AQPX, the MSA just returns the
> data provided by the MX server.
I'm not discussing the payload yet. That's a subsequent conversation.
Also there's more to the protocol than just the payload, e.g.
evolution in the transport security model between MSA and MTA which
could be transparent to the MUA.
> >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. Users who already have keys and
are just verifying freshness might also be alerted to the change.
To reduce alert frequency, we could look into payload formats in
which new keys are signed by old keys, so that routine key changes
are not a source of constant false positives, and only "unplanned"
key changes raise alerts.
> >I think it makes sense to discuss the architectural outline before
> >investing too much time in a formal writeup.
>
> I think it makes sense to not waste time arguing about a proposal that isn't
> yet developed in sufficient detail. That time is better spent actually
> developing a proposal. I appreciate the feedback on the current proposal
> and hope it leads to making the next proposal stronger.
Sure we can chat off-list if that might be helpful, and resume the
public discussion after the next version. Over and out.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
