> On 21 Jun 2018, at 5:24 pm, Petr Špaček <petr.spa...@nic.cz> wrote: > > 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.
Your worried about a client that hasn’t talked to the anycast cluster for a hour getting a BADCOOKIE? Knit picking to the extreme. > - 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? …) It is the seconds since Jan 1 1970 ignoring leap seconds in named. Serial arithmetic will be fine for the rollover in 2038 or you can just use a straight unsigned modulus value and have a extra BADCOOKIE per client during the first hour. > - Besides data format we need to explicitly state if sub-fields are big > endinan (I guess) or not, etc. We used network byte order like every other field in the DNS. > Also, let me ask why BIND decided to use AES by default instead of > HMAC-SHA256-64 described in the RFC? Because it is faster and unless you are running a anycast cluster it doesn’t matter what algorithm is being used as all you need to be able to do is handle your own output being returned to you. BIND implements 2 or 3 hashes. How many depends on what version of OpenSSL it is linked against does it have AES support or not. AES is used to generate a HASH which is actually documented in RFC 7873. There is no “hiding” the cookie from from the attacker. > 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 -- 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
