On 06/21/2018 05:09 PM, Mark Andrews wrote: > >> On 21 Jun 2018, at 5:21 pm, Daniel Salzman <[email protected]> wrote: >> >> Hello Mark, >> >> On 06/20/2018 11:01 PM, Mark Andrews wrote: >>> >>>> On 21 Jun 2018, at 12:25 am, Petr Špaček <[email protected]> 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 >
I mean if one implementation computes cookies based on "Client IP Address | Client Cookie | Server Secret", then it cannot be interoperable with another implementation which is based on "Server Secret, (Client Cookie | Nonce | Time | Client IP Addres)", no matter which hashing algorithm is used. And still both implementations comply with the RFC (I think). >> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
