IETF Logo Mail Archive

Re: [dane] An AD bit discussion

Ondřej Surý <ondrej.sury@nic.cz> Wed, 26 February 2014 15:39 UTC

Return-Path: <ondrej.sury@nic.cz>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F511A0693 for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 07:39:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.001
X-Spam-Level: *
X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6AwziP_H3sq for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 07:39:39 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 853991A00C0 for <dane@ietf.org>; Wed, 26 Feb 2014 07:39:37 -0800 (PST)
Received: from labs.ondrej.sury.nb.wifi.4.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id D740913F9D7; Wed, 26 Feb 2014 16:39:35 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1393429175; bh=vVZV/rQyEZsgq+PhO9Ogw9diAHqlI5RldgE4UN+G24k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=IZohn5AowG/4zDfz7QHRHc5sS/Dk3WsTkYjlYDWW7oi0aZPsU+QqNdoaBhfWPst7c GnaHQyHs4KA43vk5flwFuTj5eh90orgfPNzKHZTY3kQU3sBA7kEEhMLCjalDTtrHyB fZFxVIjNpIumsSeKvQX8nO/5WMImF/0kuF97gEjY=
Content-Type: multipart/signed; boundary="Apple-Mail=_A4F6ABBA-B980-4FB8-A65F-12FAA112B3E6"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ondřej Surý <ondrej.sury@nic.cz>
In-Reply-To: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca>
Date: Wed, 26 Feb 2014 16:39:35 +0100
Message-Id: <DB72D0D1-C615-4924-8695-D3B6C118EBC9@nic.cz>
References: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ki5zDgWDePEXhafAdIseyVvN_8U
Cc: dane WG list <dane@ietf.org>
Subject: Re: [dane] An AD bit discussion
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2014 15:39:41 -0000

Hi Paul,

On 26. 2. 2014, at 15:12, Paul Wouters <paul@nohats.ca> wrote:

> 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

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

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

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

> B) do nothing
> 
> 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:ondrej.sury@nic.cz    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

v2.23.0 | Report a Bug | By Email