Resource Records for EUI-48 and EUI-64 Addresses in the DNS
draft-jabley-dnsext-eui48-eui64-rrtypes-07
Yes
(Joel Jaeggli)
No Objection
(Barry Leiba)
(Brian Haberman)
(Jari Arkko)
(Richard Barnes)
Abstain
Note: This ballot was opened for revision 05 and is now closed.
Joel Jaeggli Former IESG member
Yes
Yes
(for -05)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -05)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -05)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -05)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -05)
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2013-08-14)
Unknown
In s9 (from secdir reviewer): Can we replace the term "Global bit" with a term more consistant with RFC5342 or RFC4291? RFC 5342 calls this bit the "Local bit" and the "Local/Global bit". RFC4291 calls this the "universal/local" bit. The IEEE 802 standard talks about "universal" and "local" without actually naming the bit, but lots of online documentation says "universal/local" and "U/L". The privacy concern arises not just from the uniqueness of the EUI but from the fact that it is a more permanent identifier than the IP address associated with the subscriber (as the next paragraph notes). So maybe in the first paragraph: r/in the form of unique trackable/in the form of unique, permanent trackable identities likewise maybe: r/typically change over time/provide a unique permanent identifier
Spencer Dawkins Former IESG member
No Objection
No Objection
(2013-08-09 for -05)
Unknown
I happen to agree with what Martin says in his "Abstain", but I'm tipping to "No Objection" because the specification documents existing RR assignments (EUI48 and EUI64 are already in http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4), describes the privacy considerations of including this information in the public DNS, and recommends that "EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS".
Martin Stiemerling Former IESG member
Abstain
Abstain
(2013-08-08 for -05)
Unknown
I do not see that any type of hardware identifier should be stored in the DNS at all. I also find the use case odd, though I do understand that there is a regulatory requirement to implement this. However, I do not want to block this draft and I'm balloting abstain for that reason.
Stephen Farrell Former IESG member
Abstain
Abstain
(2013-08-15 for -05)
Unknown
I'm abstaining because I think this is standardising a very dubious practice that is not really needed except (it seems) for compliance with a really silly regulation in one country. But I agree with Ted that the IETF seems to have rough consensus to publish this, which is a pity IMO. - Where is there a definition of a private DNS namespace? If that is not defined, how can an implementer or deployment know whether or not its ok to publish these records in their DNS? I *think* I know that is meant, but not very precisely and absent such a definition isn't there a real danger that the (weak) privacy mitigation suggested will be mythical? (If a good definition exists, all that'd be needed is a reference, and I'm not saying that I think that has to be an RFC, just good and easily accessible.) - abstract and intro: I think you should s/where/if/ in: "This document specifies an interoperable encoding of these address types for use in private DNS namespaces, where the privacy concerns can be constrained and mitigated." The current text suggests that all you need is a "private DNS namespace" and you're done, which is not the case. - Section 5: It was my impression that the IETF LC demonstrated a consensus that the Canadian regulation was crappy. I think to properly reflect the quite rough consensus this should say something about that here, so that its clear that these RRs are not what the IETF would do, were it to design a solution for this use-case. - Section 8: was any consideration given to putting ciphertext forms of these values into RRs? Surely that'd be a better mitigation than depending on access control for DNS queries? For example, in the cited use-case the EUI value could be encrypted with a public-key before being placed into the DNS. (Yes, that's also a crappy solution, but perhaps less crappy than this.)
Ted Lemon Former IESG member
Abstain
Abstain
(2013-08-14 for -05)
Unknown
As I've said in the past, I think this is a bad idea, because it encourages the use of private identifiers in the DNS, which I expect will result in leakage despite the document's admonition against publishing these records in public zones. But the IETF appears to disagree, at least according to the results of the IETF last call, so I will just abstain rather than arguing about it further.