Subject: [DNSOP] Seeking more WG Last Call review for draft-ietf-dnsop-cookies

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 16 Jul 2015 12:52:37 -0700

<secretary-hat on>

Greetings. The WG Last Call for draft-ietf-dnsop-cookies was supposed to 
end today, but it got extremely little review during the Last Call. It 
would be helpful to all of us if more people can review the document, 
say what they do or don't like about it, and so on.

--Paul Hoffman

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 16 Jul 2015 22:24:01 +0200

If there is extension on last call, I would like to be volunteer  reviewer
the document.
Best,
Hosnieh

> -----Original Message-----
> From: DNSOP [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Thursday, July 16, 2015 9:53 PM
> To: dnsop WG
> Subject: [DNSOP] Seeking more WG Last Call review for draft-ietf-dnsop-
> cookies
> 
> <secretary-hat on>
> 
end
> today, but it got extremely little review during the Last Call. It would
be helpful
> to all of us if more people can review the document, say what they do or
don't
> like about it, and so on.
> 
> --Paul Hoffman
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Francis Dupont <[email-masked]>
Date: Mon, 20 Jul 2015 13:24:03 +0200

Here is a short review of draft-ietf-dnsop-cookies-04.txt. Note I was
heavily involved into the "SIT" experiment (SIT was a scaled down
version of the DNS cookie idea provided by bind9 version 9.9) so
you should not surprise I like the DNS cookie.

I have two comments about the current text which applied to SIT and
still apply to the "full" DNS cookie.

First the critical security property provided by SIT/DNS cookie is the
"return routability". This explains why it is not efficient against
on-path attackers, and very efficient against DDoS/amplification attacks
using fake source addresses. BTW as the current defense against DDoS/
amplificattion, the response-rate limitation, is in fact the choice
between dropping the packet on the floor or return a truncated response
to force TCP fallback, it is very fine to have another solution!

The second comment is about the algorithm used by the server to compute
the (state) cookie. It is left undefined and in fact you can use what
you want if it provides the required properties (typically the secret
is not easy to guess) and all equivalent servers (e.g., anycasted or
load-balanced) use the same parameters (i.e., same algo and secret).
Nevertheless when HMAC-SHAxxx is a good algorithm there are significantly
faster alternatives, for instance based on AES (thanks to Russ Housley
for the idea).

Regards

[email-masked]

PS: Acknowledgements -> Acknowledgments in US English. There is coookie too.