Subject: [secdir] Secdir last call review of draft-ietf-dnsop-server-cookies-04

From: Stephen Farrell via Datatracker <[email-masked]>
Date: Wed, 02 Dec 2020 09:46:58 -0800

Reviewer: Stephen Farrell
Review result: Has Issues

I see two issues here worth checking:

1. I don't recall SipHash being used as a MAC in
any IETF standard before. We normally use HMAC,
even if truncated. Why make this change and was
that checked with e.g. CFRG? (And the URL given
in the reference gets me a 404.)

2. Is it really a good idea to use a 32 bit seconds
since 1970-01-01 in 2020? I'd have thought that e.g.
a timestamp in hours since then or seconds since
some date in 2020 would be better.

Here's a couple of nits too:
- section 1: what's a "strong cookie"?
- "gallimaufry" - cute! but not sure it'll help readers to learn that word.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 2 Dec 2020 19:25:58 +0100

Stephen,

ad 1) the performance is crucial for DNS over UDP and PRF such as SipHash is more efficient than HMACs. No, it wasn’t consulted with CFRG, and I can’t speak for Willem, but I am confident enough to make the decision. SipHash is widely used for hash tables virtually anywhere now.

ad 2) we need a value that’s synchronized well enough and monotonic. I honestly don’t see any value in using 64-bit value here. Using unixtime has a value in itself, it’s a well-known and there’s a little room for any implementor to make a mistake in an implementation. The interoperability is more important than the actual value of the counter. It’s write only counter, nobody is going to interpret it after it has been generated, and it’s wide enough to prevent brute forcing.

Cheers,
Ondřej
--
Ondřej Surý — ISC (He/Him)

> On 2. 12. 2020, at 18:47, Stephen Farrell via Datatracker <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Dec 2020 20:37:57 +0000

Hiya,

On 02/12/2020 18:25, Ondřej Surý wrote:
> Stephen,
> 
> ad 1) the performance is crucial for DNS over UDP and PRF such as
> SipHash is more efficient than HMACs. No, it wasn’t consulted with
> CFRG, and I can’t speak for Willem, but I am confident enough to make
> the decision. SipHash is widely used for hash tables virtually
> anywhere now.

The text says that you need a MAC though. Personally, I
think it'd be wiser to (double-)check before using novel
crypto even if the only novelty is use in a standards
track RFC.

> 
> ad 2) we need a value that’s synchronized well enough and monotonic.
> I honestly don’t see any value in using 64-bit value here. Using
> unixtime has a value in itself, it’s a well-known and there’s a
> little room for any implementor to make a mistake in an
> implementation. The interoperability is more important than the
> actual value of the counter. It’s write only counter, nobody is going
> to interpret it after it has been generated, and it’s wide enough to
> prevent brute forcing.

So what happens after 2038? That's really not v. far in the
future any more.

Cheers,
S.

> 
> Cheers, Ondřej -- Ondřej Surý — ISC (He/Him)
> 
>> Reviewer: Stephen Farrell Review result: Has Issues
>> 
>> 1. I don't recall SipHash being used as a MAC in any IETF standard
>> before. We normally use HMAC, even if truncated. Why make this
>> change and was that checked with e.g. CFRG? (And the URL given in
>> the reference gets me a 404.)
>> 
>> 2. Is it really a good idea to use a 32 bit seconds since
>> 1970-01-01 in 2020? I'd have thought that e.g. a timestamp in hours
>> since then or seconds since some date in 2020 would be better.
>> 
>> Here's a couple of nits too: - section 1: what's a "strong
>> cookie"? - "gallimaufry" - cute! but not sure it'll help readers to
>> learn that word.
>> 
>> 
>> 
>> 
> 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Dec 2020 13:15:49 -0800

On Wed, Dec 2, 2020 at 10:32 AM Ondřej Surý <[email-masked]> wrote:

> Stephen,
>
> ad 1) the performance is crucial for DNS over UDP and PRF such as SipHash
> is more efficient than HMACs. No, it wasn’t consulted with CFRG, and I
> can’t speak for Willem, but I am confident enough to make the decision.
> SipHash is widely used for hash tables virtually anywhere now.
>

Well hash tables are an application with somewhat different security
properties than MACs, so I don't think this is dispositive.

I concur with Stephen that CFRG should sign off on the use of SipHash here.
With that said, how does SipHash compare to GMAC in terms of performance?

-Ekr

> ad 2) we need a value that’s synchronized well enough and monotonic. I
> honestly don’t see any value in using 64-bit value here. Using unixtime has
> a value in itself, it’s a well-known and there’s a little room for any
> implementor to make a mistake in an implementation. The interoperability is
> more important than the actual value of the counter. It’s write only
> counter, nobody is going to interpret it after it has been generated, and
> it’s wide enough to prevent brute forcing.
>
> Cheers,
> Ondřej
> --
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>

---

From: Willem Toorop <[email-masked]>
Date: Wed, 2 Dec 2020 22:38:22 +0100

Op 02-12-2020 om 21:37 schreef Stephen Farrell:

<snip>

>> little room for any implementer to make a mistake in an

The draft states that `All comparisons involving these fields MUST
use "Serial number arithmetic", as defined in [RFC1982]'. So it can not
be used to compare differences larger than 68 years, but comparisons of
cookie timestamps are more in the "hours" order of magnitude.

Cheers,
-- Willem

> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Dec 2020 21:49:15 +0000

Hiya,

> cookie timestamps are more in the "hours" order of magnitude.

Sorry for being dim, but is clear what value to put
in those 4 octets in say 2039 such that different
implementations will do the right thing? I did glance
at rfc1982, so there may be very far-sighted text
in there that I missed:-) And it may even be fine
for this purpose if different servers differ by a
second or so at that point, but even if so, it may
be a bad plan to leave that unspecified in case
other timestamps use the same code.

Cheers,
S.

---

From: Willem Toorop <[email-masked]>
Date: Wed, 2 Dec 2020 23:07:40 +0100

Op 02-12-2020 om 22:49 schreef Stephen Farrell:
> implementations will do the right thing
Well the text does specify an "32-bit unsigned number of seconds elapsed
since 1 January 1970 00:00:00 UTC", so because of the "unsigned" the
wrap to 0 is only in 2106, not 2038.

But even then, in 2106, it should not be a problem to check the age of a
cookie because of the rfc1982 comparison (which takes care of the wrap)
and the fact that Server Cookies will not be older than hours (and not
years).

Cheers,
-- Willem

> I did glance

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 2 Dec 2020 23:18:29 +0100

SYN cookies in both Linux and FreeBSD uses siphash.

* FreeBSD: https://svnweb.freebsd.org/base?view=revision&revision=253210 (since 2013)
* Linux: https://github.com/torvalds/linux/commit/fe62d05b295bde037fa324767674540907c89362#diff-14feef60c3dbcf67539f089de04546c907233cbae09e1b2dd2c2bc6d6eae4416 (since 2017)

I believe that the SYN cookies have exactly the same properties as DNS cookies.

Ondrej
--
Ondřej Surý (He/Him)
[email-masked]

> On 2. 12. 2020, at 22:15, Eric Rescorla <[email-masked]> wrote:
> 
> Well hash tables are an application with somewhat different security properties than MACs, so I don't think this is dispositive.
>

---

From: Brian Dickson <[email-masked]>
Date: Wed, 2 Dec 2020 14:25:29 -0800

> other timestamps use the same code.

The reference to RFC1982 pretty much implies use of modulo arithmetic.
Maybe it would help to spell it out?
(Basically, calculate seconds since Jan 1 1970 at 0000 UTC, and if the
value is > 2^32, take the remainder mod 2^32.)

The RFC1982 specifies how the differences should be handled, so regardless
of which one is 0 and which one is 1 (or 2^32 - 1), the difference yielded
is a small number (i.e. 1).

This handles any relative time window less than 68 years, at any time in
the future (2038 or 2106 or 2256 or 22209.)

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Dec 2020 22:31:56 +0000

Hiya,

> wrap to 0 is only in 2106, not 2038.

Ah. I missed that "unsigned." (Does that mean implementers
might also?)

> and the fact that Server Cookies will not be older than hours (and not

So the buggy case would be where a server re-constructs
the input to the hash after some kind of round-trip of
the octets (to e.g. struct tm or something and then back
to time_t and to network byte order) at which point you could
I think get failures depending on who implemented what
incorrectly. That kind of thing has been seen before (even
if it seems a bit mad;-)

FWIW, I'd say it's worth a few more words to try reduce
the probability of such failures happening, e.g. maybe
just highlighting the "unsigned/2106" point you made
above would be enough. But, if the WG don't want to do
that, that's also fine by me.

Cheers,
S.

---

From: Willem Toorop <[email-masked]>
Date: Thu, 3 Dec 2020 15:28:37 +0100

Op 02-12-2020 om 23:31 schreef Stephen Farrell:

<snip>

> that, that's also fine by me.

Sure, NP. I'll include Brian Dicksen's provided clarification in the
text. Also, I approached Jean-Philippe Aumasson and he fixed the url we
used in the draft for SipHash, but recommends to use this one in the future:

https://www.aumasson.jp/siphash/

So I'll change that too.

Cheers,
-- Willem

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Dec 2020 09:39:52 -0800

> https://www.aumasson.jp/siphash/

It seems like kind of a problem to have a normative algorithm reference to
a random personal Website.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 3 Dec 2020 17:50:33 +0000

https://www.aumasson.jp/siphash/<https://urldefense.com/v3/__https:/www.aumasson.jp/siphash/__;!!GjvTz_vk!H9yuV_JGH8WlsgRRRHM2ZK0GjjLwaWYM9A9bC2Fylujljh-wHdJvPqIppeQ4$>

  *   It seems like kind of a problem to have a normative algorithm reference to a random personal Website.

That web page has pointers to papers, perhaps they should be used instead.

Or maybe someone can convince Simon Joseffson to write it up (as he has for many others :)

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Dec 2020 10:28:24 -0800

On Thu, Dec 3, 2020 at 9:52 AM Salz, Rich <rsalz=[email-masked]>
wrote:

> <https://urldefense.com/v3/__https:/www.aumasson.jp/siphash/__;!!GjvTz_vk!H9yuV_JGH8WlsgRRRHM2ZK0GjjLwaWYM9A9bC2Fylujljh-wHdJvPqIppeQ4$>
>
>
>
>    - It seems like kind of a problem to have a normative algorithm
>    reference to a random personal Website.
>
>
>
That might be better. Basically, something that we can have some confidence
will be stable.

> Or maybe someone can convince Simon Joseffson to write it up (as he has

That seems great.

-Ekr

-- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 4 Dec 2020 12:36:35 -0800

Hi Ondřej,

Just because someone else does something, even a "big name", doesn't
necessarily make it a good idea for us to also do it.
We should be able to justify our algorithm choices on cryptographic
principles, not just appeal to authority.

In a similar vein, you said something about the 32-bit timestamp being wide
enough to prevent brute-force attacks.  Could you say a bit more about what
attacks those are that are being prevented?  I'm not really seeing how the
width of the timestamp comes into play for that concern, just from a quick
skim of the document.  (Timestamps tend to not provide much protection
against brute force by themselves, since time is relatively guessable,
especially to seconds precision.)

Thanks,

Ben

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 4 Dec 2020 22:14:29 +0100

Hi Benjamin,

I did not used appeal to authority as an argument, but I’ve just provided examples that SipHash has been implemented in the similar scenarios and there hasn’t been reported issue with the choice for years now.

Using fast PRF (pseudorandom function) for the DNS Cookies is a good choice because it matches the required properties - it needs to be fast and secure in a sense that attacker can’t compute neither the key nor the output of the function. DNS Cookies are not MACs.

Sorry for the misnomer of the brute force - what I meant was a protection against a replay attack. I’m just currently very tired with day to day job.

Please note that DNS Cookies doesn’t protect the actual DNS message payload, it merely provide means to establish trust between the client and the server as to distinguish between a legitimate and spoofed traffic, so different policies can be used - Response Rate Limiting (RRL) could be turned off for DNS messages with cookies or when under attack it could require fallback to TCP for DNS queries without the DNS Cookie. The DNS cookies doesn’t protect the actual content in any way, neither it does protect the communication from the on path adversary.

In that regard, the client cookie is just nonce (and it’s just convenient to use same algorithm to generate it, but it could be output from CSPRNG as well) and the server cookie is a cryptographic primitive that uses the client nonce, key and timestamp to construct the server cookie. Such server cookie is used by the DNS client to authenticate to the server (it’s shared secret, but it requires no per-client state on the server). Just to repeat, the actual payload (DNS message) is not protected by the DNS cookie.

If the DNS server could keep a state for every DNS client, a CS random number would be as good as the output of the SipHash.

I might not be a cryptographer as my daily job, but I am reasonably confident that SipHash has matching properties, it hasn’t been broken as of today. Also all DNS vendors have agreed to make this choice and the RFC here is merely a way how to ensure interoperability between various implementations.

(Typing this on phone, so excuse any irregularities in the text.)
Ondrej
--
Ondřej Surý — ISC (He/Him)

> On 4. 12. 2020, at 21:37, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Ondřej,
>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 4 Dec 2020 13:31:09 -0800

> especially to seconds precision.)

I think the timestamp being used as input to the hash provides a particular
protection to brute forcing.
Since the output (hash) is a function of the input, this means that any
attempt to brute force some other element which is an input to the hash,
will be constrained by an element over which the attacker has no control.

The timestamp is a monotonically increasing (modulo 32) value, which
changes every second.
This places a time window for a brute force attack, to be of a 1 second
duration.
Alternatively, it can be considered as increasing the entropy, meaning the
brute force attempt would need to include all potential values of the
timestamp over the cookie lifetime.
I believe the 30 minutes or 1 hour lifetime adds enough entropy to
significantly increase the work required for a brute force attack.

I don't think the absolute size of the timestamp value (in bits) plays any
part here.

Brian Dickson

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 5 Dec 2020 14:58:10 +0000

There is a fair amount of academic study around SipHash, and while everyone can make mistakes, its creators have a pretty good reputation. I don't think we can say SipHash is unknown in the industry.

The TLSWG made it a practice to ask CFRG to "approve" all crypto it used (except perhapd HKDF, but that's a side note). The DNSOP has no such practice.

If SECDIR or the Ads thinks SipHash isn't good, it would be great to hear reasons.  I haven't heard any yet.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 5 Dec 2020 16:18:27 +0000

Hiya,

On 05/12/2020 14:58, Salz, Rich wrote:
> There is a fair amount of academic study around SipHash, and while
> everyone can make mistakes, its creators have a pretty good
> reputation. I don't think we can say SipHash is unknown in the
> industry.
> 
> The TLSWG made it a practice to ask CFRG to "approve" all crypto it
> used (except perhapd HKDF, but that's a side note). The DNSOP has no
> such practice.

FWIW, I think asking CFRG for comment (not approval) whenever
a new algorithm is introduced onto the standards-track is a
good idea, regardless of the WG from which the draft came.
Such checks don't mean anyone thinks badly of any algorithm,
the argument is it's better to ask a question in the place
where the expertise lies, just in case.

Cheers,
S.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 5 Dec 2020 17:32:35 +0000

I don't disagree, but I CFRG should be asked if they are willing, and if they are, then such a change needs to be socialized.  I am not sure it's fair to hold this draft up.  I mean, it's not like it uses ROT-13.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 5 Dec 2020 10:58:38 -0800

On Sat, Dec 5, 2020 at 6:58 AM Salz, Rich <rsalz=[email-masked]>
wrote:

> everyone can make mistakes, its creators have a pretty good reputation. I
> don't think we can say SipHash is unknown in the industry.
>
> The TLSWG made it a practice to ask CFRG to "approve" all crypto it used
> (except perhapd HKDF, but that's a side note). The DNSOP has no such
> practice.
>

I recognize that this is a bigger issue, but I believe this should be the
practice for the IETF as a whole and I would encourage the SEC ADs to work
to make it so.

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 7 Dec 2020 17:23:32 -0800

Hi Ondřej,

Thanks for this detailed writeup; it really helps bring clarity to the
current situation.

In light of the follow-ups from others, it seems that there are actually
two distinct but somewhat entangled issues:

(1) whether SipHash is a strong cryptographic hash function that delivers
its stated properties.

(2) whether the stated properties of SipHash are appropriate for the
scenario we are using it for in this document.

I had initially assumed that Stephen's review was asking about (2), but for
the most part we tend to ask CFRG about things like (1).  So, while I agree
that it's valuable to get input from the CFRG on (1) and am willing to
start the conversation there if needed, I would also like to get Stephen's
(or anyone else's really) input about question (2).  I suspect that we are
okay in that regard, not least because of the other similar usage that you
describe, but request that the analysis of what properties we need from a
hash function for this use case (and that SipHash meets them) be included
in a future version of the draft.

Thanks again,

Ben

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Dec 2020 14:56:23 +0000

Hiya,

(I wouldn't put that much store on my specific response, but
since you asked...)

> (1) whether SipHash is a strong cryptographic hash function that delivers

Right. And whether there are any oddities, e.g. ways in which
one ought not use the algorithm. Asking about that is IMO a
good plan because once this gets used somewhere it'll be used
again elsewhere so I'd prefer we know if/when that's ok or
not. (Additionally, I'll admit a slight personal bias against
adding new algorithms where we have existing ones that are
fine - I figure that just costs more and damages interop for
little or no benefit. That could be outweighed though if the
new alg is already implemented and deployed for the purpose
in question and/or if it's widely available in libraries.)

> scenario we are using it for in this document.

For DNS cookies, I'd say it'd be very unlikely that this is
not ok.

Cheers,
S.