On Fri, Apr 17, 2020 at 08:13:52PM +0200, Florian Weimer wrote: > * Wietse Venema: > > > Florian Weimer: > >> * Wietse Venema: > >> > >> > Vladimir Lomov: > >> >> I'm a bit bewildered. Does this mean that all is Ok with glibc 2.31 with > >> >> 'options trust-ad' and postfix 3.5.0 or it is depend strongly on used > >> >> 'options'? > >> > > >> > This patch avoids the need to add options to resolv.conf. > >> > >> Does Postfix perform its own DNSSEC validation? I suppose not, > >> otherwise you would not need the AD bit. > > > > Correct. Until now, Postfix asserts RES_USE_DNSSEC to request > > validation in a resolver. > > RES_USE_DNSSEC is unfortunately misnamed. All it does is set the DO > bit in queries. This bit is named “DNSSEC answer Okay”. It was added > after it was realized that some clients would choke on the records of > unknown type that DNSSEC servers added to responses (unconditionally > at first). > > However, “DNSSEC answer Okay” is also misnamed: The bit was introduced > for the first version of DNSSEC. We are now to the second or third > version (depending on how you look at it). If an older implementation > (of the first DNSSEC version, or DNSSECbis without NSEC3 support) > encounters current responses, they contain unknown records again > because the record numbers have changed, so it's essentially the same > situation that prompted the introduction of the DO bit. But these > clients are obviously okay with that, otherwise we would have needed > another DO bit to request the newer DNSSEC records. > > This tells me that DO is not really about DNSSEC in practice. It only > means that the client indicates that it is (in some sense) modern and > willing to discard unknown records and flags. > > As a side effect of setting DO in the query, AD becomes available. A > second way to achieve that is to set AD in the query. > > > Postfix then uses the ad bit to trust that information is > > authentic. The sysadmin has responsibility to ensure that (the path > > to) their resolver is secure. > > But it often was not, so the AD bit is not a strong indicator. > > What we tried with the glibc change was to make sure that the AD bit > is trustworthy. In general, we found no way to do this except through > opt-in from the system administrator. If the operating system has a > way to launch a preconfigured local DNS resolver (on 127.0.0.1), this > mechanism needs to be enhanced to add the trust-ad option (perhaps > after a review that the AD bit handling in that implementation is > reasonable). > > I forgot to arrange for the second part to be implemented in Fedora 32 > (and Debian), for which I need to apologize. I filed a NetworkManager > bug here: > > <https://bugzilla.redhat.com/show_bug.cgi?id=1825285> > > cloud-init needs some work as well: > > <https://lists.launchpad.net/cloud-init/msg00267.html> > > And for Debian's resolvconf: > > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958045> > > >> The intent of this change in glibc was that NetworkManager (or > >> whatever generates /etc/resolv.conf) figures out whether the > >> configured resolver performs DNSSEC validation and can be trusted to > >> set the AD bit accordingly. > > > >> If you patch Postfix to add back the flag unconditionally, > >> disregarding the name server trust status, then maybe handling the AD > >> bit in this way was not such a good idea after all. > > > > My patch does not make security any worse than it was prior to > > GLIBC 2.31. This is all I can do for stable Postfix releases: > > ensure that shit does not stop working after an OS update. > > > > Any 'improvements' in Postfix DNSSEC support will have to be developed > > in the Postfix 3.6 release cycle. The results from those 'improvements' > > will never be merged back into Postfix 3.5 and earlier. > > I'm trying to understand why you were trusting the AD bit. Is it > because you consider the requirement in the RFC to perform DNSSEC > validation optional? We looked at this and thought we needed the flag > masking in glibc, with an explicit configuration decision (at the > glibc layer) to mark the resolvers as trusted to handle the AD bit as > expected. > > The behavior is already configurable at the glibc layer. It does not > make sense to me to add another knob to Postfix itself. > > My worry here is that if Postfix (as the de-facto secure mailer) uses > RES_TRUSTAD in this way, others will follow suit, and then libraries > can no longer use the AD bit to indicate successful DNSSEC validation. > > (The -fcommon part of your patch is unrelated to all that, of course.)
This reasoning is why I consider it harmful to limit use of DANE records to situations where the DNS lookup is "trusted" to have been validated -- it just encourages flipping a switch to "trust" servers that shouldn't be trusted. The right behavior (regardless of what any RFC says) is to use any TLSA records you're able to lookup. If the configured nameservers are validating DNSSEC and your link to them is secure, you get the full protection DANE provides. If they're not, the behavior is no worse (and in many ways better) than what you'd get by not having DANE at all. Yes an attacker could perform DoS by giving you invalid TLSA records or MITM the connection by providing ones for a key they control, but if you switch DANE completely off then an attacker in the same position can do these things anyway. Rich
