Re: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-05.txt

Willem Toorop <> Wed, 13 January 2021 19:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C70AF3A129C; Wed, 13 Jan 2021 11:05:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id De8CxfKoBB09; Wed, 13 Jan 2021 11:05:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 720ED3A1298; Wed, 13 Jan 2021 11:05:05 -0800 (PST)
Received: from (unknown []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 891606028A; Wed, 13 Jan 2021 19:05:00 +0000 (UTC)
Received: from ( []) by
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=soverin; t=1610564699; bh=Mxe129hQJFv+sChVkhMd+7WcVF4/V8UmokJVa5TkIYQ=; h=To:References:Cc:From:Subject:Date:In-Reply-To:From; b=ZwUpnUGeh16d090UfPInzS6NTg7AcjhLP5kPHoOTTRFe4LcEno6kifdOoeikLDMS1 qPAqa3qx403xOc7Ck87a0Aw7mhNUbHLhQOrlgXHJgta+DOHxXplTnWYt68Zc8dOoKF 5FBGNiZVhDfqpc6A+yIoLN5cj6wmwxq43ijAx0bidX8YUy8byBB3ZYUC6UTPCCkGIN xZBqnjufDYKjYV303NebtPGREVsQdMCBPDPuEe3B18mUrthfl7x7CbYZriCrQEEhkF c3R75eFM26LJD6fYVdYfcEjrE9nNCd0CNzKh+HTjibaQqkqUd8ftsV4iNLG3dRE2fx sSALrPVAqAZ8w==
To:,, The IESG <>
References: <>
Cc: Tim Wicinski <>, Stephen Farrell <>, Benjamin Kaduk <>
From: Willem Toorop <>
Message-ID: <>
Date: Wed, 13 Jan 2021 20:04:56 +0100
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Jan 2021 19:05:09 -0000

Dear DNSOP, Stephen and Benjamin,

After IESG evaluation it was decided that we needed to post a revised
version of the DNS Server Cookies draft, with the DISCUSS position
resolved. Also SECDIR review had a "Has Issues" result.
This is that revised version.

To resolve the SECDIR review issues and DISCUSS positions, this version
has timing recommendations in section 4.3 and section 5 aligned, and has
more/better text on the properties and requirements of the Server Cookie
and the pseudorandom function used in its calculation. The document also
has extra text around timestamp compares.

Besides these blocking issues IESG provided a *lot* of COMMENTs and
suggestions which we have (almost) all addressed. Below I have included
a log of those changes.

Stephen and Benjamin, could you please review and see if your Issues and
DISCUSS positions are resolved, and if so, change those statuses?

Comments from Stephen Farrell:

  * Remove "strong" in "strong cookie" in section 1
  * Point out more explicitly the Timestamp field is **unsigned** and
    tell RFC1982 handles difference in the future even in case of
  * Use an authoritative citation for SipHash-2-4

Comments from Benjamin Kaduk:

  * Fix timing inconsistency of section 4.3 and section 5
  * Motivate the use of SipHash-2-4 as pseudorandom function
  * Consolidate everything after the first paragraph in the Abstract
    into a single second paragraph
  * Single implementation no anycast services also benefit for a well-
    studies algorithm
  * Avoid the word 'nonce' with Client Cookies
  * Language style improvements in "tracking of Client Cookies
    prevention" description
  * Make the single server case more explicit in Server Cookie
    construction description
  * A DNS Server MAY generate a new Server Cookie more often than every
    half hour
  * Length verification of Server Cookies so byte string input into
    SipHash-2-4 is injective and not susceptible to data substitution \
  * Explain how different Client Cookie for each server provides minimal
    authentication (in Section 3)
  * Provide Security Considerations for Server Cookies
  * Mention Timestamp values in test vector examples
  * Miscellaneous other minor editorial suggestions

Comments from Erik Kline:

  * Section 1: s/in a Client protecting fashion/in a privacy protecting
  * Section 8: s/five minute/five minutes/
  * Mention that "tracking of the public IP of a NAT" is beyond the
    scope of this document

Comments from Roman Danyliw:

  * Use an authoritative citation for SipHash-2-4
  * Be clear on the notation of SipHash-2-4 (with dashes)

Comments from Murray Kucherawy:

  * Fix linebreaks in section 7
  * Remove Section 1.1 "Contents of this document"

Comments from Barry Leiba:

  * Suggest implementation-defined period of time to renew Client Cookie
    (with one year as the maximum limit)
  * Implementations MUST set reserved bits to 0 when constructing a
    cookie (but not when verifying!)

Comments from Éric Vyncke:

  * Fix capitalization of "client" and "server"
  * More consistent summary of the types of attacks
  * Mention that "tracking of the public IP of a NAT" is beyond the
    scope of this document

Comments from Robert Wilton:

  * Suggest implementation-defined period of time to renew Client Cookie
    (with one year as the maximum limit)
  * Repeat that "Changing the Server Secret regularly is RECOMMENDED" in
    Section 5

-- Willem

Op 13-01-2021 om 15:33 schreef
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
>         Title           : Interoperable Domain Name System (DNS) Server Cookies
>         Authors         : Ondrej Sury
>                           Willem Toorop
>                           Donald E. Eastlake 3rd
>                           Mark Andrews
> 	Filename        : draft-ietf-dnsop-server-cookies-05.txt
> 	Pages           : 18
> 	Date            : 2021-01-13
> Abstract:
>    DNS Cookies, as specified in [RFC7873], are a lightweight DNS
>    transaction security mechanism that provide limited protection to DNS
>    servers and clients against a variety of amplification denial of
>    service, forgery, or cache poisoning attacks by off-path attackers.
>    This document updates [RFC7873] with precise directions for creating
>    Server Cookies so that an anycast server set including diverse
>    implementations will interoperate with standard clients, suggestions
>    for constructing Client Cookies in a privacy preserving fashion, and
>    suggestions on how to update a Server Secret.  An IANA registry
>    listing the methods and associated pseudo random function suitable
>    for creating DNS Server Cookies is created, with the method described
>    in this document as the first and as of yet only entry.
> The IETF datatracker status page for this draft is:
> There is also an HTML version available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> DNSOP mailing list