This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Building consensus over DNSSEC enhancements to glibc.
- From: Petr Spacek <pspacek at redhat dot com>
- To: libc-alpha at sourceware dot org
- Cc: carlos at redhat dot com
- Date: Thu, 19 Nov 2015 15:03:58 +0100
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <563CED63 dot 1070201 at redhat dot com> <20151106182835 dot GC3818 at brightrain dot aerifal dot cx> <563D0953 dot 9020707 at redhat dot com> <56407C19 dot 2080906 at redhat dot com> <20151109180310 dot GO3818 at brightrain dot aerifal dot cx> <5649A3F3 dot 2060309 at redhat dot com> <20151116161642 dot GQ3818 at brightrain dot aerifal dot cx> <564A0FED dot 9010408 at redhat dot com> <20151116181740 dot GS3818 at brightrain dot aerifal dot cx> <564A1E3E dot 5090703 at redhat dot com> <20151116182322 dot GU3818 at brightrain dot aerifal dot cx> <564AB3F9 dot 4020404 at redhat dot com> <564AC146 dot 1040305 at redhat dot com> <564AD51D dot 4040100 at redhat dot com> <564B3FA7 dot 8010100 at redhat dot com> <564D69F2 dot 7080904 at redhat dot com>
On 19.11.2015 07:19, Carlos O'Donell wrote:
> On 11/17/2015 09:54 AM, Simo Sorce wrote:
>> I would prefer if glibc (and all other libraries) gave this
>> information to applications themselves, as it would be more
>> efficient. The "out of libc" method causes resolv.conf to be re-read
>> 3 times which is a burden for short lived processes but is better
>> than not trusting glibc and having applications implement their own
>> crypto or have a dozen different methods to "configure" DNSSEC.
>
> I believe the following answers all of the questions in your email,
> and resolves the use cases you brought forward. If I missed one, please
> provide it again and I'll see what I can do.
This sounds very good as far as I understood it :-) I will try to clarify few
things just to be sure we understand each other.
> I think that defaulting to stripping the AD-bit *and* providing a way
> for an application to know which resolv.conf option was set at
> startup would allow the application to know the following:
>
> * Assume DNSSEC AD-bit untrusted by default in glibc.
>
> - Modern glibc will strip AD-bit by default without `options: dnssec-enforced`
> specified in /etc/resolv.conf
>
> - Old glibc will not strip AD-bit.
>
> - Applications that want to read /etc/resolv.conf as a heuristic
> can look for `dnssec-enforced` option. Not the recommended way.
>
> * Is the system enforcing DNSSEC (to use an SELinux term)?
>
> - Use up a res._options bit for RES_DNSSEC_ENFORCED, meaning the
> admin has secured the system and DNS results follow DNSSEC rules.
>
> e.g.
> diff --git a/resolv/resolv.h b/resolv/resolv.h
> index 53c3bba..e886610 100644
> --- a/resolv/resolv.h
> +++ b/resolv/resolv.h
> @@ -221,6 +221,7 @@ struct res_sym {
> #define RES_USE_DNSSEC 0x00800000 /* use DNSSEC using OK bit in OPT */
> #define RES_NOTLDQUERY 0x01000000 /* Do not look up unqualified name
> as a TLD. */
> +#define RES_DNSSEC_ENFORCED 0x02000000 /* System is enforcing DNSSEC. */
>
> #define RES_DEFAULT (RES_RECURSE|RES_DEFNAMES|RES_DNSRCH|RES_NOIP6DOTINT)
> ---
>
> - res._options has RES_DNSSEC_ENFORCED set (indicates /etc/resolv.conf
> had the `options: dnssec-enforced`. So yes we are enforcing
> DNSSEC and AD-bit is not stripped, and all listed servers are trusted.
>
> - Use all the normal APIs knowing the results are secure or indeterminate.
>
> - Connected validating resolvers are trusted and drop insecure
> and bogus results.
Detail:
Neither DNS-wire format nor applications distinguish between "indeterminate"
and "insecure". This is expected and follows RFC 4033 section 5. In both cases
AD bit = 0 so consumers will know that particular RR set was not authenticated
and cannot be used for security decisions.
Validating resolvers will drop bogus answers (this includes case where
attacker stripped DNSSEC metadata from answers!).
The logic in consumer should be the results can be trusted if and only ...
if (res._options & RES_DNSSEC_ENFORCED & response->header.ad == 1)
// data can be trusted
else
// data cannot be trusted
Applications might potentially skip some DNS queries
if (res._options & RES_DNSSEC_ENFORCED == 0)
because they now beforehand that it does not make sense to even try it.
> - res._options does not have RES_DNSSEC_ENFORCED set. So no.
>
> - Only APIs that have explicity trust information can be used.
Carlos, could you be more specific? I'm not sure what exactly you mean.
I would expect that 'old' functions which do not know anything about DNSSEC
will work as before, e.g. getaddrinfo() will do what it does today, except the
fact that arrays returned by res_query() will have AD bit zeroed out.
Looking from upgrade perspective, anything more restrictive may break the
system when glibc is upgraded but `options: dnssec-enforced` is not added to
/etc/resolv.conf. This may easily happen when glibc is upgraded but validator
needs manual configuration.
This should not be a problem because any application doing
if (res._options & RES_DNSSEC_ENFORCED & response->header.ad == 1)
will not use not-trustworthy-data.
> - Use getdns API.
>
> - Use new glibc APIs with DNSSEC flags per Petr's suggestions.
I guess that you meant new flag for getaddrinfo() etc. to get only secure
results. Yes, that is an option, but I certainly do not insist on that.
Highest impact is on res_*() functions because these are used to obtain
TLSA/SSHFP records etc.
> Regardless of the mode the application can use the extended APIs with
> DNSSEC flags to receive perhaps all the results of a query along with
> trust information so it can decide which results to use and which to
> discard. Likewise the extended APIs with flags that request only secure
> results are also a valid option.
> You must still lock down /etc/resolv.conf to prevent someone from marking
> the system as secure when it is not.
>
> Higher level policy frameworks have to decide what to do about multiple
> connected interfaces, mixtures of trusted and untrusted networks, etc.
> etc. and route that information to the validating resolver whose results
> go to the stub resolver which is part of the running application process.
Yes, this is what dnssec-trigger is going to do in Fedora.
> How does that sound?
Good, thank you very much!
--
Petr Spacek @ Red Hat