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

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 16 December 2020 00:00 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 160813A091C; Tue, 15 Dec 2020 16:00:43 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw 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: Roman Danyliw <rdd@cert.org>
Message-ID: <160807684262.8322.15298996984520658766@ietfa.amsl.com>
Date: Tue, 15 Dec 2020 16:00:43 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hAEwsaCQnNsjDd156AiDerA9OBM>
Subject: [DNSOP] Roman Danyliw'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: Wed, 16 Dec 2020 00:00:43 -0000

Roman Danyliw 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 to Stephen Farrell for the SECDIR review
(https://mailarchive.ietf.org/arch/msg/secdir/TV4Qw2ionRmJ8skKzgUWzRTeDtw/) and
the discussion around the appropriateness of SipHash, the associated reference
and the arithmetic around the timestamp.   A few comments on this thread
relevant as COMMENTs:

* Please do make clarifying editorial fixes noted here
https://mailarchive.ietf.org/arch/msg/secdir/eGSBMIwkaJjOy9EXtw5lqcgrZRM/

* Thanks for exploring URLs for the normative reference for for SipHash, but
pointing to a personal website is not appropriate (despite it providing a
direct link to the relevant paper).  Please use an authoritative citation in
Section 4.4.  I recommend (something to the effect of):

Aumasson JP., Bernstein D.J. SipHash: A Fast Short-Input PRF. Progress in
Cryptology - INDOCRYPT 2012. Lecture Notes in Computer Science, vol 7668.
Springer.  https://doi.org/10.1007/978-3-642-34931-7_28.

As an aside, while I concur with the sentiment that all crypto algorithms used
in standards track protocols should be reviewed by CRFG
(https://mailarchive.ietf.org/arch/msg/secdir/wZq9M2c3hrd5SpOc1KAM3TuPH0w/) as
a standard practice, this isn’t where we are as a community as of yet.  This
needed review of SipHash can be decoupled from this document. Additionally:

** Please also be clear on the notation that SipHash2.4.  Since the normative
reference uses the notation “SipHash-2-4” (with the dashes), please use that or
provide explicit text to explain it.

** Section 7.  For future agility, should a “recommended” column be
sub-registry just as was added to
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
or is the thinking that there will only be serial updates of the cookie
algorithm where concurrent use is not expected?