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

Éric Vyncke via Datatracker <noreply@ietf.org> Thu, 17 December 2020 07:37 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A16E23A1521; Wed, 16 Dec 2020 23:37:31 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-server-cookies@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, tjw.ietf@gmail.com, tjw.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <160819065136.28993.1105069299288196175@ietfa.amsl.com>
Date: Wed, 16 Dec 2020 23:37:31 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/H4wuJMQpPliEBPp534B_ImsPz-E>
Subject: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-server-cookies-04: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2020 07:37:32 -0000

É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/ ?