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? Those are in my view more trustworthy
than any library the application might attempt to use to perform
validation.
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).
> >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). 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.
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.
> 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.
> >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?
> >>Perhaps, but that's your domain. The important question is, how does a
> >>client know that your TLSA records are reliable?
> >DNSSEC RRSIG.
>
> Right, but what libraries can a client use to do the verification correctly,
> and without making that verification vulnerable to attack?
Postfix uses libresolv to 127.0.0.1:53, with the AD=1 bit signalling
verification. What attack did you have in mind?
> Axiomatically trusting the MSA is not sufficient. We need a better way.
The addrquery draft unavoidably trusts the MSA. If that's not
acceptable, this draft may be DOA.
> >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.
> >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.
> >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, I don't see any way to get
around that, the introduction problem is a bear with trusted third
parties. Speaking of parties, how many key-signing parties do you
attent? :-)
> >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. The MUA <---> MSA link is mutually authenticated
with TLS cert for the server (WebPKI or DANE as appropriate). The
MSA <---> MX is also authenticated TLS, DANE would also make it
possible to authenticate the client (Shumon Huque and I are working
on a DANE client auth spec), which can facilitate limiting abuse.
What alternative did you have in mind?
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
