Re: [DNSOP] DNS cookies and multi-vendor anycast incompatibility

[Daniel Salzman <[e-mail]>]

Hello Mark,

On 06/20/2018 11:01 PM, Mark Andrews wrote:
> 
>> On 21 Jun 2018, at 12:25 am, Petr Špaček <[e-mail]> 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?

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>