Re: [dane] An AD bit discussion

Viktor Dukhovni <viktor1dane@dukhovni.org> Wed, 26 February 2014 15:57 UTC

Return-Path: <viktor1dane@dukhovni.org>
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 7BAA71A0676 for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 07:57:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham
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 FgBODqZdciZX for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 07:57:55 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE081A066E for <dane@ietf.org>; Wed, 26 Feb 2014 07:57:54 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 276072AAD0C; Wed, 26 Feb 2014 15:57:52 +0000 (UTC)
Date: Wed, 26 Feb 2014 15:57:52 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140226155752.GT21390@mournblade.imrryr.org>
References: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/S-Ja1t4Fb_R_wr_RrCvAeYS5PcM
Subject: Re: [dane] An AD bit discussion
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
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:57:59 -0000

On Wed, Feb 26, 2014 at 09:12:20AM -0500, Paul Wouters wrote:

> 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

This is also my ideal world of tomorrow.

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

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.