Building consensus over DNSSEC enhancements to glibc.

[Petr Spacek]

On 16.11.2015 15:00, Florian Weimer wrote:
> 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?

Hmm, I apparently did not send the reply :-) Anyway, in my eyes 'search' is
inherently incompatible with domain name-based checks (be it TLS or DNSSEC or
whatever else).

Speaking about AD bit, theoretically it could be set 1 if *all* intermediate
results had the bit set to 1, but I'm worried that applications would not
handle it correctly: Application would have to receive back the terminal name
which was found & use the name for domain name checks, which is error prone
and adds yet another layer which application developer has to take care of.

Given that in TLS world search directive and use of short names lead to
validation failures (unless the cert contains the short name ...) I would
strip the AD bit if search is in use & name returned is not the same as name
originally requested by the caller.

-- 
Petr^2 Spacek