On Jul 31, 2015 8:49 AM, "Viktor Dukhovni" <[email protected]> wrote: > > On Fri, Jul 31, 2015 at 08:33:31AM -0700, Watson Ladd 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? 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. > > I did say "127.0.0.1", not ISP iterator. I keep saying *local* > (perhaps I should have said "loopback") resolver, but nobody seems > to be reading the fine print. :-( > > stub resolver <---> validating loopback iterator <---> Untrusted nameservers > > If the *local/loopback* resolver happens to use the ISP as a > forwarder, that's not especially relevant, modulo the usual privacy > considerations.
It absolutely is relevant. It means an OS provided component can completely change the security guarrienties of an application with no visible sign. I don't like that. > > I think we need to return the core subject of this discussion (high > level addrquery architecture). Authentication technology aside for > the moment, is the > > MUA <---> MSA <---> MX host > > transaction model acceptable or not? We can then talk about how > to authenticate each hop. If this is not acceptable, how does > addrquery get to the MX host? [ I'd be very reluctant to implement > a new MX host service which has many orders of magnitude more remote > clients than the existing MX host SMTP service. ] > > This proposal looked promising because it piggy backs on the existing > SMTP backbone. If it abandons that, then my enthusiasm for it will > likely wane. > > -- > 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
