Hi Stephen,
> > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - abstract: referring to section 1.1 from here seems wrong, > the abstract ought be readable by itself Agreed. I propose to remove that sentence and let the abstract stand on its own. > > - 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. Yes, that is the sole purpose. Do you think this needs to be made more explicit? > > - 5.3: "I believe that to be..." seems like the wrong language > to use with >1 author. Yes. This sentence was already removed from the authors' shared source file shortly after -04 was sent out. > > - 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. One important aspect to clarify here is that resolver shouldn't be transmitting the key tags for every query. They are only to be sent with or at the same time as DNSKEY queries. 4.2 says that the edns-key-tag option MUST NOT be sent for non-DNSKEY queries. 5.2 says the need to issue a DNSKEY query is also the trigger to issue a key tag query. Additionally, the document says that resolvers SHOULD transmit the key tags for zones with configured trust anchors and MAY do so for non-trust anchor zones. For most resolvers only the root zone would be configured as a trust anchor. Lastly, there is a practical limitation here in that each unique key given out would require a corresponding unique DS record in the parent zone. A malicious zone operator might be able to get away with tens of unique keys, but probably not hundreds. The one exception to this would be if the malicious actor operated both a parent zone and a child zone. Given all that, do you think it warrants a paragraph in the privacy section? DW _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
