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

[Mark Andrews <[e-mail]>]

> On 21 Jun 2018, at 5:24 pm, Petr Špaček <[e-mail]> wrote:
> 
> On 20.6.2018 23:01, 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.
> 
> 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: [phone]              INTERNET: [e-mail]