Hi folks, I've read this draft (and not my [email protected] backlog, so dead horses may be beaten) and have some comments on it.
On 10/28/2014 12:36 AM, [email protected] 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 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
