Re: [openpgp] Fwd: New Version Notification for draft-wouters-dane-openpgp-00.txt (fwd)

Paul Wouters <paul@nohats.ca> Tue, 16 July 2013 02:02 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0AD11E819A for <openpgp@ietfa.amsl.com>; Mon, 15 Jul 2013 19:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.704
X-Spam-Level:
X-Spam-Status: No, score=-2.704 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTv8y2ryGMBi for <openpgp@ietfa.amsl.com>; Mon, 15 Jul 2013 19:02:01 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE3B11E817B for <openpgp@ietf.org>; Mon, 15 Jul 2013 19:02:00 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3bvPxJ6lVlz72B; Mon, 15 Jul 2013 22:01:56 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id fkJNRA4VE-Ip; Mon, 15 Jul 2013 22:01:56 -0400 (EDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 15 Jul 2013 22:01:55 -0400 (EDT)
Received: by bofh.nohats.ca (Postfix, from userid 500) id D3F06817DB; Mon, 15 Jul 2013 22:01:55 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C6F0F817D7; Mon, 15 Jul 2013 22:01:55 -0400 (EDT)
Date: Mon, 15 Jul 2013 22:01:55 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Andrey Jivsov <openpgp@brainhub.org>
In-Reply-To: <51E482E5.5020201@brainhub.org>
Message-ID: <alpine.LFD.2.10.1307152150210.22103@bofh.nohats.ca>
References: <alpine.LFD.2.10.1307151832180.22103@bofh.nohats.ca> <51E482E5.5020201@brainhub.org>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: openpgp@ietf.org
Subject: Re: [openpgp] Fwd: New Version Notification for draft-wouters-dane-openpgp-00.txt (fwd)
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openpgp>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 02:02:05 -0000

On Mon, 15 Jul 2013, Andrey Jivsov wrote:

> A few quick comments follow.

Thanks for the comments.

> This ignores prior work in this area. https://keyserver.pgp.com is known to 
> solve exactly the problems you described for many years now.

Ahh, yet another different webgui? I see the howto also states "You can
only remove your own key and the email address must match exactly". I
had one of my email addresses yanked two years ago with zero notice. I
would not have been able to remove my key. But even so, many (most?)
people still seem to use other more well known, non-commercial,
keyservers, such as pgp.mit.edu and pgp.surfnet.nl. Even if I use very
secure key servers, if people look for my key on crappy old key servers,
the risk remains.

> 2. Given that the size of the record is very important when stored in DNS 
> records, it's odd to see that ECC OpenPGP keys are not even mentioned.

I specifically did not want to limit the record to any particular type.
I just wanted it to support RFC OpenPGP compliant keys. Some people
don't want to use ECC (for legal other other reasons). Others don't
want to use ElGamal, DSA, RSA, etc. There is no reason for this draft
to distinguish and force people to pick a specific key type.

> In 
> fact, given that we are talking about a new format here, one can see many 
> benefits of standardizing *only* on ECC keys or at least 
> preferring/encouraging ECC keys.

There is no new format of public key. Only a base32 encoding for an
existing format. The base32 is there only not cause problems with DNS
(and the LHS needs to use base32, so it seemed prudent to make the RHS
also use base32)

> I think you raise a valid concern that keys placed in DNS records should be 
> "cleaned". A 4096 bit RSA key with 10 subkeys and 3d party signatures seems 
> excessive.

Though still doable. DNSSEC has forced a lot of cleanup of the port 53
TCP path. While I think it is still better to try and keep things small,
I don't think it poses a big problem anymore.

> 3. I suspect that "4.6. Subject: line encryption" is prone to bugs for 
> complex messages with multiple MIME parts. It probably needs more work to be 
> acceptable.

I do feel it is a little out of place, but it's such a simple thing to
do, I wonder why this isn't being done by existing PGP clients and
plugins already. Perhaps it can be rewritten as more of an "informative
hint".

Paul