Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-server-cookies

[Willem Toorop <[e-mail]>]

Thanks Brian,

All but one nit resolved in these commits:

*
https://github.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/commit/db51181a
*
https://github.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/commit/e1e763e8

For your convenience, a rendered possible future version of the document
with these changes can be viewed here:

*
https://raw.githubusercontent.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/master/draft-ietf-dnsop-server-cookies-04.txt

I've provided a bit more feedback inline below.

Op 10-10-2020 om 23:13 schreef Brian Dickson:
> 
> 
> On Fri, Oct 9, 2020 at 8:38 AM Benno Overeinder <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     This starts a Working Group Last Call for
>     draft-ietf-dnsop-server-cookies.
> 
>     Current versions of the draft is available here:
>     https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/
> 
>     The Current Intended Status of this document is: Standards Track
> 
>     FYI, I will not shepherd this document, as it was written with one
>     of my coworkers.
>     Tim Wicinski will be Document Shepherd.
> 
>     Please review the draft and offer relevant comments.
>     If this does not seem appropriate please speak out.
>     If someone feels the document is *not* ready for publication, please
>     speak out with your reasons.
> 
> 
> I have read the document, and support publication (modulo very minor
> nits that should be fixed).
> 
> In addition to these nits, I do have one further suggestion for Section 8.
> 
> I'm not sure if it is too late to make such a suggestion, but on reading
> (and thinking about) the spec,
> it could be useful guidance (particularly for clients which may not be
> aware of changes to their Client-IP address):
> 
> "o   In order to determine that a Server has detected a change to the
> Client-IP, a Client may consider
>       a BADCOOKIE error sooner than would be expected from a Server
> Cookie refresh as a signal
>       that the Client-IP may have changed, and thus that a new Client
> Cookie should be created for each Server."

This is too late. For privacy reasons, the server should not be able to
discover that the Client-IP changed so it cannot *track* Clients with
the help of a DNS Cookie.  The Client needs to detect source address
changes before it uses it to send out queries.

> 
> Nits:
> Introduction - I believe "provides" should be "provide", to agree with
> the singular "is" of the verb. (Sorry, grammar nit.)
> 
> Section 1.1 - I believe all the "Section Section" instances should
> really just be "Section".
> 
> Section 4 - "too frequent" -> "too frequently". 
> 
> Section 4.3 - "in the anycast." -> "in the anycast set."
> 
> Section 4.4 - hash calculation, end of first line "Client-IP," ->
> "Client-IP |"

(from Wikipedia)
SipHash is not actually a cryptographic hash, bot only suitable as
message authentication code: a keyed hash function like HMAC.

It has the form SipHash(message, key)

Thanks,
-- Willem

> 
> Section 5 - "anycast group" -> "anycast set"; "us used" -> "is used"
> 
> Section 8 - "like for example five minute." -> "for example five minutes."
> 
> Brian
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>