Hi all,
We have posted a revised -02 and would welcome the WG's view: https://datatracker.ietf.org/doc/draft-li-dnsop-ecs-aggregation-fix/ The problem: when a resolver enables ECS, several implementations expand their query-aggregation key from <qname,qtype> to <qname,qtype,subnet>, and per RFC 7871 a response that omits ECS (or carries SCOPE PREFIX-LENGTH 0) is valid for all clients. Together these revive the birthday-style cache poisoning that aggregation was meant to prevent. This has been demonstrated and measured at scale and assigned multiple CVEs. This revision follows Ondřej's earlier feedback on the draft, which made three points; -02 acts on all three: RFC 7871 is Informational, so this can't target the Standards Track. Agreed — -02 is Informational.The content is already described in RFC 7871 §11.2. Agreed that §11.2 identifies the attack. What §11.2 does not specify is the resolver's response behavior — including the no-ECS / scope-0 case it explicitly leaves open ("...sensitive to a nameserver legitimately stopping ECS replies..."). -02 specifies that behavior: when to mark a zone "no-ECS-support" and force aggregation, how to avoid the false positive §11.2 warns about, and how to handle an unexpected non-ECS response for a zone that does use ECS.An extra RFC for something already in a Security Section doesn't make sense; if there's interest, 7871 might be updated instead. Agreed, and that is exactly what we are proposing: -02 is offered as input toward a revision of RFC 7871, not as a standalone RFC. So our question to the WG is whether there is interest in closing this gap in 7871. We would value the group's view. Thanks, Yuqi 仇渝淇 [email protected] 仇渝淇 [email protected]
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
