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: Rich Felker <dalias at libc dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 18 Nov 2015 13:49:30 +0100
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <20151110174923 dot GS3818 at brightrain dot aerifal dot cx> <56433969 dot 10405 at redhat dot com> <20151111154525 dot GW3818 at brightrain dot aerifal dot cx> <56436FB2 dot 2010302 at redhat dot com> <20151111170706 dot GY3818 at brightrain dot aerifal dot cx> <5649BB13 dot 6040907 at redhat dot com> <20151116162328 dot GR3818 at brightrain dot aerifal dot cx> <564A1CB0 dot 7080508 at redhat dot com> <20151116182146 dot GT3818 at brightrain dot aerifal dot cx> <564A2968 dot 70003 at redhat dot com> <20151117050327 dot GW3818 at brightrain dot aerifal dot cx>
On 17.11.2015 06:03, Rich Felker wrote:
>> > And now imagine a system which does not have validator installed or running
>> > for some reason. Attacker can still play the same tricks as in cases (2) and
>> > (5). Given the fact that validator is not present, we must treat the data as
>> > if result of DNSSEC validation was "indeterminate", i.e. clear AD flag. This
>> > prevents applications from accepting forged data which has to be
>> > cryptographicaly secure.
> Agreed.
>
>> > Please note that necessary level of trust is different for different DNS
>> > record types. For A/AAAA records it is widely accepted that results may be
>> > forget and applications are counting with that. For other purposes like TLS
>> > certificate validation it is necessary to have full confidence in the data, so
>> > validation results has to be properly communicated to the application. The
>> > list of "must be secure" record types is changing over time, so it is not
>> > feasible to hardcode list to resolver libraries.
> I think the confusion that's had us talking past each other is that my
> model was just A/AAAA/CNAME/PTR records, which are the only things the
> standard libc APIs give applications easy access to. For these, IMO,
> there's little meaning in exposing the AD bit to the application. On a
> secure client setup, you know just by getting a reply that the record
> is either signed or under a domain that doesn't use DNSSEC. And on an
> insecure setup you just have to assume any result could be forged
> (same as the pre-DNSSEC world).
>
> Anyway, what I'm not clear on is how you would want to expose the AD
> bit to applications wanting to do TLSA lookups, since there's not even
> an application-friendly API for this. There's just res_send. So is
> your proposal that res_send should patch up the result payload to
> remove the AD bit unless the nameserver is configured as trusted? Or
> do you want new APIs for other record types, or some extension to
> getaddrinfo for them?
I will attempt to merge sub-threads together, please see
https://sourceware.org/ml/libc-alpha/2015-11/msg00335.html
for an example. This is how it works today in OpenSSH and more or less with
Postfix.
--
Petr Spacek @ Red Hat