Ballot for draft-ietf-dnsop-edns-key-tag
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
- abstract: referring to section 1.1 from here seems wrong, the abstract ought be readable by itself - section 5: Is the key tag query only and solely intended to allow the authoritative to track how clients are paying attention (or not) to key rollovers? If there's another purpose I'm not clear about it. - 5.3: "I believe that to be..." seems like the wrong language to use with >1 author. - section 7/8: Is there a missing security/privacy consideration here, in that an authoritative server here could arrange to hand out key tags that are specific to (in the limit) each query, so that when the resolver queries a sub-domain, and thereafter, the client will be identifiable to the authoritative server? One could do this by generating new keys per querier so that if I ask about example.com I get given a tag that's unique to me, and then some web content pushes me to ask about www.example.com and every time I do that I emit that user-specific key tag. While that'd be unlikely for a large zone, it might be feasible as a tracker if some "bad" domain sets up a specific subdomain for such purposes. That said, I'm not clear how much better this is for the attacker compared to simply using a tracking name in the authority component of the URL for e.g. some 1x1 gif.
I am doubtful that this will deploy, considering that there are 2 mechanism. Are there existing or planned implementations of both approaches? I am sorry if I missed that in the shepherding writeup.
It's unfortunate that the working group couldn't agree on one mechanism, but that's not enough to stand in the way of publication.
Discussion engaged between the Mahesh (OPS DIR reviewer) and the author. https://www.ietf.org/mail-archive/web/ops-dir/current/msg02457.html