Subject: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-server-cookies-04: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 16 Dec 2020 23:37:31 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-dnsop-server-cookies-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. There was a clear oversight in
RFC 7873.

Please find below some non-blocking COMMENT points (but replies would be
appreciated), and some nits.

As a side note, mixing "gallimaufry" and "cookies" in the same sentence does
not look good for the "chef" ;-)

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Title --
Is the word "interoperable" in the title really required in a standards track
document, isn't it implied ? Title is "Interoperable Domain Name System (DNS)
Server Cookies" but could simply be "Domain Name System (DNS) Server Cookies"
suggest to add something around "anycast" to differentiate from RFC 7873.

-- Section 3 --
I like that a Client cookie must be changed upon local IP address change but I
am afraid that there is no way to detect that a provider Carrier Grade NAT
(CGN) is using round robin among a pool of public address; this still allows
for client tracking as the client cookie is unchanged even if the public IP
address has changed. Should there be some text around this issue or in the
security section ?

-- Section 4.4 --
Should the "SipHash2.4()" be specified in the text ? E.g., via a reference to
section 6

Should there be a recommended minimum length of the shared secret (or entropy
level) ?

-- Section 6 --
In "This document REQUIRES compliant DNS Server to use SipHash-2.4 as a
mandatory and default algorithm for DNS Cookies", I wonder whether "a mandatory
and default" is required as only one algorithm is specified and there is a
"REQUIRES".

== NITS ==

Is there a reason why "Server" and "Client" are capitalized in the text?

-- Section 1 --
s/denial-of-service and amplification/denial of service, amplification/ ?