On Tue, Mar 12, 2019 at 7:29 AM Willem Toorop <[email protected]> wrote:
> 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 protected] > To: Willem Toorop <[email protected]>, Ondrej Sury <[email protected]> > > > 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] > 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
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
