[secdir] draft-ietf-dane-openpgpkey-06 SECDIR Review

[Donald Eastlake <[e-mail]>]

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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]