[Ntp] Roughtime and Delay Attacks

Tal Mizrahi <tal.mizrahi.phd@gmail.com> Tue, 02 April 2019 04:13 UTC

Return-Path: <tal.mizrahi.phd@gmail.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68263120004 for <ntp@ietfa.amsl.com>; Mon, 1 Apr 2019 21:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 F4wvz6813wum for <ntp@ietfa.amsl.com>; Mon, 1 Apr 2019 21:13:57 -0700 (PDT)
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 9D6C512001E for <ntp@ietf.org>; Mon, 1 Apr 2019 21:13:57 -0700 (PDT)
Received: by mail-wm1-x342.google.com with SMTP id v14so1816997wmf.2 for <ntp@ietf.org>; Mon, 01 Apr 2019 21:13:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=tp39uGhy9efxv6yIdVeuXRjoU9ZRBmYTAkoCM2v09IU=; b=XpSwP2/7WP99zGxXlTw1ZgP9vm9ylFMn25QlrD4iSx/+0uu8AhwLHEZwHYs/nec3n8 yOo+s0D4f++ln+50PgsK7x8HifR8Vf+trcQ0goGqs7B6R1qN/ex3GYojHdGiatPOr7Ls ApYuGg2+avUx1UXzJTAN9ElXcvTRnbLqGG69D4AUU632P3ZVwHstRuhEMGp48IXZCRzy 9G6Ftrn6YxjugmBuQ8B6F7NYxkifgkBkvIH36x5nKEjcSQObk0BfhdUNFivgr758fvTT SYbmZImrUT2+VEZPt4xQk0A+AMik3G2ngHSH3aPUIBb1EoQHCcYI8Ovix6Dy0wOp8GdJ OFTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tp39uGhy9efxv6yIdVeuXRjoU9ZRBmYTAkoCM2v09IU=; b=alVlob7eLNgSlu7vwd9tMx3yAJbNSVD1eBCxY9+5nNFeiozjrfQhIbkoU13UPpZUqt 65oNg2Q1pnK9MgsizGdu5TbpBycJh2pL6TsZcwDXaieOm/VD1eCnWw+FP2h6NtE5zkNA aOGKPic/65uc8k2YApveEmtuLSqHj7KLekxtCn36BvvmeozFO7rx0lpx9389JpcNkws1 vgI3zUxTQWD7OVYIXEf4TaLks5a+KzdfSnFN0N9YVhLEpTIlXEspU2iLVkjlonfWdtxd Rv0d9lWzqbhIyPp/7IFYh+0BSkoVFQ4+V1kyLuTpwtDGkNC0YMcIT9NujWOPQ3Ywbn6U cLSQ==
X-Gm-Message-State: APjAAAWLe8UFP/ijjMHifiz1d9uB+itOzUvVc5YuqicmUoUX0BMibb3/ KQPb4OOAjsrRUbsa9usaZLNL3M5J667YLwu6+oU=
X-Google-Smtp-Source: APXvYqwfKnEtF9VesjJufygnYfnX/bI/P0YFswDATm95FltzWZmPq0VBEv13Ep/n+ubTBzERFOM0aDcnPKPkOiRQ2v4=
X-Received: by 2002:a1c:c00b:: with SMTP id q11mr1981721wmf.38.1554178436017; Mon, 01 Apr 2019 21:13:56 -0700 (PDT)
MIME-Version: 1.0
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Tue, 02 Apr 2019 07:13:42 +0300
Message-ID: <CABUE3Xmg1vZedhEras54LC6WyChPhcZnqB2s1TNcMaoLbarkdQ@mail.gmail.com>
To: Aanchal Malhotra <aanchal4@bu.edu>, Watson Ladd <watsonbladd@gmail.com>, kristof.teichel@ptb.de, ntp@ietf.org
Content-Type: multipart/alternative; boundary="00000000000098b3fe0585845d7a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/OL4tAukVQDe-bf8a8NGKLAdU-vQ>
Subject: [Ntp] Roughtime and Delay Attacks
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2019 04:14:00 -0000

Hi Aanchal, Watson, Kristof,

Thanks for a fruitful discussion in Prague.

To summarize our discussion regarding delay attacks: in order to roughly
detect delay attacks, a client has a MAX bound on the RTT. If the RTT of a
request-response handshake exceeds MAX, the client ignores the
corresponding server. Indeed, I believe this helps the client to roughly
detect delay attacks.

Question: in the scenario above, i.e., RTT>MAX, how can the client prove
the server's malfeasance? The cryptographic chain in this example would
indicate that all the servers are well, and the client has no way to prove
that RTT>MAX. What am I missing?

Thanks,
Tal.