Telechat Review of draft-ietf-dnsop-cookies-08
review-ietf-dnsop-cookies-08-secdir-telechat-nir-2016-01-21-00

Version -09 looks good to me.

I still think they’re over-emphasizing how much this mechanism is weak, but
this is style, not substance.

Yoav

> On 8 Dec 2015, at 8:52 AM, Yoav Nir <ynir.ietf at gmail.com> 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. > > 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.
> > 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. > > 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. > > 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. > > > 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/ > > 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. > > I think it should be mentioned that the
cookie mechanism is stateless. 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*. > > 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. >