Subject: [dane] I-D Action: draft-ietf-dane-openpgpkey-00.txt

From: [email-masked]
Date: Thu, 10 Apr 2014 10:56:23 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

        Title           : Using DANE to Associate OpenPGP public keys with email addresses
        Author          : Paul Wouters
	Filename        : draft-ietf-dane-openpgpkey-00.txt
	Pages           : 8
	Date            : 2014-04-10

Abstract:
   OpenPGP is a message format for email (and file) encryption, that
   lacks a standarized 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 datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Petr Spacek <[email-masked]>
Date: Tue, 22 Apr 2014 10:43:18 +0200

Hello!

I would like to comment on

> 3. Location of the OpenPGPKEY record
>
>    Email addresses are mapped into DNS using the following method:
>
>    1.  The user name (the "left-hand side" of the email address, called
>        the "local-part" in the mail message format definition [RFC2822]
>        and the "local part" in the specification for internationalized
>        email [RFC6530]), is hashed using the SHA2-224 [RFC5754]
>        algorithm to become the left-most label in the prepared domain
>        name.  This does not include the at symbol ("@") that separates
>        the left and right sides of the email address.
>
>    2.  The DNS does not allow the use of all characters that are
>        supported in "local-part" of email addresses as defined in
>        [RFC2822] and [RFC6530] . The SHA2-224 hashing of the user name
>        ensures that none of these characters would need to be placed
>        directly in the DNS.
1) SHA-224 result representation:
IMHO this section should state that SHA2-224 result has to be encoded to 
hexadecimal representation.

I know that hexadecimal is a common representation for user interfaces but 
please keep in mind that SHA2-224 produces 224 bites of "noise" and 
hexadecimal representation is not the only possible.

2) Multiple OPENPGPKEY records for one owner name:
I didn't see a note if OPENPGPKEY is supposed to be singleton or not (and how 
it should be processed if it isn't singleton). I'm sorry if I missed the note.

3) Algorithm agility:
It is clear to me that SHA2-224 hashing is there "just" for privacy and 
nothing else. Still, I think it would be beneficial to have algorithm agility 
built-in.

What about
8d[..]b7.sha224._openpgpkey.example.com.  IN OPENPGPKEY <base64 public key>
?

Of course, the client need to know where to look for keys.

I can see two approaches:
- "Dumb" clients will try all supported algorithms starting with the strongest.
- List of available algorithms can be published under _openpgpkey.example.com.

Note that I'm perfectly fine with defining only SHA-224 for now. Basically 
this is the same situation as with SSHFP fingerprint types. They started with 
SHA-1 only but with the alg. agility built-in.

Maybe we could have yet another IANA registry for this...

A new registry would allow us to do fancy things in future.

E.g. to define "salted-sha-224" algorithm and store salt under 
ssha224._openpgpkey.example.com. That still allows you to share _openphpkey 
sub-tree between domains...

Or to define "clear" algorithm if deemed.

Or to define a clever way how to cut hash into several labels if we need to do 
so ...

Have a nice day!

-- 
Petr^2 Spacek

---

From: Petr Spacek <[email-masked]>
Date: Tue, 22 Apr 2014 13:15:47 +0200

> Or to define a clever way how to cut hash into several labels if we need to do

Hmm, I have even more controversial idea:

What about CERT RR?
http://tools.ietf.org/html/rfc4398#section-2.1 contains this (beside others):

2.1. Certificate Type Values

    The following values are defined or reserved:

          Value  Mnemonic  Certificate Type
          -----  --------  ----------------
              3  PGP       OpenPGP packet

I wasn't around when CERT was designed and I haven't seen it in wild, so 
please bear with me if I'm totally wrong :-)

http://tools.ietf.org/html/rfc4398#section-3.3
seems to define basically the same thing as draft-ietf-dane-openpgpkey-00 - 
except usage of hashing for owner name derivation.

What is the advantage of using OPENPGPKEY RR instead of CERT RR?

Can we use CERT and drop OPENPGPKEY RR definition from 
draft-ietf-dane-openpgpkey and define "Location of the OpenPGPKEY record"?

Also, RFC 4398 mentions OpenPGP revocation certificates. It sounds like an 
interesting idea... I can imagine using DNS for key revocation in the same way 
as for key distribution.

-- 
Petr^2 Spacek

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 22 Apr 2014 12:49:54 +0000

On Tue, Apr 22, 2014 at 10:43:18AM +0200, Petr Spacek wrote:

> nothing else. Still, I think it would be beneficial to have algorithm
> agility built-in.

In this specification sha2-224 does not play a security role.  It
is used not for privacy but rather as a short-enough and yet strongly
collision resistant representation of potentially longer email
addresses that would not fit into a DNS label.  It is expected that
the number of email addresses with SMIMEA or OPENPGP keys in any one
domain will be substantially less than 2^{112} (~ 10^{34}).  A domain
with 10^9 users will have two users with the same lookup key
with probability roughly 2^{-62} or ~10^{-16}.

There is no need for "algorithm agility" here.  This is a lookup
key construct, not a tamper-resistant signature.  In fact multiple
algorithms would be entirely counter-productive in this context.

-- 
	Viktor.

---

From: Petr Spacek <[email-masked]>
Date: Tue, 22 Apr 2014 16:34:06 +0200

> In this specification sha2-224 does not play a security role.  It
Hmm, I should have read section 5.1 more than once :-)

> key construct, not a tamper-resistant signature.  In fact multiple
Just to be clear - I have never used term "tamper-resistant" in this context.

> algorithms would be entirely counter-productive in this context.
I agree. I'm sorry for the noise created by my comment (3).

My comments (1), (2) and the second e-mail with question about CERT RR still 
apply.

-- 
Petr^2 Spacek

---

From: James Cloos <[email-masked]>
Date: Tue, 22 Apr 2014 18:02:39 -0400

>>>>> "PS" == Petr Spacek <[email-masked]> writes:

PS> What about CERT RR?
PS> http://tools.ietf.org/html/rfc4398#section-2.1 contains this (beside others):

Cert uses the user portion of the email address as-is, and therefor only
supports usernames which fit unalterred in dns.

Some aspects of the rfc are a bit terse.  Can you tell, for IPGP,
whether the length octet is a bit-lenght or an octet-length?  Or
which data, exactly, is digested to create the key tag?

James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Paul Wouters <[email-masked]>
Date: Tue, 22 Apr 2014 18:42:42 -0400 (EDT)

> supports usernames which fit unalterred in dns.

Correct. Although we could have used the openpgpkey style _prefix to
avoid that, there were more issues with the CERT record type.

CERT also uses sub-typing, so you might end up getting all kind of types
of certificates (like a PKIX cert) that you don't want or need. Granted,
the _openpgpkey. prefix would at least prevent the non-malicious
contamination, but you might still get all kinds of weird stuff. From
what I understood, sub-typing was what really killed the CERT record,
and everyone since has been strongly urged to stay away from sub-typing,
and told to use _prefix. instead.

The CERT record also does not offer a nice presentation format for the
zone file. The RFC states:

       smith        IN CERT PGP 0 0 <OpenPGP binary>

Having binary in a zone is really a non-starter. Which is why OPENPGPKEY
uses base64 as the presentation format and the raw binary as the wire
format.

> which data, exactly, is digested to create the key tag?

IPGP specifies a URL, so now that url becomes another security hurdle.
What do you do when it is on https and you don't trust the CA, ignore.
What do you do when the URL is unreachable - is that censorship/attack?
With the full key in DNSSEC, you get the entire key using only one DNS
query without any followup HTTP(S) queries that you might not be able to
do for various (security/monitoring) reasons.

It seemed much more desirable to start a fresh dedicated RRTYPE over
fixing up the CERT RRTYPE and then needing to deal with servers that
only support the "old CERT type" versus ones that support the "new CERT
type". In other words, the pain of recycling was worse than just
starting fresh.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Apr 2014 09:41:12 +1000

> and told to use _prefix. instead.

	Then you have failed to understand RFC 5507.

>        smith        IN CERT PGP 0 0 <OpenPGP binary>

	CERT records have base64 as the presentation format of the
	binary blob.  This is independent of the type of certificate
	being encoded.  See RFC 4398 2.2 Text Representation of CERT RRs.
	I think you are confusing wire format and presentation format.

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 22 Apr 2014 21:44:43 -0400 (EDT)

> 	Then you have failed to understand RFC 5507.

Hmm, I read from RFC 5507"

    When storing data in the DNS for a new application, the goal must be
    to store data in such a way that the application can query for the
    data it wants, while minimizing both the impact on existing
    applications and the amount of extra data transferred to the client.
    This implies that a number of design choices have to be made, where
    the most important is to ensure that a precise selection of what data
    to return must be made already in the query.

To me that reads as "don't do sub-typing" because the query cannot
request the single type it is interested it, and can only get the full
list.

> 	binary blob.

The line above here containing "smith" comes straight from that same
RFC, so that's a little confusing then :P I did not read "<OpenPGP binary>"
as "base64" :P

Maybe we should file an errata (if people cared about CERT)

Paul

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Apr 2014 12:45:11 +1000

> Maybe we should file an errata (if people cared about CERT)

As far as I can see you want a new type to save 5 bytes per record.
There is no need for a new type especially as you are using a prefix
to seperate usage.  CERT is quite capable of holding the data.

I can see some use in encoding local part as we don't want case
insensitve local parts.  We also don't want to be able to just list
out the PI data.  Additionally a prefix is useful for seperating
name spaces (people vs machines).  Standard mbox encoding (RFC 1034)
doesn't seperate the name spaces which has always been a problem.

I would recommend changing the draft to focus on why mbox is not a
good format for the DNS keys for email addresses for and just encode
the data using CERTs.

Note ":" + base32hexnp(sha1(utf8(local))) would be sufficient without
the _openpgpkey label to seperate namespaces. (':' could be replaced
with any non LDH character)  Reserve all strings which match that
format for the new mbox format.

base32hexnp = base32hex with no padding as used in NSEC3.

Mark