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

"Jim Schaad" <ietf@augustcellars.com> Mon, 23 February 2015 03:35 UTC

Return-Path: <ietf@augustcellars.com>
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 E75011A0154 for <dane@ietfa.amsl.com>; Sun, 22 Feb 2015 19:35:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 CxAEALmMCPRA for <dane@ietfa.amsl.com>; Sun, 22 Feb 2015 19:35:45 -0800 (PST)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B23E1A0151 for <DANE@ietf.org>; Sun, 22 Feb 2015 19:35:45 -0800 (PST)
Received: from Philemon (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 01BB138F00; Sun, 22 Feb 2015 19:35:44 -0800 (PST)
From: Jim Schaad <ietf@augustcellars.com>
To: draft-ietf-dane-openpgpkey@tools.ietf.org
References: <CAHw9_iJPuG23Aok7V_wcAMirua_DPDLHy01tnd+DaUqEeK3NZA@mail.gmail.com>
In-Reply-To: <CAHw9_iJPuG23Aok7V_wcAMirua_DPDLHy01tnd+DaUqEeK3NZA@mail.gmail.com>
Date: Sun, 22 Feb 2015 19:34:53 -0800
Message-ID: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGZrEAk8fO9l7kPFCFwPwE9DoqVVp1q1ALw
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/hfPmm_Y8TsZZkGmqwlPPBfKl26I>
Cc: "'<dane@ietf.org>'" <DANE@ietf.org>
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
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: Mon, 23 Feb 2015 03:35:47 -0000

Having reviewed the document, I would suggest the following issues be
addressed:

1.  The introduction nicely restricts the problem to dealing with encryption
and not signatures.  I think it would be wise to have a brief paragraph
about why the signature side is not dealt with.  I think it would be as
simple as saying that the document is not doing anything about changing the
trust model, so the fact that one could obtain a signature key ring for a
sender does not give any additional security on the trust of the signature.
This might prevent a future update to the document that extended to deal
with signatures.

2.  The abstract should probably make a statement that the trust model is
not changing for keys, and this is targeted towards doing optimistic
encryption rather than secure encryption.

3.  Minor point - if you lost the public key you probably lost the
pre-signed key revocation.  Not sure that it is worth updating the paragraph
to reflect that this value can be lost as well.  s/pre-sign a key
revocation/pre-sign and retained a key revocation/

4.  In section 3, I strongly urge that the problem of case folding of user
names be acknowledged.   I don't insist that the problem be solved.  (I
believe that it is not really solvable.)  However I strongly field that the
existence of the problem needs to be stated along with the fact that there
is no intention to solve it.   The problem statement can also easily state
that this is a problem ONLY for US ASCII systems and not for UNICODE systems
as these are less likely to allow for case folding in the first place.
(Does not need to be in section 3, but that seems to be the logical place to
put it.)

5.  Did I miss someplace  a statement that this record type MUST be used
only if DNSSEC is present?  Or are you willing to use it w/o DNSSEC for
opportunistic encryption?  If so then that should probably be stated.

Jim