On 20.6.2018 23:01, Mark Andrews wrote: >> On 21 Jun 2018, at 12:25 am, Petr Špaček <petr.spa...@nic.cz> wrote: >> >> On 20.6.2018 16:10, Paul Wouters wrote: >>> On Wed, 20 Jun 2018, Petr Špaček wrote: >>> >>>> it seems that current specification of DNS cookies in RFC 7873 is not >>>> detailed enough to allow deployment of DNS cookies in multi-vendor >>>> anycast setup, i.e. a setup where one IP address is backed by multiple >>>> DNS servers. >>>> >>>> The problem is lack of standardized algorithm to generate server >>>> cookie from a shared secret. In practice, even if users manually >>>> configure the same shared secret, Knot DNS and BIND will use diffrent >>>> algorithm to generate server cookie and as consequence these two >>>> cannot reliably back the same IP address and have DNS cookies enabled. >>>> >>>> One of root server operators told me that they are not going to enable >>>> DNS cookies until it can work with multi-vendor anycast, and I think >>>> this is very reasonable position. >>>> >>>> So, vendors, would you be willing to standardize on small number of >>>> server cookie algorithms to enable multi-vendor deployments? >>> >>> I think this is a good idea but there are already two examples in RFC >>> 7873 for cookie generation. Is there a problem with those examples, or >>> is there only a lack of options in the implementation to configure >>> these? If the latter, than no new IETF work would be needed. >> >> These are mere examples and not specifications with all the details >> necessary for reliable interoperability. > > The server cookie examples have all the details required to build a > interoperable > implementation. i.e. with the same inputs you will get the same outputs.
Sorry, I still do not think it is sufficient for interoperable implementations for multiple reasons: - Let's assume that serverA has time limit for cookie freshness "1 hour" and the serverB in the same anycast cluster "2 hours". This will produce unnecessary BADCOOKIE errors from time to time. - It is not specified how "Time" sub-field in B.2. is encoded on the wire so it is not guaranteed that two different implementations will decode the value in the same way. (Is it in integer seconds? Unix timestamp? Signed or unsigned? How do we handle rollover over 0xFFFFFFFF? ...) - Besides data format we need to explicitly state if sub-fields are big endinan (I guess) or not, etc. Also, let me ask why BIND decided to use AES by default instead of HMAC-SHA256-64 described in the RFC? For me it is appealing to hide content of the cookie from attacker eyes but I'm not willing to implement something without proper description and understanding (cargo-cult algorithms instead of spec, anyone? :-). So let me ask again: Are other vendors willing to work on sufficiently detailed specification? If not just say it! In that case I will be happy to reply to our friendly root operator that it is not going to happen, and consequently throw away code for cookies from Knot Resolver. I do not see value in it without interoperable spec, just maintenance costs. Petr Špaček @ CZ.NIC >> E.g. when a cookie is "old" according to B.2.? >> E.g. are there privacy considerations with plain HMAC vs. encryption? > > >> Besides this, BIND defaults to AES-based algorithm which is not >> specified in the RFC and Knot DNS has its own because developers >> considered the BIND's approch overkill. >> >> If we decide to standardize we need to find a reasonable algorihm and >> standardize all its variables to make it work without run-time >> synchronization (posssibly except key rotation but it can be done >> avoided as well). >> >> This message is for other DNS vendors to see if there is an interest in >> standardizing something we can all share and operators use in practice. >> >> -- >> Petr Špaček @ CZ.NIC _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
