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

[Ballot comment]
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/

[Ballot comment]
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

[Ballot comment]
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/ ?

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
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?

[Ballot discuss]
The following points notwithstanding, I'm excited to see this mechanism
get specified and am looking forward to balloting Yes once my concerns
are resolved.  Thank you for writing this document (and implementing it,
etc.)!

There seems to be an internal inconsistency in the normative guidance
for how long a given cookie value should be accepted.  Section 4.3 says
that "[t]he DNS Server SHOULD allow Cookies within 1 hour period in the
past and 5 minutes into the future to allow operation of low volume
clients and some limited time skew between the DNS servers in the
anycast set" (before going on to recommend that the server generates a
new cookie if it receives one from the client that is more than half an
hour old).  In contrast, Section 5 says "[t]he operator SHOULD wait at
least longer than the period clients are allowed to use the same Server
Cookie, which SHOULD be half an hour, see Section 4.3".  If I'm reading
correctly the "1 hour" in Section 4.3 is supposed to line up with the
"half an hour" in Section 5, but does not.

Also, as was mentioned in the secdir review thread, I think we should
clearly state what properties we require of a MAC in order to be a
useful server cookie (including why the chosen inputs are the right
thing to MAC!)  That is, what message is being authenticated, and why is
that a useful message to authenticate?

I will also take this opportunity to consult the CFRG on the suitability
of SipHash-2-4 for its stated purpose, though I do not feel a strong
need to delay IESG approval of this document until a positive answer is
received.

[Ballot comment]
Abstract

This seems quite long for an Abstract!  I suspect that everything after
the first paragraph could be consolidated into a single second
paragraph, if desired.

Section 1

  attackers.  This document specifies a means of producing
  interoperable strong cookies so that an anycast server set including
  diverse implementations can be easily configured to interoperate with
  standard clients.

While the need for a precise and interoperable specification is clear in
this case of diverse implementations backing a single anycast service,
isn't there also some benefit in having a well-studied algorithm even
for use within a single implementation or non-anycast service?

Section 3

While I recognize that (UDP) DNS packets do feel some need to economize
on space, I also feel that we should consider what role the client
cookie is playing as a nonce and how much randomness is needed in order
for it to succeed in that role.  In particular, in some sense it is
*not* being used as a cryptographic nonce, but rather an ephemeral
opaque identifier for a given client+IP address, that should be
unguessable.  Specifically, the client cookie can be used for more than
one cryptographic operation, as it is re-used when the server generates
a new "fresh" cookie.  So I would suggest rewording to not call this a
'nonce'.  That notwithstanding, my generic advice for random nonces is
to use at least 128 bits if you want to not think about it much
(https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html
apparently suggests 256-bit, though that's just a link I happened to see
recently on some other list), and I feel that there is a need to include
reasoning to justify the choice of any smaller nonce in terms of what
properties the nonce needs to provide and how they are achieved within
the target security margin.  In this case (IIUC) we are a bit
constrained by the size of the client cookie being a protocol constant,
but we can still provide some analysis of what properties we are able to
provide within that constraint.

  One way to track Client IP addresses, is to register the Client IP
  address alongside the Server Cookie when it receives the Server
  Cookie.  In subsequent queries to the Server with that Server Cookie,

nit/editorial: given the previous mention of "tracking" as being a bad
thing done by external observers, the transition to this topic is a bit
rough.  I'd consider something like "One way to satisfy this requirement
for non-re-use is to register [...]", for a smoother transition.

  the socket MAY be bound to the Client IP address that was also used
  (and registered) when it received the Server Cookie.  Failure to bind

(Does this "MAY" flow well with "one way to"?)

Section 4

  The Server Cookie is effectively a Message Authentication Code (MAC)
  and should be treated as such.  The Server Cookie is calculated from
  the Client Cookie, a series of Sub-Fields specified below, the Client
  IP address, and a Server Secret known only to the servers responding
  on the same address in an anycast set.

(Is it conventional to think of a single server as being "the one and
only server in a degenerate anycast set", or would we consider adding a
clarification that it remains secret to the server in the single-server
case?)

Section 4.3

  The Timestamp value prevents Replay Attacks and MUST be checked by
  the server to be within a defined period of time.  The DNS Server
  SHOULD allow Cookies within 1 hour period in the past and 5 minutes
  into the future to allow operation of low volume clients and some
  limited time skew between the DNS servers in the anycast set.

FWIW we hardcoded 5 minutes of skew into Kerberos but the current
thinking is that that's way too much.  A modern performant server should
have no trouble getting accurate time to within a few seconds, is my
understanding.

  The DNS Server SHOULD generate a new Server Cookie at least if the
  received Server Cookie from the Client is more than half an hour old.

Presumably it also MAY generate a new cookie more often than that?

Section 4.4

I recognize that the stakes here are relatively small, but I don't think
that should excuse us from adhering to general cryptographic best
practices and ensuring that the mapping from protocol parameters to the
byte string input to the hash (MAC) function is an injective mapping.
(See https://tools.ietf.org/html/rfc5116#section-3.3 for some discussion
in a similar context.)  IIUC the client cookie is fixed length by
protocol, so it and the version/reserved/timestamp are fixed-width, thus
injective by default.  However, the length of the Client-IP can vary
based on address family, so either a length prefix or address-family
indicator might be in order (though the overall length of the input is
probably enough to differentiate between the two cases for address
family).
And SipHash is inherently immune to length-extension attacks, hooray.

This would probably be a good section to put the analysis of what
properties are needed from the hash/MAC and how SipHash meets them (per
the secdir review thread), if we don't want to put it in the toplevel
Section 4.

Section 5

  All servers in an anycast set must be able to verify the Server
  Cookies constructed by all other servers in that anycast set at all
  times.  Therefore it is vital that the Server Secret is shared among
  all servers before it is used to generate Server Cookies.

(editorial) I suggest "before it is used to generate Server Cookies on
any server".

  Stage 3  This stage is initiated by the operator when it can be
      assumed that most clients have learned the new Server Secret.

Clients never learn the Server Secret itself!
This should presumably be "most clients have obtained a Server Cookie
derived from the new Server Secret".

Section 6

  [SipHash-2.4] is a pseudorandom function suitable as Message
  Authentication Code.  This document REQUIRES compliant DNS Server to
  use SipHash-2.4 as a mandatory and default algorithm for DNS Cookies
  to ensure interoperability between the DNS Implementations.

(Where does the "SipHash-2.4" notation originate from?  The original
paper at https://www.aumasson.jp/siphash/siphash.pdf seems to use the
"SipHash-2-4" notation.)

Section 8

  DNS traffic.  An on-path adversary that can observe a Server Cookie
  for a client and server interaction, can use that Server Cookie for
  amplification and denial-of-service forgery attacks for the lifetime
  of the Server Cookie.

Such an adversary is limited to using that cookie for attacks directed
against the client associated with the cookie, though, right?

  Unfortunately, tracking Client IP Address Changes is impractical with
  servers that do not support DNS Cookies.  To prevent tracking of
  clients with non DNS Cookie supporting servers, a client MUST NOT
  send a previously sent Client Cookie.  [...]

I think there's a missing qualifier here, like "to a server not known to
support the cookie mechanism" or "in the absence of an associated server
cookie" or similar.  A blanket prohibition on sending previously sent
client cookies would seem to render the cookie mechanism entirely
unusable...

  Summarizing:

  *  In order to provide minimal authentication, a client MUST use a
      different Client Cookie for each different Server IP Address.

(This is only "summarizing" if the RFC 7873 discussion is considered to
be a previous mention.)  Even RFC 7873 doesn't seem to discuss in much
detail *why* this is the case.  IIUC the risk is that in sending a
client cookie to a third-party server, that third party could send that
cookie as a client cookie to the target server and potentially get back
the same server cookie as is used between the primary client/server,
thus gaining the ability to spoof responses as if they were the primary
server.  Should we lay this scenario out in more detail?  ("No" is
probably an okay answer, though I'm not 100% convinced yet.)

  *  To prevent tracking of clients for a non DNS Cookie supporting
      server, a client MUST NOT send a previously sent Client Cookie to
      that server, unless it can track Client IP Address changes for
      those servers too.

I don't think we should have two "MUST NOT" statements covering the same
topic but with slightly different caveats -- it sets up the risk of skew
between directives and consequent internal inconsistency.  I prefer one
of my formulations suggested above, though they are of course not the
only way to resolve the potential issue.

  Besides the Client Cookie construction, this update on [RFC7873] does
  not introduce any new characteristics to DNS Cookies operations and
  the Security Considerations section of [RFC7873] still applies.

We also have the new Server Cookie construction, that by design includes
some defined fields in cleartext.  Some discussion of the associated
considerations, or why there are no considerations, seems in order.

Section 10

Following the reference for [SipHash-2.4] suggests that
https://www.aumasson.jp/siphash/ might be a more targeted URL than the
current one (that redirects to the only the root path of the
www.aumasson.jp site).

Appendix A.4

I guess the timestamp should in theory be recoverable from the listed
cookie value, though maybe it is helpful to say it in a more
human-readable form as well.

[Ballot comment]
[ 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"

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dnsop-server-cookies-04. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

A new registry is to be created calle the DNS Server Cookie Methods registry. The new registry will be located on the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/

IANA Question --> It seems that for every value (version) there are different bit size assignments. We understand the expert will be determining these values, however are there any specific instructions regarding the size assignments that should be included in the document?

The new registry has values from 0 to 255 and will be managed through Expert Review as defined by RFC 8126. There are initial registrations in the new registry as follows:

+=========+=======+=======================================+
| Version | Size | Method | Reference |
+=========+=======+=============+=========================+
| 0 | 8-32 | reserved | |
+---------+-------+-------------+-------------------------+
| 1 | 8-15 | unassigned | |
+---------+-------+-------------+-------------------------+
| 1 | 16 | SipHash-2. | [ RFC-to-be; Section 4 ]|
+---------+-------+-------------+-------------------------+
| 1 | 17-32 | unassigned | |
+---------+-------+-------------+-------------------------+
| 2-239 | 8-32 | unassigned | |
+---------+-------+-------------+-------------------------+
| 240-254 | 8-32 | private use | |
+---------+-------+-------------+-------------------------+
| 255 | 8-32 | reserved | |
+---------+-------+---------------------------------------+

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-12-04):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, warren@kumari.net, dnsop@ietf.org, tjw.ietf@gmail.com, draft-ietf-dnsop-server-cookies@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Interoperable Domain Name System (DNS) Server Cookies) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Interoperable Domain Name
System (DNS) Server Cookies'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-12-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 denial-of-service and
  amplification, forgery, or cache poisoning attacks by off-path
  attackers.

  This document provides precise directions for creating Server Cookies
  so that an anycast server set including diverse implementations will
  interoperate with standard clients.

  This document updates [RFC7873] with

  *  suggestions for constructing Client Cookies in a privacy
      preserving fashion,

  *  precise instructions for constructing Server Cookies deprecating
      the methods described in [RFC7873], 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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/



No IPR declarations have been submitted directly on this I-D.

(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

DNS cookies, as specified in RFC 7873, are a lightweight DNS
transaction security mechanism. This document provides precise
directions for creating Server Cookies so that an anycast server
set including diverse implementations will interoperate with standard
clients.

Working Group Summary:

There were several discussions during the working group process,
but they were all resolved.


Document Quality:

The document was the result of different interpertations of the original
RFC that cause some implementation issues.  Appendix C points out there are
several implementations that interact successfully.

Document Shepherd:  Tim Wicinski
Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This document will update RFC7873, and it is in the abstract and the
introduction.

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section are accurate

(18) There is one IANA registry created:  "Domain Name System (DNS) Parameters"
Additions to this registry is done by Expert Review.  The document shepherd is
comfortable with this.

(19) N/A

(20) No Yang Necessary

https://raw.githubusercontent.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/master/draft-ietf-dnsop-server-cookies-04.txt

(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

DNS cookies, as specified in RFC 7873, are a lightweight DNS
transaction security mechanism. This document provides precise
directions for creating Server Cookies so that an anycast server
set including diverse implementations will interoperate with standard
clients.

Working Group Summary:

There were several discussions during the working group process,
but they were all resolved.


Document Quality:

The document was the result of different interpertations of the original
RFC that cause some implementation issues.  Appendix C points out there are
several implementations that interact successfully.

Document Shepherd:  Tim Wicinski
Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This document will update RFC7873, and it is in the abstract and the
introduction.

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section are accurate

(18) There is one IANA registry created:  "Domain Name System (DNS) Parameters"
Additions to this registry is done by Expert Review.  The document shepherd is
comfortable with this.

(19) N/A

(20) No Yang Necessary

https://raw.githubusercontent.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/master/draft-ietf-dnsop-server-cookies-04.txt

(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

DNS cookies, as specified in RFC 7873, are a lightweight DNS
transaction security mechanism. This document provides precise
directions for creating Server Cookies so that an anycast server
set including diverse implementations will interoperate with standard
clients.

Working Group Summary:

There were several discussions during the working group process,
but they were all resolved.


Document Quality:

The document was the result of different interpertations of the original
RFC that cause some implementation issues.  Appendix C points out there are
several implementations that interact successfully.

Document Shepherd:  Tim Wicinski
Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are no downward normative references

(16) This document will update RFC7873, and it is in the abstract and the
introduction.

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section are accurate

(18) There is one IANA registry created:  "Domain Name System (DNS) Parameters"
Additions to this registry is done by Expert Review.  The document shepherd is
comfortable with this.

(19) N/A

(20) No Yang Necessary