> On 21 Jun 2018, at 5:21 pm, Daniel Salzman <daniel.salz...@nic.cz> wrote: > > Hello Mark, > > On 06/20/2018 11:01 PM, 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. >> > > So how should the DNS cookies be implemented? IMHO if one server uses > https://tools.ietf.org/html/rfc7873#appendix-B.1 > and another server uses https://tools.ietf.org/html/rfc7873#appendix-B.2, > then it's not interoperable. > Actually the upcoming Knot DNS 2.7 implemented "B.1" using Siphash instead of > FNV. Bind probably implemented B.2. > Are both implementations correct?
Well you are free to inspect the code to ensure that it behaves the way we said it did. The code is in lib/ns/client.c:compute_cookie. Older branches that is bin/named/client.c:compute_cookie > Thanks, > Daniel > >>> 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
