Re: [dane] I-D Action: draft-ietf-dane-openpgpkey-usage-01.txt

[Pieter Lexis <[e-mail]>]

Hi folks,

I've read this draft (and not my [e-mail] backlog, so dead horses
may be beaten) and have some comments on it.

On 10/28/2014 12:36 AM, [e-mail] wrote:
> 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           : Best Common Practise for using OPENPGPKEY records
>         Author          : Paul Wouters
> 	Filename        : draft-ietf-dane-openpgpkey-usage-01.txt
> 	Pages           : 8
> 	Date            : 2014-10-27

General remarks:

Make it clear early in the document that OPENPGPKEY records are only
valid for their TTL and never permanent but they MAY function to
validate the local public keyring.

Also, nowhere in this draft there is any mention if (and if so, under
what conditions) keys obtained from the DNS may be added to the local
keyring.

Abstract:

This document aims to be a Best Current Practice (in this document also
referred to to Best Common Practice). But at the moment there is no
common practice (or even a current practice ;-)), so this nomenclature
is a bit off. I'd suggest dropping the C{ommon,urrent}.

1. Introduction

- Broken x-ref
- Singular and plural use of MTA and MUA, pick one.


2. The OPENPGPKEY record presence

- Could use some more information on the threat model we're protecting
  against. Like the end-to-end nature of this solution vs transport
  security, or just a reference to section 4 of this document.

3. OpenPGP public key considerations

- This should refer to later sections on what to do with keys obtained
  from the DNS.

3.3 Public Key UIDs and synthesized DNS records

- CNAME's and DNAME's looks clunky, "CNAME and DNAME records" looks
better imo.

3.4 OpenPGP Key size and DNS

- s/DNS Resoruce/DNS Resource/
- Refer to draft-ietf-dane-openpgp section 4, and optionally expand as
  this is almost a copy-paste.

4.  Security Considerations

- s/twart/thwart/
- The terms MUA and MTA are used before in section 1, no need to
  explain/un-acronym them here (do it in section 1)

4.1.  Email address information leak

- Pretends that dictionary attack against a zone (even with NSEC3) has
  the same difficulty as against SMTP

4.2.  OpenPGP security and DNSSEC

- (and other sections) appear to be partially duplicated from the
   openpgpkey draft. Should refer to these sections and expand on them
- s/twart/thwart/

4.3.  MTA behaviour

- s/bogus/Bogus/; s/indeterminate/Indeterminate/ (to match terminology
  from 4035 4.3)
- "the MTA MUST NOT sent the message and queue the plaintext message
  for delivery at a later time” is unclear - should it or should it not
  queue the plaintext message?
- s/sent/send/
- Whether or not encrypt with both keys is also 'just' part of the
  local policy

4.4. MUA behaviour

- "contradicting properties" is somewhat broad, needs
  examples/expansion.

4.5. Email client behaviour

- Needs some information on adding the key to the local keyring and what
  the trust implication is.

-- 
Pieter Lexis