Hiya,
On 16/02/17 21:43, Wessels, Duane wrote: > > 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? Up to you. It wasn't clear to me at first, but was clear when I finished reading. > > >> >> - 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? Again, up to you. The issue is fairly borderline so I won't argue if you don't wanna. S. > > > DW >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
