Building consensus over DNSSEC enhancements to glibc.

[Paul Wouters]

On 11/17/2015 01:58 PM, Carlos O'Donell wrote:

> The option strips the AD-bit from responses returned by libresolv to
> cause all applications using libresolv to see unauthenticated data.
> 
> e.g.
> 
> openssh-7.1p1/openbsd-compat/getrrsetbyname.c 
> 
> 274 #ifdef HAVE_HEADER_AD
> 275         /* check for authenticated data */
> 276         if (response->header.ad == 1)
> 277                 rrset->rri_flags |= RRSET_VALIDATED;
> 278 #endif
> 
> openssh-7.1p1/dns.c
> 
> 239         if (fingerprints->rri_flags & RRSET_VALIDATED) {
> 240                 *flags |= DNS_VERIFY_SECURE;
> 241                 debug("found %d secure fingerprints in DNS",
> 242                     fingerprints->rri_nrdatas);
> 243         } else {
> 
> This would prevent the ssh client from thinking it had secure
> fingerprints loaded via DNS.
> 
> A secure system that is migrating from being insecure to having
> validation over a secure channel (local validating resolver) would
> immediately set the options flag in /etc/resolv.conf before
> upgrading and clear it after the upgrade when the results could
> be trusted.
> 
> Optionally NetworkManager via resolvconf (coordinating /etc/resolv.conf
> changes) could set the option if only one insecure public network
> was connected to the system.

So indeed, this is an insecure solution. One write to /etc/resolv.conf and all
trusted applications are compromised. Applications like gpg or ssh or openpgpkey-milter
or even browsers checking TLSA records should not bet their security on this.

If that is the only API to be offered, I recommend we patch the applications with the
"postfix method" instead and for now limit ourselves with dnssec only if localhost is
specified in resolv.conf.

Note that with the openssh client, I have seen situations where it trusts the SSHFP while it should not. I haven't
figured out exactly when this happens. It is not easilly reproducable.

Paul

Paul