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

[Daniel Salzman <[e-mail]>]

On 06/21/2018 05:09 PM, Mark Andrews wrote:
> 
>> On 21 Jun 2018, at 5:21 pm, Daniel Salzman <[e-mail]> wrote:
>>
>> 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?
> 
> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dnsop
>