[DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-server-cookies-04: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-server-cookies-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/



----------------------------------------------------------------------
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.


----------------------------------------------------------------------
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.