Subject: [DNSOP] comments on draft-wessels-edns-key-tag-00

From: 神明達哉 <[email-masked]>
Date: Mon, 2 Nov 2015 13:23:03 +0900

I've read draft-wessels-edns-key-tag-00.  I think it's generally well
written.  I have a few small comments.

- 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)?

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?

--
JINMEI, Tatuya

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 2 Nov 2015 05:37:10 +0000

> On Nov 2, 2015, at 1:23 PM, 神明達哉 <[email-masked]> wrote:
> 

Thank you for the review.

> 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.

>  sending an old key tag, intending to prevent or delay the migration

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