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: Florian Weimer <fweimer at redhat dot com>
- To: Petr Spacek <pspacek at redhat dot com>
- Cc: Rich Felker <dalias at libc dot org>, libc-alpha at sourceware dot org
- Date: Mon, 16 Nov 2015 15:00:51 +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> <5641C454 dot 3030309 at redhat dot com> <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> <5649D87E dot 6080105 at redhat dot com> <5649D9D9 dot 4040206 at redhat dot com>
On 11/16/2015 02:27 PM, Petr Spacek wrote:
> On 16.11.2015 14:22, Florian Weimer wrote:
>> On 11/16/2015 12:16 PM, Petr Spacek wrote:
>>
>>> 'Not using DNSSEC: same situation as now' goes directly against the gold DNS
>>> standard. Please see original (i.e. pre-DNSSEC) RFC 1035:
>>> http://tools.ietf.org/html/rfc1035#page-26 section 4.1.1 Header section format.
>>>
>>> It clearly states what to do with bits 9, 10 (AD), and 11 in message header:
>>> "Reserved for future use. Must be zero in all queries and responses." So, if
>>> you decide not to use/ignore DNSSEC please do it in a standard-compilant and
>>> at the same time secure way: Zero out these bits unconditionally.
>>
>> I'm sorry, but this argument is invalid. DNSSEC violates this clause in
>> RFC 1035. As a result, you cannot blame host A for turning
>> non-compliant when speaking to host B, which implements DNSSEC, violates
>> RFC 1035 requirements, and indirectly causes the non-compliance of host A.
>>
>> In general, the DNS RFCs do not support this level of exegesis.
>>
>> From a technical point of view, clearing reserved protocol elements has
>> caused significant issues in the past; see the ECN signaling problems
>> encountered in the wild for an example. This is why I have reservations
>> about your proposal above, no matter what the RFCs say here.
>
> Honestly, I can't believe my eyes. 'no matter what the RFCs say here' even
> though the end result is an insecure system (because all other proposals to
> make it fail-safe were refused)?
Let's cut down the hyperbole a bit.
I am not opposed to deliberate clear the AD flag on replies (but not
queries) under certain circumstances. But I am opposed to clearing the
CD flag (on queries and responses) or the remaining reserved flag in the
original DNSSEC protocol header.
Based on your interpretation of RFC 1035, libresolv has to break the CD
flag by zeroing it, which is, I think, not desirable. This invalidates
your argument, but not AD flag special processing as such.
By the way, have you had a chance to review how an AD flag policy should
interact with the search path configured in /etc/resolv.conf?
Florian