Subject: [dane] An AD bit discussion

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Feb 2014 09:12:20 -0500 (EST)

Hi,

I've been part of a very long and heated discussion about the trust of
the AD bit. I would like to hear from people here what they think.

I'm currently aware of two (non-dns utilities) applications that make
security decisions based on "blindly" trusting the AD bit: ssh with
VerifyHostKeyDNS=yes|ask and Postfix.

libreswan and strongswan are examples of applications that use libunbound
for in-application DNSSEC validation to avoid needing to trust
/etc/resolv.conf DNS servers for the AD bit.

First, let me list 4 items everyone seems to agree on:

1 Applications can either do dnssec validation themselves, or trust the
   AD bit.

2 It is undesirable that each application has its own DNSSEC validation
   code, trust anchors and DNS cache.

3 It is undesirable that applications blindly trust the AD bit when
   resolv.conf points to another host as the AD bit could have been modified
   on the network.

4 In the ideal world tomorrow, each host has its own automatically
   configured, perfectly working validing DNS server and resolv.conf can
   be ignored or is always hardcoded with nameserver 127.0.0.1

Now for my question. Until we reach 4), what should we do with the AD
bit in getaddrinfo() ?

A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new
    configuration mechanism will allow white-listing nameservers and 127.0.0.1
    will always be on the whitelist.

B) do nothing

C) Something else, please specify

Paul

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Feb 2014 01:41:21 +1100

> First, let me list 4 items everyone seems to agree on:

Actually 2 is very much not agreeded apon by everyone.

> _______________________________________________
> 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: Ondřej Surý <[email-masked]>
Date: Wed, 26 Feb 2014 16:39:35 +0100

Hi Paul,

>  be ignored or is always hardcoded with nameserver 127.0.0.1

My personal opinion on that matter is that the application should not have to care about that and they should just use (some) API to get the validated response from system library (not necessarily glibc).

>   will always be on the whitelist.

This seems to be reasonable to me for the time being.

> C) Something else, please specify

O.
--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 26 Feb 2014 15:57:52 +0000

>   be ignored or is always hardcoded with nameserver 127.0.0.1

This is also my ideal world of tomorrow.

> Now for my question. Until we reach 4), what should we do with the AD

I was not aware of any mechanism in getaddrinfo() to communicate
the AD bit?  Is this a new getaddrinfo() implementation with features
I've not looked at yet?

Also getaddrinfo() typically uses RES_DEFNAMES and RES_SEARCH,
which make the meaning of any security bit rather ambiguous.
When the input is not a fully-qualified DNS name, what is it
the user has learned to be secure?

What happens when one of the domains on the search list returns
NXDOMAIN (without proof non-existence), but a subsequent suffix
yields a "secure" result?

I am fairly confident that security is rather elusive when the
input name is only partially specified.  Lots of ways to get
this wrong.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Feb 2014 11:16:36 -0500 (EST)

> the AD bit?  Is this a new getaddrinfo() implementation with features

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"

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 26 Feb 2014 16:22:21 +0000

> rephrase it as "a DNS API call that returns the presence or lack of AD bit"

I, for one, no longer know what you're asking.  Not enough context.
If your question is not about getaddrinfo(), can you ask it again
with a bit of context?  Are you asking what applications should
(in general?) do with the AD bit from stub resolvers?  Or how
libraries should report the AD bit from DNS to applications when
the library has a mechanism to do so unambiguously?  Or ...?

-- 
	Viktor.

---

From: Petr Spacek <[email-masked]>
Date: Wed, 26 Feb 2014 17:27:43 +0100

Greetings,

> the library has a mechanism to do so unambiguously?  Or ...?

Paul and me have accidentally open threads about the same topic on this list 
and also on dnsop-list. I guess that this discussion fits better here so I 
will post our reasoning.

Please note that we would like to discuss the right implementation approach 
with you and not to push described proposal.

I work in Red Hat's Identity Management group and my opinions can differ from 
Paul's, don't be surprised. (I.e. "we" in following text doesn't necessarily 
include Paul

We can see two very basic approaches:
A) Do DNSSEC response validation in each application.
B) Let recursive resolver do the validation and use AD bit in the application.

We consider the first approach (i.e. each application doing response 
validation) too heavy-weight and hard to administer for various reasons:
- Response validation is sensitive operation and application programmers 
should not do it themselves.
- A variant where every application calls validation library is still not 
optimal. Experience with crypto libraries shows that there are many 
opportunities to use a library
incorrectly (in a way which works but is not secure).
- This approach has potential to create administrative nightmare if each 
application decides to maintain own set of trust anchors etc. We can see 
results of such approach in
  PKI world ...

We believe that better approach is to centralize validation in local 
system-wide recursive resolver and use AD bit for signaling that data are 
trustworthy to applications. A
n application should use stub-resolver to talk to local recursive resolver and 
use received AD bit to decide e.g. if it is possible to trust TLSA records or not.

Unfortunately, there are use cases where neither a locally running validating 
resolver nor a trusted path to a remote resolver are available and deployment 
of such is unacceptable.

It seems that existing stub-resolvers unconditionally trust recursive 
resolvers and just forward the AD bit back and forth. This behavior is okay 
only if no application relays on the AD bit. In other words, supporting DANE 
with current stub-resolvers practically requires to add a configuration option 
'recursive resolver is un/trusted' to each and every DANE-enabled application 
and library. (This is exactly what OpenSSH client does. An additional problem 
is that this value has to be maintained as network configuration changes over 
time.)

We would like to make DNSSEC implementation in applications as simple and 
secure as possible. That is a reason why we are looking for a solution for a 
case where AD bit can't be trusted because validating resolver is not 
available for whatever reason. It would allow applications to use AD bit 
without explicit configuration per-application if we solve this case somehow.

Is there any 'standard' way to handle described situation?

We have the following proposal (some people say it is controversial):
- Extend stub-resolvers with a new call for resolver initialization: In case 
of ldns it would be something like: ldns_resolver_new_frm_file_trusted().
- The new call will initialize library as usual + read some system-wide 
configuration (it can be whatever, imagine for example a new file 
/etc/resolv.trusted).
- Client applications will use the same API (except the initialization) to do 
DNS queries.
- When a DNS answer is received from network the stub-resolver will consult 
configuration read from /etc/resolv.trusted:
-- If the particular recursive resolver is listed as trusted - pass AD bit to 
the application.
-- *Otherwise: Clear AD bit and pass the answer with AD=0 to the application.*

This allows an administrator to configure system-wide policy. In case with 
locally running validating resolver or e.g. IPSec tunnel to trusted resolver 
admin can declare it as trusted and nothing changes. However, this mechanism 
allows the system to be safe even in configurations *without* validating 
resolver. No explicit configuration in application is need, just one 
system-wide setting.

It could seem like a minor improvement or a hack, but it allows applications 
to trust the AD bit unconditionally and as a result it significantly 
simplifies DNSSEC implementation and configuration on client machines. We hope 
that this simple approach will allow us to implement and deploy DANE and 
similar technologies widely.

This proposal can be seen as temporary solution before secure transport 
mechanisms like IPSec or CGA-TSIG are widelly available and used. The main 
advantage is that it is easy to implement and it doesn't require any new 
technology so we can use it in applications today.

We would like to hear your opinions and recommendations for this area.

Thank you for your time.

-- 
Petr Spacek @ Red Hat

---

From: Petr Spacek <[email-masked]>
Date: Wed, 26 Feb 2014 16:59:55 +0100

Greetings,

include Paul :-)

Thank you for your time.

-- 
Petr Spacek @ Red Hat

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 26 Feb 2014 17:10:11 +0000

On Wed, Feb 26, 2014 at 05:27:43PM +0100, Petr Spacek wrote:

> trustworthy to applications. An application should use stub-resolver to
> talk to local recursive resolver and use received AD bit to decide e.g.
> if it is possible to trust TLSA records or not.
>
> Unfortunately, there are use cases where neither a locally running
> validating resolver nor a trusted path to a remote resolver are available
> and deployment of such is unacceptable.

Please adopt the more modern BSD-style res_ninit(), ... libresolv
interface which improves thread-safety of the stub resolver, and
allows clients to set or query the server list via res_setservers()
and res_getservers().  Extend that API to include a res_ninit_ex()
(or similar) that can specify an alternative resolv.conf file (in
coordination with other implementations if possible).

Some applications will want to explicitly ensure that the trusted
recursive resolver is local.  Others, for better or worse, may
prefer to trust the administrator's judgement about which recursive
resolvers are secure.  See this and related posts in thread by the
same author:

    http://archives.neohapsis.com/archives/postfix/2014-02/0499.html

Applications, that place trust in the AD bit (choose to not implement
their own validation) should be able to decide whether they also
trust everything in /etc/resolv.conf, or whether they'd rather be
sure.

Paul Hoffman's new DNS API may also be something to consider.  I
am hoping Paul or someone else intimately familiar with it can
chime in about that.

> secure as possible. That is a reason why we are looking for a solution
> for a case where AD bit can't be trusted because validating resolver is
> not available for whatever reason. It would allow applications to use AD
> bit without explicit configuration per-application if we solve this case
> somehow.
> 

No.  But you could extend /etc/resolv.conf to support a verb that
marks the AD bit authoritative.  If the file is maintained by the
administrator and uses the new verb, the AD bit is passed on,
otherwise (as e.g. with /etc/resolv.conf populated by DHCP) it is
ignored.  This could be useful for applications that don't want to
employ res_[sg]etserver().

>  - Extend stub-resolvers with a new call for resolver initialization:  In
>    case of ldns it would be something like:
>
>	ldns_resolver_new_frm_file_trusted().
>
>  - Client applications will use the same API (except the initialization)
>    to do DNS queries.
>
>      -- If the particular recursive resolver is listed as trusted - pass
>         AD bit to the application.

>      -- *Otherwise: Clear AD bit and pass the answer with AD=0 to the

I think this is unwise, forcing all applications that want validated
results to make new platform-specific calls is unwise.  Instead
extend the /etc/resolv.conf syntax:

	nameserver 127.0.0.1
	ad_trusted yes

the default can be "ad_trusted no".  Applications that want to
control the server list and specify a corresponding value of
"ad_trusted" can employ a custom resolv.conf file or call
res_setservers(), which would turn on the AD bit (the application
knows which servers it asked for, and can decide whether to believe
the AD bit).

> mechanisms like IPSec or CGA-TSIG are widely available and used. The main

I don't expect wide adoption of IPSec or TSIG any time soon if ever.

> We would like to hear your opinions and recommendations for this area.

Whatever you do, don't force applications to make new calls to
avoid having the AD bit clobbered by the stub resolver.  It must
be possible to configure the system so that the AD is usable with
no changes to applications using the resolver API.

Thus the suggestion to move the signal out of the application and
into /etc/resolv.conf.

-- 
	Viktor.

---

From: Tony Finch <[email-masked]>
Date: Wed, 26 Feb 2014 17:24:37 +0000

> VerifyHostKeyDNS=yes|ask and Postfix.

Note that OpenSSH can be linked with ldns to do its own validation.

> 1 Applications can either do dnssec validation themselves, or trust the

At the moment I consider in-process validation to be the safer way to do
it, because apps do not have any sane way to verify that it is safe to
trust the AD bit (more about that below). That is, by doing its own
validation the app is better able to guarantee safety, without assuming
that there is an expert and diligent sysadmin who is able to do arcane
things like override the DHCP server's suggested nameserver addresses.

>   code, trust anchors and DNS cache.

Agreed, but there are some subtleties. It's probably not too bad if the
validation code is in a shared library that is centrally configured - like
the traditional resolver or ldns's resolver. However if ldns's resolver
were to be more widely used it will need MUCH better trust anchor
management. Even so a system-wide cache should perform better. Perhaps
multi-user systems should have per-user validating caches so that users
don't have to trust each other too much :-)

>   resolv.conf points to another host as the AD bit could have been modified

Right. What makes this particularly pernicious is that the resolver API
does not give an app any reasonable way to find out if it would be safe to
trust the AD bit.

To do so the app would have to extract the name server addresses from the
__res_state and compare that with the system's list of network interface
addresses. The layout of __res_state is private and the way IPv6 support
has been added varies wildly between different flavours of unix. Utterly
horrible.

>   be ignored or is always hardcoded with nameserver 127.0.0.1

That would be nice :-)

>    will always be on the whitelist.

That sounds like a fair plan.

Note that what ssh does is use the low-level res_query() API which returns
a raw DNS packet, and examines the AD bit in the packet header.
http://svnweb.freebsd.org/base/vendor-crypto/openssh/6.5p1/openbsd-compat/getrrsetbyname.c?revision=261288&view=markup#l274
Exim's preliminary DNSSEC support does the same.
http://git.exim.org/exim.git/blob/HEAD:/src/src/dns.c#l430

So you should change the low-level parts of the traditional resolver to
clear the AD bit in the packet header before returning to any higher level
code, unless the connection to the nameserver is known to be safe.

Question: along with this change are you planning to change the resolver
to set the AD flag in queries when the nameserver is known to be safe?

Usually the AD flag only appears in responses if the query had the AD or
DO flags set. DO is a bit wasteful for clients that only care about the AD
bit. However the only DNSSEC switch that libc resolvers currently have is
options edns0 (which implies DO).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Malin: West or southwest 5 to 7, backing south 6 to gale 8 for a time. Rough
or very rough. Showers, rain for a time. Good, occasionally poor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 26 Feb 2014 17:36:30 +0000

> That sounds like a fair plan.

It is in fact problematic if both 127.0.0.1 and another nameserver
are listed.  The correct semantics of that are hard to define.  It
makes more sense to define a boolean primitive that marks all the
nameservers collectively as either trusted or not.

> options edns0 (which implies DO).

The RES_USE_DNSSEC flag turns on the "DO" bit.  I would be surprised
if RES_USE_EDNS0 enabled "DO".  As for setting the "AD" bit in the
request automatically, it probably should still require an explicit
indication of interest from the application or be set via a default
option value /etc/resolv.conf.

-- 
	Viktor.

---

From: Petr Spacek <[email-masked]>
Date: Wed, 26 Feb 2014 18:41:33 +0100

> things like override the DHCP server's suggested nameserver addresses.
A proposal sent to the other thread
(http://www.ietf.org/mail-archive/web/dane/current/msg06475.html)
attempts to address this problem with explicit name server white-listing.

> don't have to trust each other too much :-)
The mentioned proposal calls for per-system centralized trust anchor management.

> does not give an app any reasonable way to find out if it would be safe to
This is exactly the reason why we propose to strip the AD bit in library so 
application don't need to think about it's trustworthiness.

> code, unless the connection to the nameserver is known to be safe.
Note we are not trying to 'target' one particular library. It would be great 
if we can reach consensus on some universal approach and then actively work 
with DNS library maintainers to add the new behavior to DNS libraries.

> options edns0 (which implies DO).
Could you elaborate on reasons for setting AD=1, please?

-- 
Petr Spacek  @  Red Hat  @  Brno office

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 26 Feb 2014 17:50:12 +0000

> Could you elaborate on reasons for setting AD=1, please?

With "DO=1", applications that only care about the AD bit in the
reply also receive unwanted "RRSIG" records.

Setting "AD=1" may however require a new request option bit, since
RES_USE_DNSSEC sets "DO=1".  I am not sure whether it would be
right to always send "AD=1" when all the nameservers are trusted
and believed to support validation.  Perhaps that's OK, but it may
be prudent to only do this when specifically requested.

-- 
	Viktor.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 26 Feb 2014 13:09:28 -0500

> C) Something else, please specify

<no-hat Just an old time DNSSEC promoter>
I agree with most of what you said. 

Strictly the AD bit "problem" is twofold, 
	a) Application does not know where the AD bit came from nor if the bit/data has been changed in flight. 
	b) Application does not know the security policy of the "entity" that set the AD bit or who operates it. 

a) is caused by the fact that most systems do not do 4) but blindly accept DNS resolvers supplied by 
network configuration protocols like DHCP and RA.  For all practical purposes this while a nice "convenience" it 
is a  security hole that someone will drive a truck though one day (actually they have it is called a coffee shop network) 
To further make things worse there is frequently no integrity protection on the last "hop/mile" between the recursive resolver and 
host stub-resolver. 
 
There is a large hotel chain that advertises that the resolvers used in their hotels are 8.8.8.8 (Google) and two others ISP's 
the answers when sent to directly 8.8.8.8 only about 1/3 of the time look like they come from 8.8.8.8. When asking OpenDNS directly 
the answers are supplied by the resolvers in the DHCP list. This can only be defeated by sending queries to a port != 53 and in some cases
requires TCP connections.

b) This is a big issue, and without some research you can not find this out what the resolver is doing, and then you can 
not be sure if the resolver has special cases where it will not give you the real answers but the ones it is told by higher authority to
give out. 

As what a DNS library should do, IMHO work on setting up a trusted path to a trusted Recursive resolver,
and then add info in the returned structure that gives credibility of the AD bit. 

DNS cookies are one option, TSIG and DNScurve are better, SIG(0) will scale to random servers, 
TLS over long lived TCP/SCCP are also possible, IPsec to resolver will work as well. 
If someone can figure out how to do Encrypted DNS over UDP that would be great. 
If you trust 127.0.0.1 fine but make sure all the answers come from it. 

The biggest difficulty you will face is encryption and Anycast DNS are unfriendly to integrity, 

In summary we need to 
   - deploy security for the last mile
   - extend API's to return info that the application can USE (not what we think it wants) 

	Olafur

---

From: Tony Finch <[email-masked]>
Date: Wed, 26 Feb 2014 18:14:09 +0000

> nameservers collectively as either trusted or not.

Yes.

> if RES_USE_EDNS0 enabled "DO".

Er yes, you are right. I was confused by the way ssh uses the resolver: it
sets RES_USE_DNSSEC only if RES_USE_EDNS0 is set, so putting "options
edns0" in /etc/resolv.conf turns on ssh's trust-AD behaviour. There
is not a separate resolv.conf option for DNSSEC. Grotty.

(Note that when I make statements about resolver behaviour I am checking
boh FreeBSD and glibc - they are pretty consistent in all this.)

> As for setting the "AD" bit in the request automatically, it probably
> should still require an explicit indication of interest from the
> application or be set via a default option value /etc/resolv.conf.

Perhaps, though I think the AD flag is pretty benign.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth, Tyne, Dogger: Southwest 5 to 7, backing south or
southeast 6 to gale 8 for a time. Moderate or rough. Showers then rain.
Good, becoming moderate or poor.

---

From: Tony Finch <[email-masked]>
Date: Wed, 26 Feb 2014 18:16:25 +0000

> reply also receive unwanted "RRSIG" records.

Exactly.

> Setting "AD=1" may however require a new request option bit,

Definitely.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth, Tyne, Dogger: Southwest 5 to 7, backing south or
southeast 6 to gale 8 for a time. Moderate or rough. Showers then rain. Good,
becoming moderate or poor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 26 Feb 2014 18:24:32 +0000

> Perhaps, though I think the AD flag is pretty benign.

I think it requires EDNS0, but if that is already set, perhaps
turning on AD by default is harmless.  This specific detail is
perhaps more of a "dnsop" than "dane" question.

By the way I just noticed that http://www.vpnc.org/getdns-api/
does not define the interaction of DNSSEC with:

    getdns_return_t getdns_context_set_append_name(
	getdns_context *context,
	getdns_append_name_t value );

    Specifies whether to append a suffix to the query string before
    the API starts resolving a name. The value is

	GETDNS_APPEND_NAME_ALWAYS,
	GETDNS_APPEND_NAME_ONLY_TO_SINGLE_LABEL_AFTER_FAILURE,
	GETDNS_APPEND_NAME_ONLY_TO_MULTIPLE_LABEL_NAME_AFTER_FAILURE, or
	GETDNS_APPEND_NAME_NEVER.

    This controls whether or not to append the suffix given by
    getdns_context_set_suffix

Name appending breaks DNSSEC when any of the resulting zones are
insecure and are tried before ultimately secure zones.  The validity
of a request for a secure response for an under-specified query is
IMHO questionable.

-- 
	Viktor.

---

From: Tony Finch <[email-masked]>
Date: Wed, 26 Feb 2014 19:02:45 +0000

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.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet, Irish Sea: South veering west 6 to gale 8, occasionally severe
gale 9 at first. Rough or very rough, occasionally high in Fastnet. Showers,
rain for a time. Good, occasionally poor.

---

From: "Wiley, Glen" <[email-masked]>
Date: Wed, 26 Feb 2014 19:09:57 +0000

Viktor,

Your mention of the getdns api is apropos since we just announced the beat
release of our implementation :)

An application using the getdns api can decide how it will take advantage
of the system files - for example whether it wants to use a search option
which is an improvement over the current approach in which applications
are not aware of whether a suffix was appended to a query.

I would add however that the same root operator that might add a suffix to
resolv.conf could do other nefarious things to resolvers on that host
since the root operator has significant opportunities for MITM attacks on
applications running on that host.

I think the specification takes the most reasonable approach by deferring
to the application to decide the extent to which it will respect
system-wide settings (even including trust anchors).
-- 
Glen Wiley
KK4SFV

Sr. Engineer
The Hive, Verisign, Inc.

---

From: James Cloos <[email-masked]>
Date: Wed, 26 Feb 2014 14:03:40 -0500

>>>>> "PW" == Paul Wouters <[email-masked]> writes:

PW> Now for my question. Until we reach 4), what should we do with the AD
PW> bit in getaddrinfo() ?

PW> A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new
PW>    configuration mechanism will allow white-listing nameservers and 127.0.0.1
PW>    will always be on the whitelist.

PW> B) do nothing

I've always preferred a local resolver, and with dnssec a local
verifier, on every system.  If there are systems unable or unwilling
to do that, then A is a reasonable compromize until they can and will.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 26 Feb 2014 19:11:44 +0000

> 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.

    $ dig +noall +comment +answer +noedns +adflag -t mx debian.org
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28554
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 6

    ;; ANSWER SECTION:
    debian.org.             3567    IN      MX      0 mailly.debian.org.
    debian.org.             3567    IN      MX      0 muffat.debian.org.

    $ dig +noall +comment +answer +dnssec -t mx debian.org
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15599
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 6, ADDITIONAL: 19

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 4096
    ;; ANSWER SECTION:
    debian.org.             3552    IN      MX      0 mailly.debian.org.
    debian.org.             3552    IN      MX      0 muffat.debian.org.
    debian.org.             3552    IN      RRSIG   MX 7 2 ...
    debian.org.             3552    IN      RRSIG   MX 8 2 ...

-- 
	Viktor.

---

From: Andreas Schulze <[email-masked]>
Date: Wed, 26 Feb 2014 20:42:09 +0100

> VerifyHostKeyDNS=yes|ask and Postfix.
opendkim could be linked with libunbound too to mark a dkim key fetched for validation as "secured" or "nonsecured"

> /etc/resolv.conf DNS servers for the AD bit.
opendkim too...
Upon validation DKIM public keys are fetched freom DNS and the validation result
is part of the Authentication-Results header. But there is no further policy decision made.

>   be ignored or is always hardcoded with nameserver 127.0.0.1
Oh, I'm near your ideal world since years :-)

$ cat /etc/resolv.conf 
nameserver ::1

Andreas

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Feb 2014 08:25:40 +1100

The history of the AD bit in responses and it meaning.

RFC 1035 -> AD=0
RFC 2535 -> AD=0/1 (records gone through validation) 
RCC 3225 (DO introduced)
RFC 3655 -> AD=0/1 (DO=1 required, answer and authority sections all secure)
RFC 3755 (type code roll)
RFC 4035 -> AD=0/1 (DO=1 required, answer and authority sections all secure)
RFC 6840 -> AD=0/1 (DO=1 or AD=1 required, answer and authority sections all
		    secure)

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 26 Feb 2014 21:42:20 +0000

> RFC 6840 -> AD=0/1 (DO=1 or AD=1 required, answer and authority sections all

Thanks, this is very useful.  It remains only to determine whether
for platforms on which the proposed designs are being contemplated,
one can reasonably expect the target (reachable securely, typically
local) resolvers to support AD=1 in the query.

This information seems to me to be more likely available to the
administrator configuring *static* resolv.conf settings, than to
an application author or user.

Therefore, my gut reaction is that applications that want the AD
bit need to be able to ask for it, and the stub resolver library
determines how to get the job done with help from resolv.conf.

The stub resolver library may be able to get away with sending AD=1
instead of DO=1 and getting a more compact reply.  And may suppress
RRSIG elements in the answer, authority and additional sections when
the DO=1 was used because AD=1 was not known to be supported.

This still leaves us with the question of how libresolv clients
should signal their interest in the AD bit?  At the very least the
application needs to know that DNSSEC support is not simply
unavailable.

With RES_USE_DNSSEC #defined, the application knows that the run-time
promises to send DO=1.  There needs to be a similar option bit one
can test for at compile-time, and use to signal that the stub-resolver
library should return AD bits without RRSIGs (or with RRSIGs not
specifically required if it is easier to pass them along if returned).

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Feb 2014 09:50:59 +1100

In message <[email-masked]>, Viktor Dukhovni writ
> specifically required if it is easier to pass them along if returned).

Setting AD isn't that hard.  For DANE you aren't going to want to use
res_search() to retrieve the TLSA record so this just unwraps res_query().

	res_mkquery(...,query,...);
	query[3] |= 0x08; // set ad in request
	res_send(query,...);
 
Mark

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 26 Feb 2014 23:16:49 +0000

> 	query[3] |= 0x08; // set ad in request

Thanks for the proof of concept!  From an application developer
perspective, I'd like to suggest that this is not terribly practical
as an application interface.  The decision is made in the wrong place
if this is application code, rather than stub resolver internal code.

For example, Postfix uses res_search for everything, including TLSA
lookups, but being single-threaded, it can safely make temporary
changes in _res.options before each lookup (the original value is
restored when the lookup completes).

#define USER_FLAGS (RES_DEBUG | RES_DNSRCH | RES_DEFNAMES | RES_USE_DNSSEC)
#define XTRA_FLAGS (RES_USE_EDNS0)
#define SAVE_FLAGS (USER_FLAGS | XTRA_FLAGS)
	saved_options = (_res.options & SAVE_FLAGS);
        _res.options &= ~saved_options;
        _res.options |= flags;
        len = res_search(name, C_IN, type, reply->buf, reply->buf_len);
        _res.options &= ~flags;
        _res.options |= saved_options;

Here "flags" is always a subset of "saved_options" that is set for
the current query, the remainder (including RES_DEFNAMES and
RES_DNSRCH) are cleared, unless explicitly requested in "flags".

This is about the lowest level of the libresolv API that Postfix
will use.  Also control over whether the right bit to send is "AD=1"
in the header or "DO=1" in the OPT pseudo-header really belongs
in stub resolver configuration, not in Postfix.

What would make more sense, is the ability to request pre-validated
responses (AD without RRSIG if possible), and have the stub-resolver,
based on /etc/resolv.conf settings, figure out the best way to
satisfy the request.

A new RES_IGNORE_RRSIG or similar option could be used in combination
with RES_USE_DNSSEC signal that an application wants "AD" in
responses, but is not interested in RRSIGs (though might still
get them).  The library would send whichever of "AD=1" or "DO=1"
is specified in resolv.conf as being supported by the designated
nameservers.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Feb 2014 19:41:00 -0500 (EST)

On Wed, 26 Feb 2014, James Cloos wrote:

[ picking this answer because it brings back this thread to my question ]

> to do that, then A is a reasonable compromize until they can and will.

So my fear of that doing A) are negative consequences. Admins installing
a rack of servers or VMs, and pointing resolv.conf to something trusted
nearby, but not on localhost itself, will get the AD bit stripped without
additional configuration. If those people upgrade their systems to the
new A) solution, their applications will no longer see the AD bit.

But so far, it seems I'm the only one worried about that case.

That and I prefer solutions working on obsoleting resolv.conf
over extending it and I think most cases can already be covered by
running a DNS server on localhost - with the exception of laptops
(dnssec-trigger+unbound does not cut it yet for non-techies)

If there are more people who would like to reply to this issue
specifically (as opposed to other APIs or _sending_ AD bits), that
would be useful.

So far it seems people are leaning towards A) over B) while everyone
seems to agree doing DNSSEC on the host itself (server or in-app) is
still the preferred method.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Feb 2014 01:31:56 +0000

> (dnssec-trigger+unbound does not cut it yet for non-techies)

I think obsoleting resolv.conf would be a grave mistake.  More
precisely, control over the security properties of the default list
of recursive resolvers needs to be by default in the hands of the
party that sets up the set of resolvers.  Some applications may
want to tweak this, but out of the box the system administrator
sets the resolver list, and designates them trusted or not.

Applications that delegate validation are rarely well positioned
to know all the gory details, certainly not by default.

So while system configuration may default to fail safe (not lie),
it should be up to the administrator, not the application user or
developer to vouch for the safety of a given configuration.

> still the preferred method.

Modulo some adamant administrators who insist that multiple resolvers
on a physically secured firewalled LAN obviate the need for a local
resolver on each machine, and desperately want to configure trust
in nearby, but not on-host local resolvers.  (See earlier link to
postfix-users list).

For them, I am proposing a damn-the-torpedoes flag in resolv.conf,
global boolean, rather than a one nameserver at a time white-list.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Feb 2014 13:02:27 +1100

In message <[email-masked]>, Viktor Dukhovni writ
> if this is application code, rather than stub resolver internal code.

It wasn't to say that it was practical or best practice. Extending options
to set AD would be useful but there is no reason to wait for that to
happen.

> restored when the lookup completes).

Or one could use res_nsearch/res_nquery and have it work in a threaded
envionment.  Personally I would be using res_{n}query in a MTA to avoid
any possibility of searching.

> in stub resolver configuration, not in Postfix.

res_search and res_query are on the same level.

         len = res_search(name, C_IN, type, reply->buf, reply->buf_len);
         len = res_query(name, C_IN, type, reply->buf, reply->buf_len);
 
Additionally res_search should only proceed to the next name on
NXDOMAIN.  Currently it is type sensitive which is a hold over from
the when always appended the first search element regardless of the
number of labels in it and handling wildcard MX records.  If you had
a MX record like

	*.element.in.search.list MX 0 some.server

you didn't want to stop a search for A records for foo.example.net.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Feb 2014 02:18:38 +0000

> you didn't want to stop a search for A records for foo.example.net.

Looking at somewhat recent NetBSD source:

    switch (statp->res_h_errno) {
    case NO_DATA:
	    got_nodata++;
	    /* FALLTHROUGH */
    case HOST_NOT_FOUND:
	    /* keep trying */
	    break;
    case TRY_AGAIN:
	    if (hp->rcode == SERVFAIL) {
		    /* try next search element, if any */
		    got_servfail++;
		    break;
	    }
	    /* FALLTHROUGH */
    default:
	    /* anything else implies that we're done */
	    done++;
    }

we see that searching continues with NXDOMAIN, NODATA, and also
SERVFAIL!  As no tracking of the security status of NXDOMAIN or
NODATA takes place, unaware applications can get false "secure"
results when RES_DNSRCH is enabled.

I don't know how the new "getdns" handles mixing of DNSSEC and
appending suffixes.

-- 
	Viktor.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 26 Feb 2014 21:23:48 -0500

> still the preferred method.

Is Micorosoft's method still to prefer the AD bit from the server, but
use IPSec between the clients and the servers?  That would seem to be
similar to your concern.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Feb 2014 14:16:28 +1100

> use IPSec between the clients and the servers?  That would seem to be

Blindly trusting AD from anything other than 127.0.0.1 / ::1 is
asking for trouble even if IPsec is being used.  The problem is
that you still need to trust the server and anything over the net
should be untrusted by default.

Adding a trusted key clause to resolv.conf would work e.g.

trusted-key start-date end-date . 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0="

Better still would be a RFC 5011 replacement that published START
and END dates along with a poll frequency for keys that should be
used as trust anchors along with the key material.  The START and
END dates would be updated periodically.  RFC 5011 is a grose hack.
We can do significantly better.

It the trusted-key clauses haven't been updated before the end date
the validator ignores the trusted key if there are no trusted-key
clauses clauses left you treat everything as insecure.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 26 Feb 2014 22:47:23 -0500

Hi,

> should be untrusted by default.

While I'm pleased as ever to know your personal preferences in this
matter, what I was asking was for information about what Microsoft is
actually shipping, and you seem not to have replied to that question
at all.  But I am not sure about your assertion about "should" above,
in at least some scenarios: I think that's exactly what we're
discussing, so you can't just say that one of the possibilities is the
right answer (that would be circular).

As I understood the deployment model implicit in what Microsoft
shipped (at least in the past), you were not "blindly" trusting the
server, but trusting the server that gave you your IP address, your
definition within the local SMB domain, and so on.  In other words,
_not_ trusting the server in question is functionally equivalent to
"doesn't work", so the threat model you have in the above is
completely misaligned with the deployment scenario that I think was
implicit in the product Microsoft shipped.  This is the reason for the
reliance on IPSec.  I believe that that product was entirely
consistent with the DNSSEC specifications (though it might be subject
to certain kinds of attacks if the attacker can take over the relevant
server).

I think that it is quite similar to the issue that Paul was raising
with his "virtual servers" scenario.  In some virtualized environment,
if you can't trust other systems that share the same physical hardware
as you, you're hosed anyway.  Additional protection is going to get
you nothing, and in that case as Paul was arguing it's better to have
the default provide more rather than less protection, even if that
"protection" is completely bogus under some other scenarios.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Feb 2014 15:17:53 +1100

> to certain kinds of attacks if the attacker can take over the relevant

Just because a server gave you IP addresses doesn't make it trust
worthy for DNSSEC.

Just because a server gave you credentials which allow you to
register is AD doesn't make it trust worthy for DNSSEC.

You can trust something for A but not B.  Now you can tell a machine
if you get A you should also trust it for B but one should be very
careful about it.

As for not working, if you don't trust the AD bit you are left with
the status quo, which isn't everything is not working.

I walk into a coffee shop.  I get a address.  I manage to get IPsec
running between the server and myself because both ends are configured
for opportunistic IPsec.  This does not mean I should trust the AD
bit.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 26 Feb 2014 23:23:35 -0500

On Thu, Feb 27, 2014 at 03:17:53PM +1100, Mark Andrews wrote:
> for opportunistic IPsec. 

What does that have to do with the deployment scenario I was asking
about in the Microsoft case, or the one I understood Paul to be asking
about?  Those cases are entirely to do with managed infrastructure,
and the question is, _if_ you have that kind of managed infrastructure
scenario and _if_ you accept that someone could subvert your
management model (but you don't care because if they can do that then
you're screwed anyway), then is there any value in the AD bit?  I
think the answer is, "Maybe," but we're never going to sort that out
if people persist with arguments about scenarios that have nothing to
do with the one under discussion.

Yes, you should not trust the AD bit from random parts of the Internet
or opportunistic IPsec or whatever.  But that's not the case we're
talking about, I think.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Feb 2014 15:29:33 +1100

> or opportunistic IPsec or whatever.  But that's not the case we're

s/coffee shop/BYOD and access to the AD DOMAIN resources/  

Should you still trust the nameservers to not corrupt DNS responses?
My answer to that is NO, by default.  If MS have the machines configured
to do that by default they are leaving the owner of the machine exposed.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Feb 2014 04:42:13 +0000

> for opportunistic IPsec.  This does not mean I should trust the AD

We are starting to veer off-track.  The original discussion is
about stub resolver policy choices, which I read to be broadly:

    - Sensible defaults absent any configuration to the contrary?

    - Where should non-default configuration be specified?

	* System configuration files?

	* Application?

	* Both?

    - What mechanisms are appropriate for stub-resolver users to
      express the application security requirements (AD only,
      AD + RRSIGs for in-application validation)?

It sounds like there is no strong objection to defaulting to no
trust.

Either there is a default white-list of trusted nameservers (127.1,
::1) or the administrator has to explicitly bless the full list in
/etc/resolv.conf.  I've not heard many clear preferences from others
in one direction or the other.  I personally, prefer a global "trust
the nameserver list" predicate over a white-list.

I am hoping that folks here agree that generally the person or
program that writes /etc/resolv.conf is in a better position to
set the default policy than most applications, and so the stub
resolver should takes its cues from /etc/resolv.conf first.

Naturally, given appropriate APIs, applications may be able to
override this.  Thus an application that sets the nameserver
list explicitly and then asks for the AD bit, should reasonably
expect that its chosen list will not be second-guessed by the
stub resolver library.

Beyond that are API design issues, for specifying the application's
desire for AD only, AD + RRSIGs.  It would be best in libresolv to
include support for res_ninit(), res_nsearch(), res_setservers()
and so on.  Support for "getdns" would be nice if deemed ready to
be a libresolv replacement or alternative.

So likely RedHat should proceed with extensions to resolv.conf to
express the trust status of the nameserver list, and improvements
to libresolv.  The default stub-resolver policy can reasonably be
non-trust of all nameservers (typically from DHCP).

Applications should be aware that mixing DNSSEC with RES_DNSRCH is
likely non-deterministic and unsafe.  While RES_DEFNAMES may be
less problematic, it still should be avoided.  Applications that
need to process the security status of particular RRsets, should
be particular about those RRsets and specify then precisely.  It
may be more prudent to use res_[n]query() rather than res_search().

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 27 Feb 2014 00:29:57 -0500 (EST)

> It sounds like there is no strong objection to defaulting to no

Well, Andrew and I voiced concerns about breaking current common
deployments.

> non-trust of all nameservers (typically from DHCP).

But it is so much better for all server installs to just install a
validating resolver, point resolv.conf to localhost, and use the DHCP
obtained DNS servers (or admin configured DNS servers) as forwarders.

Then all applications can trust the AD bit. That's a simply a reality
that's possible today. Even upgrading machines to this is not that hard.

The only really difficult case is the roaming device that has to deal
with captive portals. dnssec-trigger+unbound isn't cutting it for the
average user yet. While the glibc change would protect them, without
dnssec-trigger+unbound they are in a complete insecure dns mess anyway,
that I think a bogus AD flag is the least of the trouble.

That's why I'm not really in favour of adding legacy to glibc or
resolv.conf. Especially because there are also so few applications that
actually do anything with AD bits, plus we are still working on API and
DNSOP documents on how to improve/secure the DNS transport for talking
to remote servers.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Feb 2014 05:46:17 +0000

> that's possible today. Even upgrading machines to this is not that hard.

Yes, up-thread, this my ideal future world too.

> DNSOP documents on how to improve/secure the DNS transport for talking

But what to do when things are not ideal, perhaps because someone
disagrees with our ideal.  How do we let them assert that AD should
be trusted?

One could always trust AD, and leave up to the platform vendor and
system administrator to make it so.  Or one could default to not
trust AD unless resolv.conf says so, and the out-of-the-box
"experience" could be made to include a 127.1 nameserver and the
the right new predicate in /etc/resolv.conf, and glue to have DHCP
tweak forwarders (subject to relevant DHCP configuration) rather
than mess with resolv.conf (much better for reasons beyond DNSSEC
IMHO).

Then it is up to adventurous administrators to mess this up.  Some
will want to bless "remote" resolvers, that we might not want
to bless by default.

As to the question of whether always trusting AD when the recursive
resolvers are not "secure" is OK?  I don't know.  Depends what
applications do with that trust.

For Postfix with "smtp_tls_security_level = dane", the worst thing
that happens is misleading logs that claim more security than you
got.  Postfix also has a "dane-only" security level, for folks who
want stronger security to designated destinations.  In this case
trusting an "insecure" AD bit is not so good.

This said, the Postfix administrator is assumed to be involved in
administration of the platform it runs on (needs root for various
Postfix activities anyway).  So Postfix always trusts AD, and
documents that it is the administrators job to ensure that this is
justified.

Can you take the same view across all future applications?  Or is
more caution warranted?  I'm reluctant to claim that good enough
for Postfix, is good enough for everything...

-- 
	Viktor.

---

From: Petr Spacek <[email-masked]>
Date: Thu, 27 Feb 2014 14:15:16 +0100

>>> to libresolv.  The default stub-resolver policy can reasonably be
Note that we don't want to hack resolvers in Red Hat's software.

We really want to reach a consensus about this problem so we (Red Hat) can 
work upstream with stub-resolver developers to add support for the new 
behavior as designed here.

Please do not limit the discussion to glibc/libresolv/ldns/anything else. We 
are interested in resolver-behavior in general not in one particular 
implementation.

> Yes, up-thread, this my ideal future world too.

Sure, this is ideal, it is absolutely clear that (local) validating resolver 
is the best option (when possible).

Now we need to discuss 'a temporary solution' for the case where a validating 
resolver is not available for whatever reason.

Please let's concentrate on following situation:
- Crypto libraries like GnuTLS/OpenSSL/NSS have DANE support compiled and 
enabled by default out-of-the-box.
- GnuTLS/OpenSSL/NSS libraries use AD bit as received from stub-resolver.
- A random application (e.g. Firefox/Thunderbird/offlineimap) use DANE-enabled 
crypto library and have no clue about DNSSEC. (That is what we want, right? 
Just use it without modifying all crypto-enabled applications in the world!)
- The whole set is running on machine with plain stub-resolver without validator.

Result => It is completely insecure because attacker can use DANE for 
effective man-in-the-middle attack: The crypto library will trust to fake TLSA 
records because attacker send fake TLSA record with AD=1.

One opinion is 'use a new shiny API for DNS and do not hack existing resolver 
APIs' and the other option is to 'do validation yourself'. I'm afraid that 
this do not belong to category 'temporary solution'.

It can take too long to design API, then to develop libraries and then *to 
convince application developers to use this new API*.

I definitely agree that old resolver from BIND8 is "not the best" but we have 
to count with existing applications. It is easier to push small patches like
- res_init()
+ res_init_trusted()
It is *much much* harder to push patches rewriting code related to DNS to some 
completely new library. We want to add DANE support to existing applications 
not only to new ones.

The proposed approach with a new initialization call (*for example* 
res_init_trusted()) have two (desired) side-effects:
- It prevents an application relaying on AD bit from running on old system 
which does not guarantee trustworthiness of the AD bit. Otherwise we would 
have to invent some way how to check at run-time that special handling for AD 
bit is supported. (Think about cases where application was compiled on newer 
system and somebody tries to run it on older system etc.)
- It doesn't affect applications which do not care/do not use new 
initialization call.

For example current software like Postfix or OpenSSH client will 'just work' 
without any change. AD bit will be handled in special way only if the resolver 
library is initialized with the new call.

>> actually do anything with AD bits, plus we are still working on API and
The main idea is 'to make DNSSEC easy for application developers - today'.

It doesn't surprise me that very few applications use AD bit because nowadays 
it requires adding a new configuration option "resolver is un/trusted" to the 
application. It is not easy neither for programmer nor for administrator.

>> DNSOP documents on how to improve/secure the DNS transport for talking
I'm sorry, this also sounds like a long-term plan. We are looking for 
something workable today. The plan is to push DANE support as much as possible 
and as soon as possible - not to wait (potentially long time) for 
standardization and adoption of new APIs etc.

> applications do with that trust.
Please see the example with DANE-enabled crypto library above.

Have a nice day!

-- 
Petr^2 Spacek

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Feb 2014 16:40:14 +0000

On Thu, Feb 27, 2014 at 02:15:16PM +0100, Petr Spacek wrote:

> - Crypto libraries like GnuTLS/OpenSSL/NSS have DANE support
> compiled and enabled by default out-of-the-box.

The enabled by default part would be most likely.  It is not up to
the libraries to enable DANE support.  They don't know which
application protocol they're riding on top of, and how/whether DANE
applies to that application protocol.

For example, DANE for SMTP will be rather different from DANE for
various other app-layer protocols.  For example SMTP adds the MX
domains to the list of valid peer names to be found in an MX host
certificate.  SMTP does not support usages 0/1, ...

At this time 2 of the above libraries have no DANE support, and
GnuTLS DANE support is substantially incomplete (TLSA trust anchors
must be immediate issuers of the leaf certificate, and possibly
other limitations).

> - GnuTLS/OpenSSL/NSS libraries use AD bit as received from stub-resolver.

Which stub resolver API would you suggest they use?  Given the
multiplicity of interfaces, and the fact that applications may want
an asynchronous DNS interface, but none is as yet as entrenched as
libresolv, I would expect these toolkits to punt on TLSA record
resolution and leave this up to the application.  Especially because
policy about DNSSEC validation (AD bit vs. in-app trust anchors,
which nameservers, ...) don't belong in the underlying SSL library.

> - A random application (e.g. Firefox/Thunderbird/offlineimap) use
> DANE-enabled crypto library and have no clue about DNSSEC. (That is
> what we want, right? Just use it without modifying all
> crypto-enabled applications in the world!)

It is not so simple.  The application sets trust policy, including
whether DANE applies, which root CAs to trust, ...  Completely
transparent DANE assumes no application-specific DANE-related policy,
this seems unlikely.

For example, with SMTP, the SSL library won't be doing MX resolution,
but the security of the MX RRset determines whether DANE applies to
any of the MX hosts.

> Result => It is completely insecure because attacker can use DANE
> for effective man-in-the-middle attack: The crypto library will
> trust to fake TLSA records because attacker send fake TLSA record
> with AD=1.

Your model is too naive.  Crypto libraries should not and won't
set application protocol policy.  MTAs and so on, have lots of
knobs to enable DANE (in Postfix it is NOT on by default), and the
administrator is responsible for making sure the platform is suitably
configured before relying on DANE.

> One opinion is 'use a new shiny API for DNS and do not hack existing
> resolver APIs' and the other option is to 'do validation yourself'.
> I'm afraid that this do not belong to category 'temporary solution'.

Postfix does neither.  The administrator sets up a trusted recursor
and then enables DANE.  DANE support in interactive applications
operated on multi-user machines by non-administrators may need to
know whether the stub resolver is trustworthy.  This requires
a new predicate in resolv.conf (or whatever).

> It can take too long to design API, then to develop libraries and
> then *to convince application developers to use this new API*.

Yep, 5-10 year deployment horizons for brand new stuff.

> I definitely agree that old resolver from BIND8 is "not the best"
> but we have to count with existing applications. It is easier to
> push small patches like
> - res_init()
> + res_init_trusted()
> It is *much much* harder to push patches rewriting code related to
> DNS to some completely new library. We want to add DANE support to
> existing applications not only to new ones.

Yes, that's why I am recommending adoption of BSD libresolv, which
is a superset of the traditional libresolv, and offers more of what
is required to support DANE.  In particular, just having res_setservers()
and res_nsearch()/res_nquery would be major progress.

Beyond that, an application interface to ask whether the system
list of recursors is deemed secure would be helpful.  Work with
the various upstream library maintainers to make that happen.

> res_init_trusted()) have two (desired) side-effects:

This is I think a mistake.  Without resolver contexts as with
res_ninit(), this applies to all resolver clients in the same
address space, not just the caller.  Applications are usually not
in a good position to define trusted recursors.  Instead of saying
which resolvers are trusted, they want to ask whether the default
resolvers *are* trustworthy.

> - It prevents an application relying on AD bit from running on old
> system which does not guarantee trustworthiness of the AD bit.

There are no such legacy applications.  If you get ahead of DANE
adoption with suitable libraries, the applications can start directly
with the new plumbing.

> Otherwise we would have to invent some way how to check at run-time
> that special handling for AD bit is supported. (Think about cases
> where application was compiled on newer system and somebody tries to
> run it on older system etc.)

Run-time checks are required, and support for these will be missing
from older systems, so the code won't run there for lack of required
dependencies.

> For example current software like Postfix or OpenSSH client will
> 'just work' without any change. AD bit will be handled in special
> way only if the resolver library is initialized with the new call.

As the developer of the Postfix DANE interface, I'd rather Postfix
AD bit handling were subject to default system policy, and would
ask the administrator to set system policy accordingly.  Once APIs
for querying the stub-resolver behaviour (AD suppressed or trusted)
become widely available, Postfix will start using them to sanity
check its TLS policy settings (can't use DANE when stub resolver
suppresses AD support).

> It doesn't surprise me that very few applications use AD bit because
> nowadays it requires adding a new configuration option "resolver is
> un/trusted" to the application. It is not easy neither for
> programmer nor for administrator.

It is the administrator's job, but the platform can make that as
easy as possible.  I don't know which applications you have in mind
that are the ones doing DNSSEC and avoid using the AD bit.  Very
few applications use DANE, period.

The Exim folks are planning to implement DANE (as soon as one or
two of them are less cycle starved), and to trust the AD bit (that
code is partly there already per Tony's post).

Which DANE libraries are these apps using?  There is no DANE support
in OpenSSL or NSS yet, and GnuTLS is sufficiently incomplete, that
it is not ready for production use.

> I'm sorry, this also sounds like a long-term plan. We are looking
> for something workable today. The plan is to push DANE support as
> much as possible and as soon as possible - not to wait (potentially
> long time) for standardization and adoption of new APIs etc.

Today, DANE is essentially unusable.  Postfix DANE support took a
year of development and resulting in a new IETF draft plus proposed
changes that I hope will lead to DANEbis.  We're not there *today*.

> Please see the example with DANE-enabled crypto library above.

The example is largely naive.  It is not going to work that way
for quite some time.  DANE will be enabled by the code that performs
the application protocol (which may sit a few layers below the
business logic), but it will not any time soon be automatically
enabled by the transport security library due to insufficient
context.  For example, the application has to confirm that the
transport endpoint name is secure (e.g. after MX or SRV lookups)
and configure fallback behaviour when all TLSA records are unusable
(e.g. mandatory unauthenticated TLS, ...).

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Feb 2014 16:42:01 +0000

> The enabled by default part would be most likely.  It is not up to

Oops, s/most likely/most UNLIKELY/.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 27 Feb 2014 12:01:44 -0500 (EST)

> resolver is not available for whatever reason.

I don't agree with this premise, but those applications can be changed
to use (most error handling removed for clarity):

 	/* one time setup */
 	dnsctx = ub_ctx_create(); /* create unbound resolver context */
 	ub_ctx_hosts(dnsctx, "/etc/hosts") /* emulate POSIX */
 	ub_ctx_resolvconf(dnsctx, "/etc/resolv.conf") /* use nameservers from resolv.conf */
 	ub_ctx_add_ta(dnsctx, rootanchor); /* root key auto-updates via /var/lib/unbound/root.anchor */
 	ub_ctx_set_option(dnsctx, "dlv-anchor:", dlvanchor); /* activate DLV */

 	/* example query */
 	const int qtype = (af == AF_INET6) ? 28 : 1;
 	struct ub_result *result;
 	ub_resolve(dnsctx, qname, qtype, 1 /* CLASS IN */, &result);

 	if (result->bogus) {
                 log("ERROR: %s failed DNSSEC valdation!\n", result->qname);
                 ub_resolve_free(result);
                 [ do application is under attack defense ]
         }

         if (!result->havedata) {
                 if (result->secure) {   /* look, a real AD bit! */
 			[ do application stuff that trusts AD bit ]
 		} else {
 			[ do application stuff with no AD bit ]
 		}
 	}

This has the same effect as stripping out forged AD bits, except real AD
bits survive. It uses whatever nameservers the system has in
/etc/resolv.conf. It supports overrides in /etc/hosts. It does not
require glibc modification. It does not require various applications
read new keywords in resolv.conf or new config files. It has no race
conditions. It's a great band-aid until "tomorrow".

And possibly, the getdns API has an even simpler way of doing this.

Is this really too hard to do today for those old applications that need
to be fixed and for the new applications you will write tomorrow?

---

From: Paul Wouters <[email-masked]>
Date: Thu, 27 Feb 2014 12:05:45 -0500 (EST)

>        if (!result->havedata) {

No "!" there obviously, it was copied from more elaborate checks :)

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Feb 2014 18:16:43 +0000

On Thu, Feb 27, 2014 at 12:01:44PM -0500, Paul Wouters wrote:
> >Now we need to discuss 'a temporary solution' for the case where a
> >validating resolver is not available for whatever reason.
> 

Can *in principle* be changed, but in practice this is often
unlikely.  Postfix works well enough with libresolv, and supports
many older platforms.  Moving to libunbound, which is not as widely
deployed is not worth the benefit.

The base libresolv library should be enhanced to at least catch up
with BSD-like systems and offer res_ninit(), res_nsearch(), ...
Beyond that it would be good to be able to tell libresolv:

    * I want AD without RRSIG

and to ask libresolv:

    - Do you trust the AD bit from your nameservers?

with that and an appropriate administrator-settable predicate in
resolv.conf we're largely set.  Applications which call res_setservers()
should automatically receive AD=1.

-- 
	Viktor.

---

From: Tony Finch <[email-masked]>
Date: Thu, 27 Feb 2014 18:37:22 +0000

> trusted-key start-date end-date . 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZx…

ldns uses the syntax

	anchor /path/to/file

and you can use unbound-anchor to keep the file up-to-date.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire: Southeasterly 7 to severe gale 9, decreasing 5 or 6.
Rough or very rough. Rain then showers. Poor becoming good.

---

From: Petr Spacek <[email-masked]>
Date: Thu, 27 Feb 2014 19:20:15 +0100

>      dnsctx = ub_ctx_create(); /* create unbound resolver context */

Please correct me if I'm wrong but I'm afraid that this snippet effectively 
>      ub_ctx_set_option(dnsctx, "dlv-anchor:", dlvanchor); /* activate DLV */
How can I install my own trust anchors? (E.g. I have internal zones and I want 
to use DNSSEC for them...) How can I disable DLV on system-wide level? All 
this should be system-wide configuration otherwise it will create problems for 
tightly controlled environments.

> And possibly, the getdns API has an even simpler way of doing this.
I agree that new DNS API is a great idea, I have said that many times already.

> to be fixed and for the new applications you will write tomorrow?
Will you patch every application doing TLS to link with libunbound? (Upstream 
developers are always happy to accept patches introducing new dependencies.)

Are you going to convince OpenStack people (accepting only pure Python code 
and nothing else) to use this?

Please see the other branch of this thread, I will reply there about crypto 
libraries.

-- 
Petr^2 Spacek

---

From: Petr Spacek <[email-masked]>
Date: Thu, 27 Feb 2014 21:04:13 +0100

On 27.2.2014 17:42, Viktor Dukhovni wrote:
> On 27.2.2014 17:40, Viktor Dukhovni wrote:
[...]

Feel free to skip handwaving about crypto libraries and jump straight to the 
matter - DNS stub-resolvers.

/Disclaimer: Please read following text about crypto libraries as a long-term 
vision. I'm adding it here just to add some context information. I'm aware 
that it will take long and that is not *that* simple./

>> which nameservers, ...) don't belong in the underlying SSL library.
I have talked with NSS developers at Red Hat's Developer Conference this year 
(devconf.cz) and their (personal and not-that-thorough) opinion was that it 
seems feasible to do DANE for pure TLS directly in crypto library.

If everything you need is to open a TLS connection to a server with given name 
then *in theory* the crypto library can do all the work for you.

Of course, there are applications with special requirements but easy cases 
could be (we hope) handled in crypto library and special case over appropriate 
APIs.

The discussion ended with statement that we need to solve API for resolvers 
first and then we can open discussion about DANE in NSS again.
    <<< --- We are here :-)

>> transparent DANE assumes no application-specific DANE-related policy,

Yes, that is a problem (in a little bit different area). Generally, we want to 
move crypto/security policies from applications to system level. Current 
situation is an administrative nightmare.

The 'Vision' (highly naive, *please* do not comment on API itself but on the 
idea) is to convert (as much as possible) applications to APIs like:

open_tls_connection('hostname', port, &conn);
send_enc_data(conn &buff, len);
recv_enc_data(conn, &buff, len);
close_tls_connection(&conn);

... and separate applications from DNS/connection handling/crypto stuff. Think 
about DNSSEC + happy eyeballs + TLS. That is a lot for an application to do 
for mere connection establishment!

That will allow us to control security policy on system-wide level where it 
belongs. We already do work in this field and direction.

This is long-term goal and adding application-controlled policies for DANE 
goes in opposite direction. That is the reason why we are trying to move 
'policy logic' to system level/library level and do not pollute applications 
with policy processing. (We have to at least *try* that.)

>> configured before relying on DANE.
That is exactly the point. We don't want to configure everything again and 
again per-application, we want system-wide configuration.

Of course, it can't work today and there always be some special cases. MTAs 
can be one of them. You are expert in this area and I trust you.

The intent is to avoid adding more and more application specific knobs because 
it will be hard to get rid of them in future. (There are exceptions - as always.)

>> a new predicate in resolv.conf (or whatever).
I 100 % agree.

>> and res_nsearch()/res_nquery would be major progress.
Again, we are not interested in a single library but in a general approach. 
Please consider that vanilla Fedora distro contains > 40 000 packages. I can 
name 5 different DNS libraries I use daily *only from top of my head*.

We want to open DNSSEC/DANE potential for all of them, not only some small subset.

Of course, this idea (nameserver whitelisting/AD bit masking) has to be widely 
adopted in rest of the ecosystem otherwise we can give it up right now. We 
don't want and can't go against the whole world.

>> the various upstream library maintainers to make that happen.
I'm glad that we agree on that. Do you have some specific proposal in your mind?
You have proposed new option in /etc/resolv.conf, something like 
resolvers_trusted = no/yes, right?

What behavior is 'the best' in your opinion? Would it be okay to always set AD 
bit to 0 if option "resolvers_trusted" is set to "no"?

Are you okay with default "no"? (If the new option is not present.)

>> resolvers *are* trustworthy.
I agree. What do you think about AD bit masking configured system-wide? Please 
keep in mind that this needs to be universal behavior implement-able even in 
old glibc resolver and any other DNS library.

>> adoption with suitable libraries, the applications can start directly
I personally agree but please read concerns expressed by glibc maintainer below.

>> from older systems, so the code won't run there for lack of required
I'm personally okay with that.

>> check its TLS policy settings (can't use DANE when stub resolver
I 100 % agree with your point of view.

The problem is that our glibc maintainer explicitly refused to change default 
behavior (i.e. mask AD bit until admin white-lists given resolver in 
/etc/resolv.conf) because it could break some (potentially) existing 
applications. That is a reason why we invented "init_trusted()" concept.

Could you give us some detailed thoughts about compatibility?

I guess that we will have the same discussion about compatibility again and 
again with many upstream developers from many DNS libraries so any detailed 
analysis will be handy.

>> changes that I hope will lead to DANEbis.  We're not there *today*.
Okay, let's find a way how we can move things forward on client side! :-)

Thank you very much for your time.

-- 
Petr^2 Spacek

---

From: Petr Spacek <[email-masked]>
Date: Thu, 27 Feb 2014 21:44:01 +0100

I'm adding quote from our glibc maintainer:

 >>>> Carlos O'Donell <[email-masked]> wrote:
>>>>> Consider a RHEL7 or RHEL6 system using the present meaning of
>>>>> `nameserver' in /etc/resolv.conf, on a secure network with a trusted
>>>>> recursive resolver using DNSSEC for some given domains. In this
>>>>> configuration any application using the AD bit works as expected.
>>>>> The system administrators ensured there was trust between the recursive
>>>>> resolver and the client stub resolver. This is how a user might configure
>>>>> their corporate network, and even better they might also use 802.1x
>>>>> with no rogue or untrusted systems on their network.
>>>>>
>>>>> If we release a z-stream or y-stream glibc that inverts the definition
>>>>> of `nameserver' from trusted to untrusted (doesn't use EDNS0+DO for
>>>>> a query, and clears the AD bit) then applications in such a configuration
>>>>> as described above that rely on the AD bit forwarding may cease to
>>>>> function correctly.
>>>>>
>>>>> That is why I do not want to change the existing meaning of `nameserver'
>>>>> and why we should not change any of the existing meanings of entries in
>>>>> /etc/resolv.conf. Thus for compatibility I suggest adding a new option
>>>>> `untrusted' for use by such applications as NetworkManager to put
>>>>> untrusted DNS server (acquired from untrusted DHCP results) into.
>>>>>
>>>>> Let me be clear though, if I didn't care about breaking customer
>>>>> configurations, I'd make this change, but I think we would be doing
>>>>> a disservice to our users by breaking valid existing DNSSEC uses.

-- 
Petr^2 Spacek

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Feb 2014 21:26:14 +0000

On Thu, Feb 27, 2014 at 09:04:13PM +0100, Petr Spacek wrote:

> Of course, there are applications with special requirements but easy
> cases could be (we hope) handled in crypto library and special case
> over appropriate APIs.
> 
> The discussion ended with statement that we need to solve API for
> resolvers first and then we can open discussion about DANE in NSS
> again.
>
>    <<< --- We are here :-)

Almost, because some of the DANE requirements are not set in stone.
For example, interaction with CNAME records is not yet a done deal.
Likewise digest agility, support for multiple peer names, semantics
of CU=3, ...

Early implementations are raising issues that clarify or extend
the standard, and so even if the resolver API were a solved problem,
it would be a bit early to bake a complete DANE implementation,
including all the policy issues around TLSA records, into a TLS
toolkit.

It is a good time to be thinking about how to validate certificate
chains via a given set of TLSA records and get the basics right
(subtle enough in itself, that almost every implementation I've
seen has serious flaws).

So progress can be made by implementing code in such toolkits:

    - To validate a remote server's certificate chain against
      a set of TLSA records provided by the application

    - To integrate this with name checks (off for CU=3) that
      support multiple application-provided names.

    - To think about the semantics of "IN TLSA 2 1 0" and whether
      such bare keys in DNS are usable without a corresponding
      chain element in the server TLS "certificate message".

    - To think about how to support digest agility

    - To provide an API for applications that want to do their
      own DNS lookups, and pass them to the librarary, rather
      than asking the TLS library to perform DNS lookups.

> This is long-term goal and adding application-controlled policies
> for DANE goes in opposite direction. That is the reason why we are
> trying to move 'policy logic' to system level/library level and do
> not pollute applications with policy processing. (We have to at
> least *try* that.)

For the simplest applications that have a single secure hostname,
and want to use some shiny new simplified API, which promises DANE
as a default enabled connection security mechanism, sure we can
assume there's a role for that.

Complications arise quickly if needs of more complex applications
are not anticipated and one need to be careful of complex dependency
chains if the crypto library depends on DNSSEC libraries which in
turn depend on crypto libraries.

> That is exactly the point. We don't want to configure everything
> again and again per-application, we want system-wide configuration.

Yes.

> The intent is to avoid adding more and more application specific
> knobs because it will be hard to get rid of them in future. (There
> are exceptions - as always.)

I vote for a stub resolver whose configuration combines a list of
recursive resolvers with a trust predicate that specifies whether
the AD bit should be passed to stub resolver applications.

I further vote for a way to query this predicate and to set the
recursor list, all via an extended libresolv.

> Again, we are not interested in a single library but in a general
> approach. Please consider that vanilla Fedora distro contains > 40
> 000 packages. I can name 5 different DNS libraries I use daily *only
> from top of my head*.

Then add the requisite functionality to each of the relevant
libraries.  But for your simple application API you only need to
care about the DNS libraries used by:

	OpenSSL (if any)
	GnuTLS  (if any)
	NSS	(if any)

you can help direct those toolkits at the preferred DNS library,
at which point behaviour of other DNS libraries is less important.

> We want to open DNSSEC/DANE potential for all of them, not only

I would recommend a bit of focus at the outset.

> Of course, this idea (nameserver whitelisting/AD bit masking) has to
> be widely adopted in rest of the ecosystem otherwise we can give it
> up right now. We don't want and can't go against the whole world.

I am still not sold on "whitelisting", as opposed to "blessing" a
configuration as a whole, but this is not critical.  Yes work with
library designers to come to agreement on the approach.

> I'm glad that we agree on that. Do you have some specific proposal
> in your mind?  You have proposed new option in /etc/resolv.conf,
> something like
>

Something like that, without suggesting any particular name.

> What behavior is 'the best' in your opinion? Would it be okay to
> always set AD bit to 0 if option "resolvers_trusted" is set to "no"?

That would be fine.  Fail closed.  If some DHCP client unaware of
the new predicate generates a resolv.conf file, it should I think
be considered insecure.

> Are you okay with default "no"? (If the new option is not present.)

Yes.  I am of course not the entirety of this group (even if lately
I am responsible for ~50% of the traffic).  So perhaps this view
is not widely held.

> I agree. What do you think about AD bit masking configured
> system-wide? Please keep in mind that this needs to be universal
> behavior implement-able even in old glibc resolver and any other DNS
> library.

Fine by me, I prefer it in fact, provided the administrator can
unmask it, and an application can find out whether the masking is
taking place.

> The problem is that our glibc maintainer explicitly refused to
> change default behavior (i.e. mask AD bit until admin white-lists
> given resolver in /etc/resolv.conf) because it could break some
> (potentially) existing applications. That is a reason why we
> invented "init_trusted()" concept.

I think he's wrong.  Precisely because applications might be using
the AD bit, it *should* be masked when unsafe.  Polluting the library
with useless initializers (and still no resolver context as with
res_ninit(), ...) would be lame.

> Could you give us some detailed thoughts about compatibility?

Go ahead, PLEASE, break Postfix DANE support on systems using
insecure upstead resolvers on which the administrator does not
arrange for the right predicate in /etc/resolv.conf.

I want the AD bit to be more than blind faith.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Feb 2014 21:38:32 +0000

>>as described above that rely on the AD bit forwarding may cease to

A feature IMHO.  Document the change, and tell administrators how
to mark the resolver list trusted.  Enhance NetworkManager to be
able to write trusted resolv.conf files when the DNS server list
comes from a secure source.

>>untrusted DNS server (acquired from untrusted DHCP results) into.

This fails open.  Given the dearth of DNSSEC applications that rely
on the AD bit, this is I think the right time to get the right
semantics.

No changes are required in end-applications, just system configuration
management, this is an easy problem that should be addressed.

Marking /etc/resolv.conf explicitly untrusted, in every case where
it is not, is I think too fragile.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Feb 2014 21:56:45 +0000

> conditions. It's a great band-aid until "tomorrow".

Oddly enough, unrelated to this thread, someone asked me today
whether there exist stub resolver libraries that can be configured
to trust AD=1, but *otherwise* perform local validation when AD=0.

Perhaps the local recursor is non-validating, or Petr's idea is
implemented and the AD bit is suppressed.  Either way, the application
can recover at the cost of performing internal verification, but only
when "necessary".

Anyone know of a library that can support this mode of operation?

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Feb 2014 23:09:22 +0000

On Thu, Feb 27, 2014 at 05:49:54PM -0500, Paul Wouters wrote:

> - Make unbound part of every install
>
> - Modify Anaconda/kickstart to take user's static DNS input and store
>   it somewhere (e.g. /etc/sysconfig/unbound or something)
>   and put 127.0.0.1 in resolv.conf
>
> - Modify unbound systemd service to run unbound-control forward_add
>   . <DNS info from sysconfig> in ExecStartPost=
>
> - Modify NM to run unbound-control forward_add . <DNS info from dhcp>
>   instead of modifying resolv.conf
> 
> no crypto library and no glibc modifications needed.

I agree, but one of the more vocal Postfix users does not.  Perhaps
we can ignore him as an unrepresentative zealot.  Objectively, I
see no reason to say no to a local validating cache.

If RedHat can standardize on a local validating cache on every
machine, that *is* better than hacking the AD bit, provided you
can ignore the zealots who insist that with a few LAN-local caches,
adding local caches on each machine is somehow bad.

My point that with virtual machines context switching to a different
VM is likely much more expensive than context switching to a local
process did not make much of an impression.

So *if* there is a local resolver and it is the only one used,
great!  No need to disable the AD bit.  If there is not, perhaps
"failing safe" is sensible.

It may be enough to design systems that default to local resolvers,
and users who change that are free to shoot themselves in both feet.

-- 
	Viktor.

---

From: Petr Spacek <[email-masked]>
Date: Fri, 28 Feb 2014 13:12:36 +0100

Hello,

please comment on the following proposal. Paul and Viktor are most active in 
this discussion but we would like to hear opinions from other experts!

Let's agree on the very basic principle, please do not recommend particular 
libraries etc.

The Goal
========
On 28.2.2014 00:09, Viktor Dukhovni wrote:
 >> On 27.2.2014 22:26, Viktor Dukhovni wrote:
(This means AD bit as seen by applications in responses from generic DNS API.)

Long-term solution
==================
Paul Wouters pushes hard for validating recursor on each host. Viktor and me 
> "failing safe" is sensible.

However, we want to find some intermediate solution deployable today.
> and users who change that are free to shoot themselves in both feet.

Proposal for short-term solution - please comment
=================================================
All names are completely "random". Please propose better names and/or semantics.

1) Add a new boolean to /etc/resolv.conf:
options resolvers-trusted
- If present, this option states that "admin ensured that recursor is 
trustworthy and the communication link between recursor and stub-resolver is 
secure".
- If present, the AD bit will be passed from recursors to applications as-is.
- If not present, the AD bit sent to a applications will be always 0.
- E.g. the option will be present on a system with locally running Unbound.
- E.g. the option *will not* be present on thin client, compute node in data 
centre, a random laptop installed today with default configuration etc.

Objections:
- There is a chance that dhcp client copies "options" from old resolv.conf to 
new one. In that case simplest variant "options resolvers-trusted" is insecure 
if one configured e.g. local trusted recursor and DHCP client was started 
after that.
- Many applications mess with resolv.conf so the new boolean should be 
somewhere else. E.g. /etc/resolv.trusted.
- Because of the first objection, the file /etc/resolv.trusted should contain 
explicit whitelist with IP addresses of trusted recursors. That lowers the 
probability that admin sets option "resolvers-trusted" to /etc/resolv.trusted 
but some application (like DHCP client) will change name servers in 
/etc/resolv.conf.

2) Add a function call for run-time check (for library users):
boolean dns_resolvers_trusted(resolver);
- TRUE if admin declared resolvers as trusted. AD bit is unchanged.
- FALSE otherwise. AD bit is always set to 0. Applications can detect that AD 
bit masking is enabled.
- If the function is not defined then DNS library doesn't support AD bit 
masking as described here.

Naturally, this can be replaced by any other mechanism for run-time checks if 
a library in question has such mechanism already.

3) Usage from applications:
- Call run-time check:
/* WARNING! This call can't be skipped: It ensures that your DNS the library 
supports the new behavior. */
dns_trusted = dns_resolvers_trusted(resolver);
if (dns_trusted)
     Enable code depending on DNSSEC
else
     Fallback

- Decide if you want to use the data from DNS or not:
dns_query(resolver, query, answer);
if (answer->ad_bit)
     Use data from DNS (answer->data)
else
     Fallback

Please add what I have missed, what is wrong etc.

Thank you very much for your time!

-- 
Petr^2 Spacek

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Feb 2014 14:05:00 -0500

> be ignored or is always hardcoded with nameserver 127.0.0.1

My problem isn't that the AD is insecure, but that it isn't very useful.
Going back 10 years to the various DNSSEC workshops, one of the things that I
wanted was more information about why there was a validation failure.

For instance, if I have previously contacted example.com, and I have
it's A/AAAA or more interestingly, the DANE borne public key for the service
I want to reach cached, or leap-of-faith'ed, I don't care as much if the
DNSSEC fails to validate because a signature expired.

If it fails to validate because the data is correct, I expect the bad data to
be discarded, and for it to try again.  At some point (<<5s) the application
needs to get some kind of report that name is not presently available.
(Happy eyeballs, or some other mechanism might want to try something else)

This is doubly true if I have contact with the user who
can I can:
    a) advise of the specific reason for the failure
       (which up to now, would be followed by facepalm and one of geeks
       goes to fix the problem....)

    b) find out what they want to do now.

SERVFAIL / "Host now found" is simply not acceptable information.

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.

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

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

---

From: Simo Sorce <[email-masked]>
Date: Fri, 28 Feb 2014 14:56:10 -0500

> connections.   Java had the right idea, but the implementation and error

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.

Simo.

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

---

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

Michael Richardson <[email-masked]> wrote:
    > If it fails to validate because the data is correct, I expect the bad

should read;
    > If it fails to validate because the data is corrupt, I expect the bad

-- 
Michael Richardson
-on the road-