On Fri, Jul 31, 2015 at 02:23:25PM -0400, Keith Moore wrote:
> >Perhaps you're using the phrase "local resolver" in some novel way
> >that I don't understand. Why shouldn't an application trust
> >responses from 127.0.0.1:53?
>
> The vast majority of hosts don't operate a resolver, and even if they do,
> there's no particular reason to believe that it's well-maintained. (though
> this will differ from one platform to another; some vendors are good about
> software updates, others not so good).
This is irrelevant. The only hosts that would need a local resolver
would be the MSAs. 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.
> >Those are in my view more trustworthy
> >than any library the application might attempt to use to perform
> >validation.
>
> The MUA vendor can at least control what library it uses. It has no
> control over what resolver is available on the customer's host or enterprise
> network.
The MUA is not the one doing the DNSSEC verification of the remote MTA.
THat's on the MSA to MTA side of the divide:
MUA <--WebPKI + SASL user auth--> MSA <--DANE, ideally mutual--> Remote MTA
> >The local resolver is far more likely for example to have a working
> >implementation of RFC 5011 (and thus not have a stale root trust
> >anchor).
>
> Sure, but there are other reasonable ways of updating trust anchors,
> including normal software update mechanisms (if they're properly
> authenticated).
I'm not holding my breath for those.
> >In the context of this draft, if authentication is
> >mandatory, then it makes it possible to deploy MX host certificates
> >at scale, without trusting DV or being easily vulnerable to DNS
> >MiTM.
>
> Perhaps. But DNSSEC has to be deployed by each mail domain (requiring a
> steep learning curve and support from the domain's registrar and DNS service
> provider).
Only the domains that want to publish e2e keys, which is even more
bleeding-edge than DNSSEC.
> And the client needs to have reason to trust either the resolver or library
> that's used (or both), and those are actually much harder at present than
> being able to trust a TLS server cert.
You can trust anything you want, but the DV TLS cert does not merit
any trust. On the MSA/MTA I operate, I also operate the unbound
server, and I've reason to trust it about as much as one can trust
software written by fallible humans.
> >Remote port 25 from the MUA is just as unreachable with or without
> >DNSSEC. So DANE does not authenticate an impossible connection
> >from the MUA to an unreachable server, and often the MUA is in
> >a captive portal where DNSSEC is not available.
>
> If the information returned from AQRY were signed, and there were a way to
> validate the public keys with which those information were signed, AQPX
> could simply pass through those signatures to the client.
How does the MUA learn trustworthy valid signature keys for that?
Making solutions to "the introduction problem" scale while trying
to avoid trusted third parties (introducers) is a balacing act
between rock and hard place. You can't have it all. Trade-offs
are unavoidable.
Doing this without trusted third parties is unavoidable, and I'm
not going to trust the CNNIC CA to introduce me to my next door
neighbours. At least DNSSEC is sensibly partitioned.
> The client
> wouldn't have to trust the MSA to validate those signatures.
Sure it would, because it would learn the trust anchors for that
from the MSA, or have to trust every self-appointed CA on the
planet. I'd rather trust my MSA.
> >The MSA needs to be trusted, because the mailbox provider controls
> >the reverse channel (mail you receive) and any keys published for
> >you in the reverse direction. So your mailbox provider can MiTM
> >the reverse traffic, recovering most of the forward traffic.
>
> a) The MSA is not necessarily operated by the same party as the mailbox
> provider, and there are good reasons to not do this.
With DMARC, DKIM, SPF, ... sure it is. How else do you authenticate
to the MSA and get to send mail from your mailbox domain?
> b) If the mailbox provider always lies about the keys that you publish, you
> can detect this.
> (detecting cases where the mailbox provider selectively lies is harder)
Yes, selective lies to certain clients which are then MiTMed are
more difficult to detect. The issue is largely symmetric, lying
by the MSA to the MUA is also prone to discovery. This is not an
easy space in which to operate invisibly.
> If you use AQPX, that's true. But I'm now thinking that this needs to be
> fixed.
I think you'll lose my support with any plausible "fix", but I'm
willing to suspend disbelief for now.
> >You Chris Newman and I can probably chat over Skype too. I open
> >for that, and it would likely save some bandwidth on the list.
>
> Either or both is fine. We should probably take this off the UTA list
> anyway, as I suspect the work won't end up being done in this WG.
Chris has my Skype contact info. I'm in US/Eastern, let's try to
set something up.
> It wasn't intended to be a core feature. But I do admit that port 25
> blocking is widespread, which is why I now think AQPX requiring the client
> to trust the MSA is a serious flaw.
I call it a design feature. I think AQPX makes this scale much
better, and allows the MSA to MX protocol to evolve separately from
the MUA to MSA protocol (product upgrade cycles for MUAs are
glacial). The MTA market is far more agile now that the hosting
providers are doing software as a service and the rest of the
infrastructure is largely on open source.
> >The protocol just carries the payload around and authenticates the
> >peer conveying it. The two parts are independent, and if we can't
> >reach consensus on the architecture of the key distribution system,
> >we're working on the wrong draft. The payload issues are important,
> >but not difficult. I don't at present have the cycles to do both
> >discussions in parallel. I think we need to decide whether:
> >
> > MUA <---> MSA <---> recipient domain's MX host
> >
> >is the right model.
>
> It's not the right model if the MSA has to be trusted to verify the MX
> host's cert. It's more-or-less the same problem as trusting the DNS
> resolver to honestly set the AD bit. Both increase the attack surface
> significantly.
The resolver on the MSA is part of the OS operated by the same
sysadmin who operates the MSA. He should trust himself at least,
but also implement monitoring (even Roland Reagan new about "doveryaj
no proveryaj").
[ I guess that not too many folks on this list have postmastered
a domain with 80,000 or more users for a decade (the MTAs and
MSAs had local resolvers way before DNSSEC, that was just the
right thing to do anyway to make them more performant/reliable). ]
The key question is whether the MUA trusts the MSA to deliver the
right keys or not (likely to be discovered if not and the correspondents
share additional channels of communication).
How exactly the MSA authenticates the MTA so it does not get fooled
by a bogus upstream is a secondary problem, that warrants attention
of course, but since we've not yet agreed on the big picture should
likely not distract us from the main issue.
> >What alternative did you have in mind?
>
> I'll work on it for the next revision.
I think it makes sense to discuss the architectural outline before
investing too much time in a formal writeup.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
