Subject: Re: [dane] An AD bit discussion

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Feb 2014 20:52:50 -0500

Simo Sorce <[email-masked]> wrote:
    >> For this reason, I think that applications should not set or depend
    >> upon the AD bit, even if the resolver is ::1.  They either understand
    >> DNS(SEC), or they use an API call way more sophisticated than
    >> getaddrinfo() to do their connections.  Java had the right idea, but
    >> the implementation and error reporting was very poor.

    > Nothing in this proposal prevents you from doing that for applications
    > you care about. OTOH forcing applications to a completely new API by
    > refusing this proposal on your grounds will guarantee less applications
    > will use DNSSEC. And DNSEC support will rapidly fragment making
    > system-wide management a lot more difficult. I think that prospect is a
    > much worse evil.

If I understand what you are saying, you are worried that different
applications will make up different DNSSEC APIs, and each application will
have different controls.

I am not opposed to centralized DNSSEC resolution (whether on the same host,
or via a trusted channel).  It's that I am dissastified with "SERVFAIL"
as the only indication of a problem... 

-- 
Michael Richardson
-on the road-

---

From: Simo Sorce <[email-masked]>
Date: Sat, 01 Mar 2014 13:05:07 -0500

> applications will make up different DNSSEC APIs, and each application will

Yes this is the worry, getting to an unmanageable situation that will
discourage people from using DNSSEC.

> as the only indication of a problem... 

Understandable, but I have the impression this is a separate problem.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: Michael Richardson <[email-masked]>
Date: Sun, 02 Mar 2014 09:04:17 -0500

> Understandable, but I have the impression this is a separate problem.

The only *API* that we presently have is built on top of resolv.conf which
makes use to *DNS*, and that API's only DNSSEC control is *AD*.  So, it's not
as yet, a separate problem.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Sun, 02 Mar 2014 09:05:36 -0500

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: Florian Weimer <[email-masked]>
Date: Sat, 08 Mar 2014 18:05:55 +0100

* Paul Wouters:

> Sorry, I mistook the flags in the struct to be the DNS flags. Let me
> rephrase it as "a DNS API call that returns the presence or lack of
> AD bit"

I think this focus on the AD bit is a grave mistake.  There are other
technologies for securing DNS data.  At least one of them (installing
an authenticated copy of the zone in the resolver) is superior to
DNSSEC according to various criteria, but full implementation requires
that the resolver clears the AD bit.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Mar 2014 17:46:39 +1100

> that the resolver clears the AD bit.

You can set AD=1 with a local copy of the zone.  I actually run
named locally like this with full dnssec validation of results
returned from the local zone.  You can also just assert AD=1 without
doing validation if that is what your local policy states on secure
transfer.

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Petr Spacek <[email-masked]>
Date: Tue, 11 Mar 2014 08:32:35 +0100

> doing validation if that is what your local policy states on secure

Maybe it is not a problem but I have to ask:

What if DS records in parent zone are somehow broken? Validating resolvers 
will see the child zone as bogus but authoritative server for such zone will 
happily set AD=1.

I'm curious if this conflicts with AD bit definition in RFCs or not.

-- 
Petr^2 Spacek

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Mar 2014 19:09:01 +1100

> will see the child zone as bogus but authoritative server for such zone will 

Yes.
 
> I'm curious if this conflicts with AD bit definition in RFCs or not.
 
It is permitted.

---

From: Petr Spacek <[email-masked]>
Date: Wed, 19 Mar 2014 11:28:37 +0100

Hello list,

On 26.2.2014 20:11, Viktor Dukhovni wrote:
> On Wed, Feb 26, 2014 at 07:02:45PM +0000, Tony Finch wrote:
>
>> Viktor Dukhovni <[email-masked]> wrote:
>>
>>> I think it requires EDNS0,
>>
>> The AD bit is in the message header not the OPT pseudo-RR, so
>> syntactically it doesn't require EDNS0. BIND works OK (try
>> dig +qr +noedns). However the spec is silent on this matter.
>> http://tools.ietf.org/html/rfc6840#page-10
>> Also I think it is arguable that RFC 4035 says servers should set the
>> AD flag in the response regardless of whether the client indicates
>> it is security-aware. But implementations do not do that.
>
> You're right about the AD bit of course,  I was thinking of "DO".
> Below setting either "AD=1" or "DO=1" elicits a validated response
> from unbound, but with "DO=1" additional RRSIG records are returned.
> The libresolv API does not currently expose a portable mechanism
> for setting AD=1 in requests.

I have heard that there was a discussion about AD bit handling at IETF 89. 
Could somebody summarize it, please?

I understand that everybody is more interested in DANE and DNS-privacy but I 
would like to finish this discussion and either drop the AD-bit special 
handling altogether or move to implementation phase :-)

Thank you very much for your time!

-- 
Petr^2 Spacek