IETF Logo Mail Archive

Re: [Ntp] Antw: [EXT] Re: Post NTS, Is shared key authentication interesting?

Daniel Franke <dfoxfranke@gmail.com> Wed, 27 May 2020 13:44 UTC

Return-Path: <dfoxfranke@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 B8DE23A0AAC for <ntp@ietfa.amsl.com>; Wed, 27 May 2020 06:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 7ZwcgUpO6rOT for <ntp@ietfa.amsl.com>; Wed, 27 May 2020 06:44:46 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 8D84F3A0AA7 for <ntp@ietf.org>; Wed, 27 May 2020 06:44:46 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id j8so25917446iog.13 for <ntp@ietf.org>; Wed, 27 May 2020 06:44:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LyVdaWaltutHJiscgnZSqzcmHUdbwBYds4SiDcp4rgI=; b=TtMl2KkrZ4+SuAbeS/jQUDkk2iARXzoiP5UUF1KhMfK46R7eQv/oxcPh3407CcvFrp ayiAhhplKxB/GlclJxHXskHWYhJIomsp5Y+/liMObpQL/trD0k9swgtzrREyaL1EhwN0 FwlARNtUm0kOzD+Kx7h5slH8itVRdSIN9xsoqhzsGgXCKlStL/BIN2Qv/xdeitmXpv0Q yJCnL2DXZUMEJrCjnyNwq8oLi4dr2QQsdvqUbDfySdNu3rjPQ6OwxyAAloz+CWX+ar4o 4IcUrXXLr4KHBiifyidk2OPjrTIcn9jz8eSHXUkDBGvlV9jxc4Utntx93Q0L1q7UU8ZL UGFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LyVdaWaltutHJiscgnZSqzcmHUdbwBYds4SiDcp4rgI=; b=RRGYUmihiRiTSe7KDafr1emjzY451G13J0fg/5sqmUl5O5IFpIaZrvO4wgoTRV6WjU kWAJbE/VoOxETqUFKOE0j3tHEzUzOuuOy968UC9B3POuk0cCRGKoOBp1fs8uqxHbOSH3 gJJmOIyGfgxi1brr4R6+VjsmpUNre+/UL/WBSWimrmOyTlhBDsIzjT9+Mtumpp2aHOiE 0n+guOG6PSQa2XZqJsa8y20nGBWqfZRpJZhy9CsQfvmvMgwmRAcqqrM6yORTB425Bzi6 Irq4Uxp9bH0AtY0OS2ujapTLkySF5BLaKIO1WINU5LSESggJY0ewpal4lbk02jFlrAxY 5S8w==
X-Gm-Message-State: AOAM532m0KbKIBhLX1mjrKuZ7Mz0e2pGoTOhiFiLY/M9GjKSO72UBYI/ smY2GI97d1LH/0hTcejnYQx3dB7br8Zc0XMT+DQ=
X-Google-Smtp-Source: ABdhPJxbmy4HuN+T7uuhbu2ImtLojFha0exdk/uov3Y6XU7AxQzHxPYgl57Yd7x27y90DRtYQ6nElJbinqk097omhCk=
X-Received: by 2002:a02:298b:: with SMTP id p133mr1525733jap.73.1590587084905; Wed, 27 May 2020 06:44:44 -0700 (PDT)
MIME-Version: 1.0
References: <68248D4C020000916A6A8CFC@gwsmtp.uni-regensburg.de> <54A83DA70200003B43047E14@gwsmtp.uni-regensburg.de> <5ECE33E0020000A10003934B@gwsmtp.uni-regensburg.de> <20200527095536.GR2915@roeckx.be> <FAE302D1-126A-4393-9208-8EC1D9F6A7BD@akamai.com>
In-Reply-To: <FAE302D1-126A-4393-9208-8EC1D9F6A7BD@akamai.com>
From: Daniel Franke <dfoxfranke@gmail.com>
Date: Wed, 27 May 2020 09:44:33 -0400
Message-ID: <CAJm83bASrTxnx4DMkKXoP4zyKeKuVzgNdeaO4_Yk+P9EGJzwvg@mail.gmail.com>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
Cc: Kurt Roeckx <kurt@roeckx.be>, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, "mlichvar@redhat.com" <mlichvar@redhat.com>, Hal Murray <hmurray@megapathdsl.net>, "ntp@ietf.org" <ntp@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002e1ec305a6a16ae6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Z6nQx5AkVtPEQHEL8vqW9VxBRIE>
Subject: Re: [Ntp] Antw: [EXT] Re: Post NTS, Is shared key authentication interesting?
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: Wed, 27 May 2020 13:44:48 -0000

On Wed, May 27, 2020 at 9:33 AM Salz, Rich <rsalz=
40akamai.com@dmarc.ietf.org> wrote:

>
> This is known as an oracle, and from this kind of thing, it is possible to
> do pretty fine-grain timings and figure out keys.  This is often surprising
> to folks, but look up "Lucky Thirteen" as an example.
>

While this is certainly a thing to keep in mind whenever designed error
responses in crypto protocols, the crypto-NAKs in legacy NTP and NTS are
both fine. The reason this is so incredibly hairy in TLS (prior to 1.3) is
that the protocol asks the server to accept malleable ciphertext from an
untrusted source and then take actions based on the corresponding
plaintext. All NTP has to do is send an error message if a MAC doesn't
validate. This is much safer, because the MACed message is not secret and
is non-malleable.

v2.23.0 | Report a Bug | By Email