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

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 25 February 2015 18:13 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 E17821A1A39 for <dane@ietfa.amsl.com>; Wed, 25 Feb 2015 10:13:25 -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 e7Cl-BKufpMG for <dane@ietfa.amsl.com>; Wed, 25 Feb 2015 10:13:24 -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 B041B1A1A3C for <dane@ietf.org>; Wed, 25 Feb 2015 10:13:23 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8137C282FCC; Wed, 25 Feb 2015 18:13:22 +0000 (UTC)
Date: Wed, 25 Feb 2015 18:13:22 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20150225181322.GU1260@mournblade.imrryr.org>
References: <CAHw9_iJPuG23Aok7V_wcAMirua_DPDLHy01tnd+DaUqEeK3NZA@mail.gmail.com> <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.10.1502251246430.3004@bofh.nohats.ca>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/kAjMazQySzfH38meFqNITCHlIK8>
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: Wed, 25 Feb 2015 18:13:26 -0000

On Wed, Feb 25, 2015 at 12:50:59PM -0500, Paul Wouters wrote:

> >Viktor, would you mind writing up the proposal again (in a new thread)
> >and we'll call consensus on this approach?
> 
> I think I explained this before, but I don't like anything that requires
> putting more than one entry into the DNS.  The logic should be in the
> client behaviour. the SMTP protocol allows "Frank" to be a different
> email from "frank" so we cannot define these two to be the same at the
> protocol level. We can only provide guidance the clients trying to
> consume the new RRtypes.

Note that precisely because the client is not free to define "Frank"
to be the same as "frank", and because DNS does not have anything
remotely resembling server-defined case matching rules, we either
give up on supporting case-less matching even when case insensitivity
is known to the server, or multiple lookup keys need to be published,
in such a way that "frank" is explicitly lower-case-of(Frank) rather
than just some lower-case address.

> So I'm okay with defining client behaviour to try sha224(Frank) and then
> sha224(frank) and have a note in the security section explaining that
> in theory (even if not in practise) these two could be different people.

Once the client is making two queries, why accept collisions?  Are
we (after all these years) finally defining RFC-822/2822/5322 local
parts to be case-insensitive?  (Price of progress and all that?)

Is a CNAME per-user really a major burden?

-- 
	Viktor.