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?
Thanks!
Changes
=======
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
wrap-arounds.
* 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 \
attacks.
* 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
fashion/
* 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
Cheers,
-- Willem
Op 13-01-2021 om 15:33 schreef [email protected]:
>
> 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:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-server-cookies-05.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-server-cookies-05
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
