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

[Viktor Dukhovni <[e-mail]>]

On Fri, Feb 20, 2015 at 03:30:05PM -0500, Warren Kumari wrote:

> Please review this draft to see if you think it is ready for
> publication and send comments to the list, clearly stating your view.

Comments:

* The below does not mention the hex encoding of the digest.  Compare with SMIMEA:

   OPENPGPKEY:

    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.

   SMIMEA:

	   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 (with the hash being represented in its hexadecimal
	   representation, to become the left-most label in the prepared
	   domain name.  This does not include the "@" character that
	   separates the left and right sides of the email address.  The
	   string that is used for the local part is a Unicode string
	   encoded in UTF-8.

* Grammar nit replace "its" with "their" or rephrase:

    5.1.  Email address information leak

       Email addresses are not secret.  Using them causes its publication.

* Forward security vouching for long-term keys

    There's a typo in the first word of the highlighted paragraph:

	5.2.  Forward security of OpenPGP versus DNSSEC

	   [...]

	   Therefor, an OpenPGP key obtained via an OPENPGPKEY
	   record can only be trusted as much as the DNS domain
	   can be trusted, and are no substitute for in-person key
	   verification of the "Web of Trust".  See [OPENPGPKEY-USAGE]
	   for more in-depth information on safe usage of OPENPGPKEY
	   based OpenPGP keys.

    An complementary approach is to not use the retrieved OpenPGP
    key beyond the signature lifetime of the OPENPGPKEY RRset RRSIG
    record.  Keys obtained from DNS should be refreshed as often
    as is practical (ideally before encrypting each message) and
    never used beyond the RRSIG lifetime.  Were the RRSIG in question
    signed by an attacker, only messages signed before the key is
    refreshed are compromised.  Of course this requires that PGP
    user agent software track the provenance and cache lifetime of
    keys obtained via DNS.

* Encoding tools:

	Appendix A.  Generating OPENPGPKEY records

	   gpg --export --export-options export-minimal \
	       [e-mail] | base64

  the "openssl base64" command is an alternative on many other platforms.
  Later the examples don't yet use the newly allocated TYPE61:

       These values can then be used to generate a generic record (line
       break has been added for formatting):

       <SHA2-224(hugh)>._openpgpkey.example.com. IN TYPE65280 \# \
	   <numOctets> <keydata in hex>

       ...

       ~> openpgpkey --output generic [e-mail]
       8d[...]b7._openpgpkey.example.com. IN TYPE65280 \# 2313 99008d03[...]

  the type should of course now be TYPE61.  May as well give a
  recipe for generating "SHA2-224(hugh)":

       printf "%s" hugh |
	   openssl dgst -sha224 -binary |
	   hexdump -ve '/1 "%.2x"' -e '/28 "\n"'

-- 
	Viktor.