Skip to main content

Interoperable Domain Name System (DNS) Server Cookies
draft-ietf-dnsop-server-cookies-05

Yes

Warren Kumari

No Objection

(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Magnus Westerlund)
(Martin Vigoureux)

Note: This ballot was opened for revision 04 and is now closed.

Erik Kline
Yes
Comment (2020-12-15 for -04) Sent
[ questions ]]

[ section 3 ]

* I assume it's not a big deal that sometimes the client cannot easily
  tell when its upstream IP address has changed (vis. RFC 7873 S6
  considerations)?

  NAT makes it difficult to comply with the MUST for clients stated
  in section 8, but...what should a client do if only has, say, an
  RFC 1918 address and is quite likely to be behind a NAT?  If its
  server is also a likely-NAT'd IP then it might presume no NAT between
  the two, but if the server has a global IP address...I suppose it
  can just rotate the per-server cookies once per year?


[[ nits ]]

[ section 1 ]

* Final sentence of the final paragraph:
  "in a Client protecting fashion" -> 
  "in a privacy protecting fashion"? (to match the abstract)

[ section 8 ]

* "five minute" -> "five minutes"
Warren Kumari
Yes
Murray Kucherawy
No Objection
Comment (2020-12-15 for -04) Sent
I learned the word "gallimaufry" from the Introduction.

I think Section 1.1 is unnecessary, given it mostly re-states the Table of Contents.

In Section 3 there's a line that says "Client-Cookie = 64 bits of entropy" which is both (a) not a sentence, and (b) the same as something said in the first paragraph of this section.  I think it can be removed.

The layout of Section 7 is odd.  It looks like several line breaks got eaten.

Also in Section 7, you're creating a registry with Expert Review, but there's no particular guidance offered to the Designated Expert once one is assigned, as suggested by RFC 8126.  Are we all OK with that?  You might advise, for example, that the registration of a new Method really should have a specification someplace.
Roman Danyliw
No Objection
Comment (2020-12-15 for -04) Sent
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?
Éric Vyncke
No Objection
Comment (2020-12-16 for -04) Sent
Thank you for the work put into this document. There was a clear oversight in RFC 7873.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

As a side note, mixing "gallimaufry" and "cookies" in the same sentence does not look good for the "chef" ;-)

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Title --
Is the word "interoperable" in the title really required in a standards track document, isn't it implied ? Title is "Interoperable Domain Name System (DNS) Server Cookies" but could simply be "Domain Name System (DNS) Server Cookies" suggest to add something around "anycast" to differentiate from RFC 7873.

-- Section 3 --
I like that a Client cookie must be changed upon local IP address change but I am afraid that there is no way to detect that a provider Carrier Grade NAT (CGN) is using round robin among a pool of public address; this still allows for client tracking as the client cookie is unchanged even if the public IP address has changed. Should there be some text around this issue or in the security section ?

-- Section 4.4 --
Should the "SipHash2.4()" be specified in the text ? E.g., via a reference to section 6

Should there be a recommended minimum length of the shared secret (or entropy level) ? 

-- Section 6 --
In "This document REQUIRES compliant DNS Server to use SipHash-2.4 as a mandatory and default algorithm for DNS Cookies", I wonder whether "a mandatory and default" is required as only one algorithm is specified and there is a "REQUIRES".

== NITS ==

Is there a reason why "Server" and "Client" are capitalized in the text?

-- Section 1 --
s/denial-of-service and amplification/denial of service, amplification/ ?
Benjamin Kaduk Former IESG member
(was Discuss) Yes
Yes (2021-01-13) Sent
Thank you very much for the updates in the -06; they
are just what I was hoping for!

I will note a couple nit-level editorial suggestions, though
I am sure the RFC Editor would find them as well.

Section 4

nit: s/Because DNS servers need to calculate/Because DNS servers need to recalculate it/

Section 8.2

nit: s/Portion of the structure/A portion of the structure/
Alissa Cooper Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Barry Leiba Former IESG member
No Objection
No Objection (2020-12-15 for -04) Sent
Thanks for this; very useful.  I have two small points:

— Section 3 —

   It is reasonable to change the
   Client Cookie then only if it has been compromised or after a
   relatively long period of time such as no longer than a year.  Client
   Cookies are not expected to survive a program restart.

Itis anvery small thing, but “a relatively long period of time such as no longer than a year” strikes me as an odd way to put it, and especially so because of the sentence that follows it.  If you’re actually suggesting that a year is a reasonable and likely choice, please say that more clearly.  Otherwise, you might consider suggesting a shorter period as a (lower-case) recommendation, with the year as a maximim... or, alternatively, leave it at the vague “relatively long” with something like, “or after a relatively long implementation-defined period of time.  The time period should be no longer than a year, and in any case Client Cookies are not expected to survive a program restart.”

— Section 4.2 —
Why is it a SHOULD, rather than a MUST, to zero the reserved field?  Why might a server not zero it for good reason?  And wouldn’t it harm future interoperability if implementations don’t, and an extension comes along that uses bits in that field?
Deborah Brungard Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Martin Duke Former IESG member
No Objection
No Objection (2020-12-16 for -04) Sent
It seems to me the mechanisms in Section 5 would be simplified by using some the reserved bit to have an identifier for the secret.
Martin Vigoureux Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2020-12-17 for -04) Sent
Hi,

Thanks for this document, I found it easy to read.  I have a couple of minor questions/comments related to the lifecycles.

Section 3:

   Except for when the Client IP address changes, there is no need to
   change the Client Cookie often.  It is reasonable to change the
   Client Cookie then only if it has been compromised or after a
   relatively long period of time such as no longer than a year.  Client
   Cookies are not expected to survive a program restart.

It isn't clear to me why it is necessary to put an upper bound a on when a client cookie needs to be changed at all.  What is the benefit of changing the client cookie once a year?

5.  Updating the Server Secret

I think that it would be useful to remind the reader that server secrets are expected to be updated on a semi-regular basis, as described in section 4.

Regards,
Rob