[CFRG] SipHash recommendation?

Benjamin Kaduk <kaduk@mit.edu> Wed, 16 December 2020 00:02 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5B23A0940 for <cfrg@ietfa.amsl.com>; Tue, 15 Dec 2020 16:02:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jh_bPgHoZmFN for <cfrg@ietfa.amsl.com>; Tue, 15 Dec 2020 16:02:37 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEEAF3A091C for <cfrg@ietf.org>; Tue, 15 Dec 2020 16:02:36 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BG02UZd026187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <cfrg@ietf.org>; Tue, 15 Dec 2020 19:02:35 -0500
Date: Tue, 15 Dec 2020 16:02:29 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: cfrg@ietf.org
Message-ID: <20201216000229.GG64351@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/iiyu_IpwpO9OZIqJMPBSCLs1WHc>
Subject: [CFRG] SipHash recommendation?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Dec 2020 00:02:39 -0000

Hi all,

We have a document (draft-ietf-dnsop-server-cookies) in front of the IESG
that proposes to use the SipHash-2-4 algorithm
(https://www.aumasson.jp/siphash/,
https://www.aumasson.jp/siphash/siphash.pdf) as a MAC over what is in some
sense a return-routability and freshness token, the "DNS cookie" originally
specified in RFC 7873.

Unfortunately, the authors of this draft have not yet written down a clear
description of what properties they believe are needed from this MAC for
this usage, which makes it slightly hard to confirm that SipHash is a
suitable algorithm for this purpose, though that is certainly a question
that I am interested in.

Regardless of that, I would also like to get the CFRG's input on whether
SipHash is a suitable algorithm for its stated goals (paraphrasing
slightly): a performant keyed (family of) PRF suitable for use as a MAC,
with the security goal for a MAC being considered to be that an attacker,
even after seeing tags for many messages (perhaps selected by the
attacker), is unable to guess tags for any other messages.

In short: is SipHash fit for this purpose?

There does seem to be a decent amount of literature analyzing SipHash, but
I have not attempted to review it to any significant degree.

Thanks,

Ben