Subject: [DNSOP] Fwd: New Version Notification for draft-sury-toorop-dns-cookies-algorithms-00.txt

From: Willem Toorop <[email-masked]>
Date: Tue, 12 Mar 2019 12:29:13 +0100

Dear DNSOP,

A new draft has been submitted addressing the issue of DNS Cookies in
multi-vendor anycast deployments.

DNS Cookies are currently impractical in such deployments, because one
implementation - even though it shares its secret with another
implementation - cannot validate the Server Cookies constructed by that
other implementation, because their methods for constructing Server
Cookies differ.

This draft provides precise directions for creating Server Cookies to
align the implementations.  In doing so, this draft introduces a
registry for functions suitable for Cookie construction.  More
specifically, FNV and HMAC-SHA-256-64 are obsoleted and SipHash-2.4 is
introduced as a suitable function.

Willem

-------- Forwarded Message --------
Subject: New Version Notification for
draft-sury-toorop-dns-cookies-algorithms-00.txt
Date: Mon, 11 Mar 2019 09:12:24 -0700
From: [email-masked]
To: Willem Toorop <[email-masked]>, Ondrej Sury <[email-masked]>

A new version of I-D, draft-sury-toorop-dns-cookies-algorithms-00.txt
has been successfully submitted by Willem Toorop and posted to the
IETF repository.

Name:		draft-sury-toorop-dns-cookies-algorithms
Revision:	00
Title:		Algorithms for Domain Name System (DNS) Cookies construction
Document date:	2019-03-11
Group:		Individual Submission
Pages:		7
URL:
https://www.ietf.org/internet-drafts/draft-sury-toorop-dns-cookies-algorithms-00.txt
Status:
https://datatracker.ietf.org/doc/draft-sury-toorop-dns-cookies-algorithms/
Htmlized:
https://tools.ietf.org/html/draft-sury-toorop-dns-cookies-algorithms-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-sury-toorop-dns-cookies-algorithms

Abstract:
   [RFC7873] left the construction of Server Cookies to the discretion
   of the DNS Server (implementer) which has resulted in a gallimaufry
   of different implementations.  As a result, DNS Cookies are
   impractical to deploy on multi-vendor anycast networks, because the
   Server Cookie constructed by one implementation cannot be validated
   by another.

   This document provides precise directions for creating Server Cookies
   to address this issue.  Furthermore, [FNV] is obsoleted as a suitable
   Hash function for calculating DNS Cookies.  [SipHash-2.4] is
   introduced as a new REQUIRED Hash function for calculating DNS
   Cookies.

   This document updates [RFC7873]

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Bob Harold <[email-masked]>
Date: Thu, 14 Mar 2019 10:21:04 -0400

>    This document updates [RFC7873]

This document looks useful, but I have a concern:

2. Constructing a Client Cookie

"If a secure pseudorandom
function (like SipHash24) is used there's no need to change Client
secret periodically and change the Client secret only if it has been
compromised."

3. Constructing a Server Cookie

"The Server Cookie is not required to be changed periodically if a
secure pseudorandom function is used."

I am not a cryptography expert, but the above sounds like the Client secret
and Server Cookie could be left forever without changing them, which seems
like a bad idea. And how would one know "if it has been compromised"?
Please explain.

I you meant "change every few years instead of hourly", then please say
that.

-- 
Bob Harold