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

From: Paul Wouters <[email-masked]>
Date: Mon, 15 Jul 2013 18:32:46 -0400 (EDT)

I've submitted a draft to associate an PGP public key with an email address using DANE.

Paul

A new version of I-D, draft-wouters-dane-openpgp-00.txt
has been successfully submitted by Paul Wouters and posted to the
IETF repository.

Filename:	 draft-wouters-dane-openpgp
Revision:	 00
Title:		 Using DANE to Associate OpenPGP public keys with email addresses
Creation date:	 2013-07-15
Group:		 Individual Submission
Number of pages: 11
URL:             http://www.ietf.org/internet-drafts/draft-wouters-dane-openpgp-00.txt
Status:          http://datatracker.ietf.org/doc/draft-wouters-dane-openpgp
Htmlized:        http://tools.ietf.org/html/draft-wouters-dane-openpgp-00

Abstract:
    OpenPGP is a message format for email (and file) encryption, that
    lacks a standarized secure lookup mechanism to obtain OpenPGP public
    keys.  This document specifies a standarized method for securely
    publishing and locating OpenPGP public keys in DNS using a new
    OPENPGPKEY DNS Resource Record.

The IETF Secretariat

_______________________________________________
dane mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dane

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 15 Jul 2013 16:16:53 -0700

A few quick comments follow.

1.
> Currently deployed key servers have no method of validating any
>    uploaded OpenPGP public key.  The key servers simply store and
>    publish.  Anyone can add public keys with any name or email address
>    and anyone can add signatures to any other public key using forged
>    malicious identities.  For example, bogus keys of prominent
>    dissidents have been uploaded to these well-known key servers in
>    attempts to capture encrypted email.  Furthermore, once uploaded,
>    public keys cannot be deleted.  People who did not pre-sign a key
>    revocation and who have lost access to their private key can never
>    remove their public key from these key servers.

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

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. 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.

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.

I planned to introduce the compact key format 
http://tools.ietf.org/html/draft-jivsov-ecc-compact soon to OpenPGP. 
This might be a mandatory tweak to further minimize the size for ECC 
keys when stored in DNS records.

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.

On 07/15/2013 03:32 PM, Paul Wouters wrote:
> URL:
> http://www.ietf.org/internet-drafts/draft-wouters-dane-openpgp-00.txt
...

---

From: Paul Wouters <[email-masked]>
Date: Mon, 15 Jul 2013 22:01:55 -0400 (EDT)

> 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.

> 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

---

From: Werner Koch <[email-masked]>
Date: Tue, 16 Jul 2013 08:06:40 +0200

> I've submitted a draft to associate an PGP public key with an email address using DANE.

Some quick notes:

Basically this is the same as the existing CERT RRs which are support by
GnuPG for many years.  The twist here is the Base32 encoding, which is
avoids a few problems.  I might haved missed that but they are not
mentioned in the I-D.

What I miss in this I-D are indirections and the use of URLs to download
a complete key.  Putting a 100k keyring into the DNS does not seem to be
optimal.  Granted, this is the exception but provisions for this should
be defined.

I consider wildcard mail address a bad idea.  If you do not want
end-to-end encryption, STARTTLS is much easier measure (we are not
relaying anymore, right?)

> 4.6.  Subject: line encryption

There is a well defined way to do this.  The special case for the
Subject is not needed.  Wrap the mail into an message/rfc822 containers
which has innocent headers.  In any case I doubt that this is in the
scope of the I-D.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Andrey Jivsov <[email-masked]>
Date: Thu, 18 Jul 2013 11:33:50 -0700

On 07/15/2013 07:01 PM, Paul Wouters wrote:
>> This ignores prior work in this area. https://keyserver.pgp.com is
>> known to solve exactly the problems you described for many years now.
>

Yes, it's a valid use case. The https://keyserver.pgp.com server will 
periodically send renewal requests to e-mails on the key, and if the 
owner doesn't reply the key key will be deleted.

>> mentioned.

I agree that support for all keys is one way to do this, but this 
intention is unclear from the draft-wouters-dane-openpgp-00.txt: if one 
mentions RFC 4880 but not RFC 6637, it can be interpreted as the 
exclusion of ECC keys.

...

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Jul 2013 15:21:19 -0400 (EDT)

On Thu, 18 Jul 2013, Andrey Jivsov wrote:

> I agree that support for all keys is one way to do this, but this intention 
> is unclear from the draft-wouters-dane-openpgp-00.txt: if one mentions RFC 
> 4880 but not RFC 6637, it can be interpreted as the exclusion of ECC keys.

I was simply not aware of RFC 6637. I will add a reference to it in the
document. Thanks!

Paul