On 07/31/2015 11:28 AM, Viktor Dukhovni wrote:
On Thu, Jul 30, 2015 at 04:02:58PM -0400, Keith Moore wrote:
And finally, the idea that a DNS client
could simply trust its local resolver to do DNSSEC validation for it never
made any sense at all.
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).
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 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 am not aware of any significant obstacles to the use of DNSSEC
in a server-to-server environment, where captive portals and other
"middle boxes" don't play a major role.
Hmmm. As far as I can tell, the chief benefit of using DANE (or, more
generally, DNSSEC-signed keys) over server certs is that DANE could permit
MUAs to directly verify the signatures on returned data, by having those
keys signed by their domains and looking up the domains' signatures using
DNS.
No, that's not the chief advantage. The chief advantage is that
it makes it possible to impelement a downgrade-resistant mechanism
to authenticate MTA-to-MTA STARTTLS (for opportunistic transport
security).
I was referring specifically to potential benefits with use of DANE with
AQRY, not to other uses of DANE.
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). 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.
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. The
client wouldn't have to trust the MSA to validate those signatures.
I really don't like having MUAs trust MSAs to do their verification
for them, as MSAs are too easily compromised. The only reason AQPX exists
in the current proposal is to work around port 25 filtering and the
consequent inability of MUAs to directly contact MX servers.
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.
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)
(But thanks for pointing out that attack - I'll add it to security
considerations.)
In my experience (b) "just works" (establishing authenticity of
TLSA RRs).
Just because something appears to work doesn't mean it's secure.
What threat model do you have in mind?
Too many to list right now, but it sounds like I need to write a
complete threat analysis.
Axiomatically trusting the MSA is not sufficient. We need a better way.
The addrquery draft unavoidably trusts the MSA.
If you use AQPX, that's true. But I'm now thinking that this needs to
be fixed.
I'll be adding support for DANE to OpenSSL. I'll probably be at
the Atlanta MAAWG meeting in October, anyone who wants to discuss
implementation pitfalls should free to corner me there...
I'm not planning on attending, but it's not far from me. I could probably
get down there if you want to meet in person.
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.
Indeed one could simply let the MSA choose how to authenticate the
remote MTA per local policy. If for some MSAs they have a better
way than DANE to authenticate some MTAs (pinned certs, WebPKI, ...)
they should be free to do so. Basically, authenticate the remote
domain by whatever means are suitable, but if this is to scale,
for now there's no real alternative to DANE (provided DNSSEC adoption
moves forward).
The more I think about this, the more convinced I become that MUAs must be
able to do their own verification.
Not possible when the data source is the remote domain's MTA on
port 25 as specified in this draft.
It's possible, but it means we can't rely on TLS and the MTA's server
cert to authenticate the data.
Deployment suffers from last mile on mobile devices, but that's
not a barrier here. I still don't know what "trusting" issue
you have in mind.
You're assuming that having the MSA do the verification for the client is
sufficient. I'm fairly certain that it is insufficient.
It is a core feature of your draft
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 hope we get to the meat of the problem in the not too distant
future, but I think we do first need to clear the protocol hurdles.
Actually I think it's the other way around. We need to focus our
attention on the data model sooner rather than later. Once we get that
straightened out, we'll know what changes we need to make to the protocol.
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.
What alternative did you have in mind?
I'll work on it for the next revision.
Keith
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
