Re: [secdir] SecDir Review of draft-ietf-dnsop-cookies-07

[Yoav Nir <[e-mail]>]

> On 9 Dec 2015, at 4:05 AM, Donald Eastlake <[e-mail]> wrote:
> 
> Hi Yoav,
> 
> Thanks for the review. See below
> 
> On Tue, Dec 8, 2015 at 1:52 AM, Yoav Nir <[e-mail]> wrote:
>> 
>> Hi.
>> 
>> I have reviewed this document as part of the Security Directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG.  These comments were written primarily for the benefit of the
>> Security Area Directors.  Document authors, document editors, and WG
>> chairs should treat these comments just as they would any other IETF
>> Last Call comments.
>> 
>> Version reviewed: draft-ietf-dnsop-cookies-07
>> 
>> Summary: has issues.
>> 
>> The draft describes a cookie mechanism (a little more complex than
>> SYN cookies or IKEv2 cookies) to prevent DoS, specifically
>> amplification attacks on the DNS, where an off-path attacker sends
>> requests with spoofed source to a DNS server, causing a lot of DNS
>> traffic towards the spoofed source.
> 
> Also cache poisoning attacks due to forged responses.
> 
>> ISSUES:
>> 
>> Section 5.5 describes what happens when a server rolls over its
>> secret. If the server receives a server cookie fitting the previous
>> server secret, it MUST reply with the new, correct, server
>> cookie. This is implied, but IMO should be stated explicitly,
>> because it is temptingly efficient to just copy the server cookie if
>> it's valid (and a cookie matching the previous secret is considered
>> valid for a while) into the response rather than re-calculating the
>> server cookie before sending.
> 
> OK. Note that it is likely that many servers will always send a new
> Server Cookie with a new time stamp in response to every request,
> similar to the example in Appendix B.2 which is implemented in a beta
> release of BIND.
> 
> How about adding something like "When a server responds to a request
> containing a old Server Cookie that the server is treating as correct,
> the server MUST include a new Server Cookie in its response.”

LGTM

>> An attacker could bypass the whole mechanism by not including the
>> OPT, and the way to deal with this is rate limiting on the server
>> for clients without valid cookies. I think this should be said
>> explicitly in the Security Considerations section.
> 
> How about adding the following: "An attacker that does not know the
> Server Cookie could do a variety of things, such as omitting the
> COOKIE OPT option or sending a random Server Cookie. In general, DNS
> servers need to take other measures, including rate limiting
> responses, to protect from abuse in such cases. See further
> information in Section 5.2.”

Agree

>> Section 9.1 suggests as a cookie algorithm "HMAC-SHA256-64
>> [RFC6234]", which I take to be SHA-256 truncated to 64 bits. There
>> is no such function (not any other truncation) in RFC 6234. Even
>> shortened hashes that do exist in other documents, such as
>> SHA512-256 are not simple truncations but also change the
>> initialization vectors for the original hash function, although
>> shortened HMACs such as those used in IPSec *are* simple
>> truncations.
> 
> OK. How about "HMAC-SHA256-64 [RFC6234]" -> "HMAC-SHA256 [RFC6234]
> truncated to 64 bits", which is what was meant.

Good

>> Same section, it is not clear what the criteria are for selecting an
>> algorithm. Specifically, I don't know what makes FNV strong enough
>> whereas something else (CRC?) is not. I don't think there's a
>> practical issue with FNV, but it would be better to state the goals.
> 
> What criteria would you recommend? The only mandatory requirement is
> in the last sentences of Sections 4.1 and 4.2. FNV64 is intended to be
> the definition of the recommended algorithm strength in the current
> draft.
> 
>> NITS:
>> 
>> "To bypass the weak protection provided by using TCP requires, among
>> other things, that an off-path attacker guessing the 32-bit TCP
>> sequence number in use."  s/guessing/guess/ or s/that an off-path
>> attacker guessing/an off-path attacker to guess/
> 
> OK.
> 
>> The word "weak" is mentioned 18 times, in addition to related terms
>> such as "limited protection". The mechanism does what it does. Sure
>> it does not include 521-bit elliptic curve cryptography, but I don't
>> think this needs to be mentioned so often.
> 
> Hey, we didn't want anyone to think we were claiming cryptographically
> strong protection. If you like, we can pick some of the less prominent
> uses of "weak" and eliminate them.

It’s only style, than substance, but I think mentioning the weakness in Abstract, Introduction and Security Considerations is enough.

>> I think it should be mentioned that the cookie mechanism is
>> notstateless. Of course all of DNS is stateless, but it should be
>> mentioned that the mechanism requires no per-client state on the
>> *server*, but does require per-server state on the *client*.
> 
> Well, the recommended implementation method is stateless at the server
> but it could be implemented in a stateful manner. For example, the
> server could generate a random quantity as the Server Cookie for each
> { client IP and Client Cookie } and remember it. That would, in some
> ways, make the Server Cookie strength as strong as possible,
> reminiscent of a one-time pad. But I don't think anyone will ever do
> that.
> 
> How about adding to Section 4.2: "When implemented as recommended, the
> server need not maintain any cookie related per client state.”

LGTM

>> Section A.1: As mentioned above, I don't know the requirements for
>> an algorithm. But just looking at the following example, I don't
>> like the construction. So I set the secret to 0x3132333435363738,
>> and considered two IP addresses: 97.98.99.100 and
>> 97.98.99.101. Running both through FNV, I get the following:
>>     FNV64("12345678abcd") = 0xb7fd1aee15822b05
>>     FNV64("12345678abce") = 0xb7fd1aee15822b04
>> 
>> On the other hand, if we reverse the order of secret and IP address,
>> we get:
>>        FNV64("abcd12345678") = 0x6c1e749e200cc845
>>        FNV64("abce12345678") = 0x5d17f5e450f9a52c
>> 
>> It seems like the FNV function is more sensitive to changes in
>> earlier bytes than to changes in later bytes. So placing the IP
>> address first makes this look more like a hash function. This is not
>> a cryptographic argument, but I believe it should be better to put
>> the IP address first.
> 
> You are using FNV-1 while the recommended version of FNV in
> draft-eastlake-fnv is FNV-1a. Here are the results with FNV-1a:
> 
>     FNV64-1a("12345678abcd") = 0x5a8c6219760802e5
>     FNV64-1a("12345678abce") = 0x5a8c611976080132
> 
> I would agree that putting the IP address first is stronger but it is
> more expensive computationally. With the secret first you can
> pre-compute FNV64(secret) and then use that as the FNV offset when
> calculating the cookie from the IP address (or IP address and Client
> Cookie in the case of the server). However, the savings are small,
> particularly for IPv6 and/or at the server where the Client Cookie is
> also included, so I would be OK with reversing the order.

Even with 1a the “hashes” look disturbingly similar. But the justification makes sense and I don’t see any security issue.

Thanks!

Yoav