Building consensus over DNSSEC enhancements to glibc.

[Petr Spacek]

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