On Mon, Jul 10, 2017 at 5:01 PM, Ólafur Guðmundsson <ola...@cloudflare.com> wrote:
> Shumon, > > In section 5 your draft says: > > If an Authoritative Server has no algorithms in common with the > Preferred Algorithms list in the incoming query, it MUST send back a > SERVFAIL response (Response Code 2). This response MUST contain the > list of algorithms supported by the server in the EDNS0 Preferred > Algorithms option. > > > > This is a HORRIBLE violation of the DNSSEC spirit. All validators are > supposed to fail to open when they can not validate algorithm the signature > is generated by. > As I tried to explain in my previous note to Paul Wouters - fail open is horrible for DANE. Protocols can evolve. If DNSSEC had algorithm negotiation from the beginning, fail open would not have been necessary. This fail open behavior frequently takes people not in the DNSSEC club by complete surprise. I've lost track of how many "WTF" moments I've had to explain to other people about this behavior. This proposed behavior change is also signaled, not unilateral. But let's debate ... Section 6 > This is hopeless algorithm, that goes against the justification of the > document. > basically it may force validating resolvers to fetch the answers multiple > times for each TTL; once without DNSSEC, then for first algorithm, then for > all algorithms ==> right now validating resolvers only fetch once with > DNSSEC enabled. > There has to be some initial fallback behavior with costs. This is not uncommon in new protocols. Think about longer term benefits. > This is a HORRIBLE violation of the DNSSEC spirit. All validators are > supposed to fail to open when they can not validate algorithm the signature > is generated by. > See previous discussion. > > overall this draft main idea: DNS publishers should sign with more > algorithms, ===> this means more keys in DNSKEY set i.e. larger DNSKEY set > ==> better for DDoS > DNSSEC already has a DDoS reputation - this isn't going to make things that much worse. Also DNSSEC has already been way surpassed in this area by NTP/SNMP etc. What we should be working on is deployment of proper protocol level mitigations, like Cookies, etc. -- Shumon Huque
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
