Re: [openpgp] The DANE draft

[Werner Koch <[e-mail]>]

On Fri, 24 Jul 2015 12:40, [e-mail] said:

> 2) If people find it does not meet OpenPGP needs, they should say so and
> have no qualms about objecting. It is much more important that there be a
> spec people use than that the document progress quickly.

I was a bit disappointed by the process: I learned about the I-D too late
and was surprised that it started out at the OpenPGP WG mailing list (2
years ago?) with just a few messages and then continued at the DANE list
without having notified the OpenPGP list.  IIRC, I send some thoughts on
this to the GnuPG list but people told me that it is too late for
changes to the I-D - so I gave up.

Here are some thoughts, anyway:

- Why a new DNS record despite that the CERT type has PGP support for
  9 years now (RFC-4398). 

  The argument for a new record is that this makes parsing easier
  because there is no need to loop over the record's sub-types.  I do
  not consider it a valid argument because there is a need to loop
  anyway because there may be several DANE records for the same key.
  Adding an extra loop over the sub-types is a non-brainer and the
  selection logic to find the best matching record will be the same.

  The CERT record is more flexible because it also allows the use of an
  indirect specification via fingerprint.  DANE however could use the
  straight PGP record and would be done.

  GnuPG has support for such CERT records including a script to create
  them also for about 9 years.  It is not widely used because most users
  have no way to add records to their zone - that is the same problem
  for DANE of course.

- The use of SHA-224 (really, see below) to map addresses to valid DNS
  characters is pure overkill.  The shorter SHA-1 is sufficient for
  this.  Counter argument is that SHA-1 shall be phased out.  I have not
  looked up that IETF statement but I hope it states the "use of SHA-1
  for cryptographic purposes".  For example rsync(1) still uses MD5
  which is sound for its purpose (SHA-1 would be better due to hardware
  support but that is another story). 

  Actually it is using SHA-256 truncated to the size of SHA-224.  Why
  not using SHA-224 (which has a different IV)?  That is surprising for
  any implementer.

- The I-D says about the local-part of the mail address:  

      ... it is turned into lowercase and hashed using the SHA2-256
      [RFC5754] algorithm, with the hash truncated to 28 octets ...

  Lowercasing UTF-8 characters is not easy and a likely reasons for
  interoperability problems.  It would be better to only require
  lowercasing ASCII characters and keep characters > 127 as they are.
   
- There is no hint in the RFC on how to find a key to verify a
  signature.  This can't be done via a mail address but requires the
  fingerprint (or as of today the key-id).

- How shall a key be retrieved or updated after a mail account has been
  closed?  It should be possible to verify signatures at all times.

  Thus another non DNS service to keep the key available needs to be
  setup too (e.g. a keyserver).  That service is also required to allow
  dissemination of revocation certificates.  IPGP records could be kept
  as long as the mail address has not been re-assigned.

- Implementation nit: The I-D states:

      The lookup result MUST pass DNSSEC validation; if validation
      reaches any state other than "Secure", the verification MUST be
      treated as a failure.

  As an implementer I see no way to do this without adding a full
  fledged DNSSEC resolver.
  

> People have been attempting to put email address related records into the
> DNS since the first drafts of the spec and none has taken off.

That is a general problem.  You need the support from the mail
providers.

> I do not find the idea of relying on the DNS for my keys remotely
> comforting and would not want to rely on such a record directly. The DNS
> has no persistence to it. Give me the MIT keyserver any day.

When intending to send a mail the first time the DNS is pretty useful
because it creates an association between mail address and key.  Thus
you can pick the right key and the recipient won't be annoyed by
encrypted mails they can't decrypt because the keyservers carry several
"faked" keys for their mail address.



Salam-Shalom,

   Werner

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