On Jul 31, 2015 8:29 AM, "Viktor Dukhovni" <[email protected]> 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? Those are in my view more trustworthy > than any library the application might attempt to use to perform > validation.
Because the stub resolver on the box uses a recursive resolver on the ISP which doesn't send back the information required to determine validity, but a single bit. Since getting DNSSEC wrong is right now consequence free, don't expect it to be fixed when the alternative is no DNS. > > 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
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
