Skip to main content

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.