DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP
RFC 7929

Note: This ballot was opened for revision 08 and is now closed.

(Stephen Farrell) Yes

Alexey Melnikov (was Discuss) Yes

Comment (2016-05-03)
No email
send info
NOTE to editors: Thank you for addressing my earlier comments in -09, -10 and -12.

Despite many objections to publishing this specification I believe we should run the experiment. I will vote "Yes" once DISCUSS-points are addressed. I would rather see this experiment being done and fail (or better - succeed), than to block publication of this document because it is not perfect.

Some (edited) comments from Ned Freed that I (mostly) agree with:

1) In Section 3:

When describing unquoting and unescaping, I think it would be useful to give an example, for example all of the following are equivalent and must result in the same hashed value:

(1) first.last@example.com
(2) first . last @example.com
(3) "first.last"@example.com
(4) "\f\i\r\s\t.last"@example.com

2)

5.1.  Obtaining an OpenPGP key for a specific email address

   If no OpenPGP public keys are known for an email address, an
   OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key
   that corresponds to that email address.  This public key can then be
   used to verify a received signed message or can be used to send out
   an encrypted email message.  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

Should the document give a specific recommendation about "remember for some time"? Is it tied to TTL for the corresponding RR?
If you can provide some additional text explaining what is reasonable (or not) here, that would improve the specification.

(Kathleen Moriarty) Yes

Comment (2016-04-13 for -08)
No email
send info
This sounds like a worth while experiment and with Alexey's discuss & comments addressed, it will be well specified.  I'll be interested to see the results and findings on space considerations for DNSSec.

(Jari Arkko) No Objection

Comment (2016-04-21 for -10)
No email
send info
There are some editorial comments from Matt's Gen-ART review, probably worthwhile to address these.

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2016-04-20 for -10)
No email
send info
I agree with Mirja that it would be nice if the shepherd's writeup were updated to reflect the experimental status.

Alissa Cooper No Objection

Comment (2016-04-20 for -10)
No email
send info
I know there has been a lot of list discussion of this draft so I apologize if these issues have already been discussed before.

I think if this sees any sizable deployment, it will be trivial for attackers to use it to harvest email addresses from the DNS. Section 7.4 therefore seems to be quite misleading. I don't see why a zone walk is necessary to do this kind of harvesting when an attacker could just send one query per entry in its dictionary. I think it would be more accurate to say that by using this mechanism, people are effectively making their email addresses public.

I also think the mechanism could facilitate pervasive monitoring as described in RFC 7258, as it potentially makes a whole class of entities (resolvers) into repositories of detailed data about who has communicated with whom via email. To the extent that large DNS providers keep logs about individual queries, it seems like those logs could become prime attack targets. The mechanism specified here can obviously help mitigate pervasive monitoring in other ways, but I think the draft needs to be up front about the trade-offs between potentially exposing metadata to a wider pool of entities and attackers in exchange for more easily being able to protect content.

(Joel Jaeggli) No Objection

Suresh Krishnan No Objection

Mirja K├╝hlewind No Objection

Comment (2016-04-20 for -10)
No email
send info
[Please update shepherd write-up, it still says: Some people have said that they would be more comfortable with the document published as Experimental. The working group requests publication as Standards Track but can live with Experimental status. ]

(Terry Manderson) No Objection

Alvaro Retana No Objection