IETF Logo Mail Archive

Re: [dane] New Version Notification for draft-osterweil-dane-ent-email-reqs-01.txt

Jakob Schlyter <jakob@kirei.se> Wed, 26 November 2014 18:30 UTC

Return-Path: <jakob@kirei.se>
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 783071A1B34 for <dane@ietfa.amsl.com>; Wed, 26 Nov 2014 10:30:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.661
X-Spam-Level:
X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 kBSnhTFTnkdT for <dane@ietfa.amsl.com>; Wed, 26 Nov 2014 10:30:27 -0800 (PST)
Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC091A1B2F for <dane@ietf.org>; Wed, 26 Nov 2014 10:30:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer; bh=LclbLX1yFBIlOv3+AupD8SNoiT/DysnYw4NYCxLWYe0=; b=mYfNTmMD4Z5N19qzrS1HrLjsVK9QHy1kE573OThOd8l4o+3uXwdp/nLpr/IucjOfWTh+griGr4FO4 r5fBgiGgkd2NkLXPxdqLi8OYosp2kngiLDlTgnGUVkeA3QTkGYmlbyzqMNV63TXV2NUMFXfF588loT 3R5P1FrxSKC2xqiQ=
Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for <dane@ietf.org>; Wed, 26 Nov 2014 19:30:05 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Jakob Schlyter <jakob@kirei.se>
In-Reply-To: <20141126010456.GB25114@mournblade.imrryr.org>
Date: Wed, 26 Nov 2014 19:30:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F00D8341-CD1B-403A-A743-1BAC983CB03E@kirei.se>
References: <20141126000329.7972.72323.idtracker@ietfa.amsl.com> <B81C95E2-0F2B-4E5B-B4C5-7CD25BEE6F0B@nist.gov> <20141126010456.GB25114@mournblade.imrryr.org>
To: dane@ietf.org
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/0Df3xPVx95ruKdY-z-Xg25_RnFc
Subject: Re: [dane] New Version Notification for draft-osterweil-dane-ent-email-reqs-01.txt
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 Nov 2014 18:30:29 -0000

On 26 nov 2014, at 02:04, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:

> * REQ-2 seems to suggest DNAME in a context where I would generally
>  expect CNAME (linking one leaf record to another).  DNAMEs would
>  far more likely be used when all users have addresses in each of
>  two or more equivalent domains.

Why? The following example makes sense for aliasing:

  _smimecert.example.com. IN DNAME _smimecert.example.net. 


> * REQ-7 is I think too concise.  What is it about?


I believe something like this:

_smimecert.example.com. IN DNAME _smimecert.example.com.provider.net.


> * REQ-8 feels wrong.  It is turtles all the way down,
>  the merging enterprise's applications may be using some other
>  protocol.  The protocol cannot encompass all competing protocols.
>  Applications may need to support multiple protocols, and perhaps
>  a meta protocol (obligatory xkcd reference anyone) could be used
>  to signal which one to apply to which user.  However it may simply
>  be better for a new protocol to keep things simple and aim to
>  displace rather than entrench legacy options.

I agree. For me, this feels like optimizing for the publish side (of which there are few) instead of optimizing for the client (of which there any many). Also, this adds complexity. I can see that it would be easier for an enterprise to say *._smimecert.example.com. IN SMIMEA go-see-ldap, but if one can put one SMIMEA RR in the DNS, one can easily loop through that LDAP thing and publish all the certs. I'd like to optimize for simplicity in this case.



	jakob

v2.23.0 | Report a Bug | By Email