> On Nov 2, 2015, at 1:23 PM, 神明達哉 <jin...@wide.ad.jp> wrote: > > I've read draft-wessels-edns-key-tag-00. I think it's generally well > written. I have a few small comments.
Thank you for the review. > > - Sections 5.2.1 > > When the recursive server > receives a query with the option set, the recursive server SHOULD set > the edns-key-tag list for any outgoing iterative queries for that > resolution chain to a union of the stub client's Key Tag(s) and the > validating recursive resolver's Key Tag(s). > > What if the recursive server receives the same query from multiple > clients with different key tags and tries to unify the multiple > original queries (some recursive server implementations do this > unification)? Is it expected to include a union of all these key > tags? What if the result of this makes the query too big (even if > it's quite unlikely to happen in practice)? That is an interesting point. I think the implementation should choose its own limit for how many tag values to send in one query. If we need to make a recommendation for the limit I would recommend 10. > > Same questions apply to Section 5.2.2. > > - Regarding security considerations, should we worry about an attack > where the attacker pretends to a massive number of different clients > sending an old key tag, intending to prevent or delay the migration > to a new key? I think this possibility should be documented, although there may be no good solution. The zone operator who collects and analyzes edns-key-tag values should be aware of this potential attack and take reasonable measures to differentiate "real" queries from "attack" queries. DW _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
