Re: [babel] Solving HMAC replay once and for all

Markus Stenberg <markus.stenberg@iki.fi> Thu, 28 June 2018 10:01 UTC

Return-Path: <fingon@kapsi.fi>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E459130F5C for <babel@ietfa.amsl.com>; Thu, 28 Jun 2018 03:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level:
X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kapsi.fi
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 JAJmXmkNp6vf for <babel@ietfa.amsl.com>; Thu, 28 Jun 2018 03:01:39 -0700 (PDT)
Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4C5130EE1 for <babel@ietf.org>; Thu, 28 Jun 2018 03:01:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=2JKXb7xmOLeQwlG3bUoK8v/zRWIrshtyTVIjTw98UrA=; b=XhEJNVPZGQVo1UibnByAo9R6fwfQ5Wt1ysZbOQjX+XWmvsCGMCUhCNv+nNhcSnlOJSeWRkhaIwIkWniYUYm2x0BoBYy6tudEmAq2B1WG6ShFZgAitCM9IPoMdTzH6OKJHuHnRxzWAN978tT6vHjRXSAiqR3lTqa6e8R2r/mxAAMyT+a/JZCQwRcQVB2M2Dt7QJ5rDaeW6O2Iut9elT009cYkpF09dB9Z/XBVdNAga0JmRGkQyauI2YUNRjIycUUaFxyJUEROY1IRMTiVPwjq5hyTDXe7psoTumsPALmKyzy55YDGi55vzWDixYWZSExqamKUShHt5TL6G+ot/Etxwg==;
Received: from [194.100.69.221] (helo=[172.20.21.37]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <markus.stenberg@iki.fi>) id 1fYTk8-00018x-09; Thu, 28 Jun 2018 13:01:36 +0300
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Markus Stenberg <markus.stenberg@iki.fi>
In-Reply-To: <87lgaznt2h.wl-jch@irif.fr>
Date: Thu, 28 Jun 2018 13:01:35 +0300
Cc: David Schinazi <dschinazi@apple.com>, babel@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF2F907B-6B9E-4410-ADCB-0A194FF4B8E2@iki.fi>
References: <87muvgh08w.wl-jch@irif.fr> <B79AE9F0-772A-4068-86CF-942ED6B8C5DF@iki.fi> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <AD5721CC-523E-4582-A612-13464B0F27F6@apple.com> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> <87lgaznt2h.wl-jch@irif.fr>
To: Juliusz Chroboczek <jch@irif.fr>
X-Mailer: Apple Mail (2.3445.8.2)
X-SA-Exim-Connect-IP: 194.100.69.221
X-SA-Exim-Mail-From: markus.stenberg@iki.fi
X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/kzcaIsXGo0NRu5nkchu4BGdD3CA>
Subject: Re: [babel] Solving HMAC replay once and for all
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2018 10:01:44 -0000

On 28 Jun 2018, at 12.44, Juliusz Chroboczek <jch@irif.fr> wrote:
>> (I think it just leads to some ‘packet loss’ if we get stuff outside
>> replay window, so it is fine; the challenge-response should be probably
>> triggered if and only if no valid stuff has been received for X from the
>> node..)
> Challenge on nonce change only, not on out-of-order PC?

I think there is a tradeoff between DoS resistance (no spurious challenges) and fast recovery from sender state loss. There seems to be plenty of design decisions to be made here though, and only based on them sensible choices can be made, but for the time being I am leaning towards the former, so I’d say challenge should be sent iff:

- no sender nonce for node (duh; new node), _or_
- no valid hmac (with valid sender nonce) received over time period of (IHU interval * something)

The messages with counter outside replay window (if used at all) would be just ignored if replay window is not used. 

e.g. sender reboots -> with this scheme, it would only recover with timeout and that’s bit icky as well.. on the other hand, node reboots probably take normally some time as well so I am not sure it is really as bad as one could think on first estimation. Key rotation or intentional counter reset/roll-over might need further thought though..

-Markus