I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I did not review Appendix A or Section 8 (Implementation Status). I think this draft is not ready for publication. It probably minimal technical changes but there are significant wording problems with it. Security: ------------ This document is "DANE for OpenPGP ..." but never says how what it documents is a use of DANE or what DANE is. While there is a reference to RFC 6698, at a minimum the DANE acronym should be expanded at first use and/or in Section 1.2. Preferably two or three sentences should be added to fix this gap. I am concerned about the use of the words "validate" and "verify" in this document in a wide variety of different ways, and in particular their use in connection with OPENPGPKEY RRs. The ordinary and usual meaning of these words, when they are not qualified in some way, is that something is completely valid/verified for use and can be used without further checking. But that isn't what seems to be meant in this document. Here it just seems to sometimes mean that it has validated under DNSSEC. It might also mean that it is of valid syntax and a bit more -- the document is unclear on whether that is included. But the use of these words for OPENPGPKEY RRs seems to exclude the validation under the web of trust or human judgement even though that step is mandated at a couple of places in the document. Looking at Section 5, the "obtain or verify" in the first sentence seems odd. Shouldn't it use "and" and be more like "obtain and DNSSEC verify"? And in the following sentence, I would say "... ; if DNSSEC validation reaches ..." Also, if you are going to start talking about a specific DNSSEC state name as is done here, there should be a reference to the specific DNSSEC RFC where that state name is defined. In Section 5.1, in the first sentence, I would say "to seek" rather than "to discover". "discover" makes it sound like it will always un-cover/find something; also I think it would be a bit better to say "corresponding to" rather than "belongs to". The last sentence in 5.1 has too many confusing "this"s. Suggest, assuming I have correctly understood what you want to say, replacing the current last sentence with "An application whose attempt fails to retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember that failure for some time to avoid sending out a DNS request for each email message the application is sending out; such DNS requests constitute a privacy leak". I suggest changing the title of Section 5.2 to "Confirming that an OpenPGP key is current" since that is what it is about, not about general validity. The third sentence of Section 5.2 ("If verifying ... a failure") is unclear and not grammatical. Trying to re-write this third sentence I come up with "If a locally stored OpenPGP public key is found to be different from an OpenPGP retrieved from the DNS and DNSSEC verified as described herein, then ...." But I don't understand this and don't understand what the "..." should be. Can't there can be multiple good OpenPGP keys for the same email address? What if one key is stored locally and you retrieve two keys, one of which is equal to the local key and one of which is different? Presumably it depends on the local/user's policy what to do in such a case of different keys. How is it helpful to say "the verification MUST be treated as a failure"? (This certainly further confuses what "verification" means in this document.) It is not clear exactly what that means but if it says that a DNSSEC verified OpenPGP key retrieved from the DNS should be dropped/ignored, why is that always the right thing? And again, what if more than one are retrieved? (Possibly a re-written third sentence and the following two sentences in this Section should be a separate second paragraph.) In the second sentence of the first paragraph of Section 7, what does the initial "It" stand for? You might think from the previous sentence that "it" was for DNSSEC but as you keep reading that can't be right because I don't think "DNSSEC" equals "ease in obtaining". "DNS" might equal ease in obtaining. So maybe it is "DNSSEC and DNS" but things get more confusing as the sentence continues. What is "better then plaintext" (should be "than")? Presumably not the key retrieved but rather the email transmitted with that key? But is that always true? If you were faked-out and believed a false key so email was encrypted to the bad guy and could not be read by the intended recipient, I would say that was worse than plaintext. This paragraph goes on to talk about active attacks, which usually. in the email context, refers to active attacks on the email on the wire, but I would guess this text is actually talking about active attacks in the form of storing a wrong key in the DNS... In re Section 7.5, why isn't the domain name included in the hash? It seems to improve security a little and the effort is small. Other: -------- Section 1: The references for Secure DNS should be given when Secure DNS is first mentioned on page 3. Section 1.1: I do not think there is such a thing as an "Experimental RRtype". It would be better to say something like "This document specifies an RRtype whose use is Experimental." I don't quite grok the use of "generality of" on page 4. Perhaps it should be replaced with "diffuse support of" or something. Section 2: As long as you are bothering to say that the OPENPGPKEY RR has no special TTL requirements, you might as well say it has no special Additional section retrieval requirements, since I think that is the most common type of RR special processing. But I think the lack of such special requirements is the default so you could probably just leave these negative statements out. Section 2.3: "textual zone files" -> "master files [RFC1035]" and add [RFC1035] to the normative references. Section 3: The following statement seems at least a little misleading: The DNS does not allow the use of all characters that are supported in the "local-part" of email addresses as defined in [RFC5322] and [RFC6530]. DNS is binary clean. What left hand side characters allowed in [RFC5322] are now allowed in DNS? Seems to me that only international text as such [RFC6530] is a problem for DNS. Probably the first bullet should be split in two. The first time I read it, it seemed that the first sentence was talking about some encodings. Then the second sentence talks about other encodings and says they are hashed. So, of course, I thought that the encodings talked about in the first sentence were not hashed. But the example appears to show that the current text had conveyed the wrong thing to me and that it is always hashes. I suggest that after "If it is written in another encoding it should be converted to UTF-8" be followed by a period and then there should be a new bullet item talking about hashing, etc., to make it clear that the hashing, etc., apply to all encodings in the first bullet. Furthermore, I don't understand why the text fragment I quote says "should" rather than "must" or perhaps just replace "should be" with "is". Then we get to the truncation. "Truncation comes from the right-most octets." is completely ambiguous. At a minimum, a word needs to be added so it says "Truncation comes from using the right-most octets." or "Truncation comes from dropping the right-most octets." Alternatively some other non-ambiguous wording is needed. Presumably it is believed that the probability of a hash collision is small enough that it can be ignored. If so, it wouldn't hurt to say so. Section 7: The last paragraph of Section 7 seems to equate "Organizations" and "mail servers". Suggest recasting the second sentence as "Mail servers of such organizations MAY optionally re-encrypt a received message to an individual's OpenPGP key.". Section 7.1: Again, I assume "indeterminate" and "bogus" are used in their DNSSEC meaning. So there needs to be a reference here to the DNSSEC RFC that explains those words. Author's Address: I understand that many do not agree with me but I believe that first page authors should normally list a postal address and a telephone number to which a message could be sent or at which a message could be left for them in addition to an email address. This section looks like schlock corner cutting to me. Trivia: -------- "twart" -> "thwart" and "twarts" -> "thwarts" Section 6: "properties are not exported" -> "properties not be exported" and in the following sentence "have" -> "has" Section 7: "direct" -> "ask" (a mail client has no power to order the user to do anything) Section 7.1: 5th paragraph, "sent" -> "send" Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3 at gmail.com