Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review.

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 26 February 2015 00:31 UTC

Return-Path: <ietf-dane@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 236C21A924E for <dane@ietfa.amsl.com>; Wed, 25 Feb 2015 16:31:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 zA07XXDZh6nX for <dane@ietfa.amsl.com>; Wed, 25 Feb 2015 16:31:40 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C4E1A923E for <dane@ietf.org>; Wed, 25 Feb 2015 16:31:40 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 76ED4282F4D; Thu, 26 Feb 2015 00:31:39 +0000 (UTC)
Date: Thu, 26 Feb 2015 00:31:39 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20150226003139.GK1260@mournblade.imrryr.org>
References: <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> <CAHw9_iJ167aCbpW=Fni0h_vsWLcWQVLC1P7vkr6X0cmAV9zG=g@mail.gmail.com> <20150223225630.GO1260@mournblade.imrryr.org> <CAHw9_iKNwGBOqdLm04Lqox6ai5tzK1Q-WfkxY=Qvtx+uOG1Qpw@mail.gmail.com> <alpine.LFD.2.10.1502251246430.3004@bofh.nohats.ca> <20150225181322.GU1260@mournblade.imrryr.org> <alpine.LFD.2.10.1502251356430.6550@bofh.nohats.ca> <20150225191500.GZ1260@mournblade.imrryr.org> <CAH1iCipV1Mi03d-AGDHsZv5Lm=OT6ta3m7vBU5uJWsXhN89TzA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAH1iCipV1Mi03d-AGDHsZv5Lm=OT6ta3m7vBU5uJWsXhN89TzA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/sEzPu7IDLJ4rZfUWpsSaNy8LXk4>
Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review.
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: Thu, 26 Feb 2015 00:31:42 -0000

On Wed, Feb 25, 2015 at 01:41:19PM -0800, Brian Dickson wrote:

> There are implications to DNS resolution & caching, if you consider stub,
> recursive, and authoritative actors. It may be the case that multiple
> queries need to be done by the stub, regardless of approach. However, if
> policy discovery involves looking up a single common record per DNS zone
> (e.g. rhs of email address), then this is cacheable and reduces both the
> size of the publishing zone, as well as the number of queries by the
> recursive to the authoritative, per client query.

If by RHS of email address you mean the domain part (the local part
being the LHS), then indeed designs are possible where the case
folding rules are published via a single per-domain key.

However, this does not substantively impact the scalability of DNS
caching, by which I mean that the number of cache entries is
increased by a factor of two rather than some much larger factor.

> _casefolding RRTYPE RDATA as a way of allowing the zone owner to publish
> all the case-folding rules for the zone, and require the client to use this
> to discover the canonical (published) owner name for a given email address.

This complicates the client code, but avoids the factor of two in
the number of cached records.  We would still however need O(10e9)
records in zones like gmail.com.  The only way to eliminate that
problem is to do per-user lookups via an online query service (whose
location is published via DNS) rather than finding users directly
in DNS.

-- 
	Viktor.