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: Florian Weimer <fweimer at redhat dot com>, Rich Felker <dalias at libc dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 16 Nov 2015 14:27:53 +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>
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)?
The context here *is* important. I do not think that applying generic rule
like 'never do this' or 'always do that' is useful, sorry.
--
Petr Spacek @ Red Hat