[Ntp] Re: Wrong NTS key exporter context in use for AES-128-GCM-SIV

Daniel Franke <dfoxfranke@gmail.com> Tue, 17 September 2024 19:08 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 84C26C14F6BE for <ntp@ietfa.amsl.com>; Tue, 17 Sep 2024 12:08:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIZWOoPnNM7E for <ntp@ietfa.amsl.com>; Tue, 17 Sep 2024 12:08:13 -0700 (PDT)
Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16945C14F6AD for <ntp@ietf.org>; Tue, 17 Sep 2024 12:08:13 -0700 (PDT)
Received: by mail-oo1-xc29.google.com with SMTP id 006d021491bc7-5d5c7f24372so3466147eaf.0 for <ntp@ietf.org>; Tue, 17 Sep 2024 12:08:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726600092; x=1727204892; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9ka8IRm0Cg+EqL0XQmozaSiqwNuPfKVBaYJULril/4A=; b=M2OOcCImz14SLiUqQ/VlTAuQKa+mHLN57ZDueBXRYwfZSbEch2JC2BGm0+7If6Lej0 bSBfe2nDKElj3b1qrVdpmjLOiC+fEAq+Hlyjk2Hf8Fd8gQ0XiYg0/RK9aa2ctYbpYhFX V8otIxS64iA4bNA/ksG05ayw0o/Xi4J7fDyQV0d9IccD3Tnp7Ez7HjOermFRNNJpel9R /lMy21ISTvfnnH1XivwCOieOJ138z9L1k7364qMcDQqDJYFJRvrPLD5q41swiHG2w2mF CZfqhGDQ1imFH/tBP7/Tur0g46xJwhugTO9dWYeMg3DvC80tj4aPbCvz8RqJ9BpdEPUB 56uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726600092; x=1727204892; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9ka8IRm0Cg+EqL0XQmozaSiqwNuPfKVBaYJULril/4A=; b=JrwP6hqqFndYMjd0M/2Bl+H4M8XrcUpzsCcYQLARuoI1G+M1iIBfOjukveLmbSQYqj d+lOSi3SDzTsQhzAArt3mHQfRS8uMrzJLXbuIYZyCPvgB8RYdRhFg+lpbnuRDpdsxDL8 Wb+yOx3edtzBGG7D7YW5HsS92akVZaPwXDVc2XATGw6mXVZI49xjTgSOGmnf94z0fVKN fj43bFyE+aHM0hHZNAIimNtPueTWzxrx3vgY1QaOnJSYSejnN5vCdNVVmEFx5BXw5gvx icG39aLwxRuRFIRTxcU7z72ykGMpiqGtrRVtaNbEql2sa+vStQlHz04iRQbAWBMmgHON 7/0A==
X-Gm-Message-State: AOJu0YxJ1JhGes20SkKMFCl1HlPyQOsF4WGAwUmbBsoPwYZKM7hkfwXS /p+RXaCDUKY+zVE5GWbLT5bGA0R7QFuwbPpu2Wxqc4ZkmXt8bNjBXzKz9+1ZOmuXMdXfb55XiXF JaXsvRp7ERzebx8vYfqMhEaLzh8E=
X-Google-Smtp-Source: AGHT+IHeO7A/OUrzhjBBgkBoGXVg8mn56KywPK6bp+WqhsthBmMfohuNwpKBGfTfnQ3o9MVu25E1FUiVUDxqU79drvI=
X-Received: by 2002:a05:6820:162c:b0:5e1:ebaa:efc9 with SMTP id 006d021491bc7-5e20147eb81mr10186042eaf.8.1726600092333; Tue, 17 Sep 2024 12:08:12 -0700 (PDT)
MIME-Version: 1.0
References: <Zuft30p5rxdjn50i@localhost> <CAJm83bD4_KbQ2=ygwUHtmNVggawViDN5toR+2MY8v+OgNQXX1w@mail.gmail.com> <ZumRC2K9fifFiE7r@localhost>
In-Reply-To: <ZumRC2K9fifFiE7r@localhost>
From: Daniel Franke <dfoxfranke@gmail.com>
Date: Tue, 17 Sep 2024 15:06:18 -0400
Message-ID: <CAJm83bC45f6=cgHw5mB=9-2vxX_L5y-d9fr8frQxdyD=xkeX3Q@mail.gmail.com>
To: Miroslav Lichvar <mlichvar@redhat.com>
Content-Type: multipart/alternative; boundary="0000000000002c40c20622556912"
Message-ID-Hash: Z5DXZ67VYSJU7ZEGLUB7QWVY7Z2LSRRU
X-Message-ID-Hash: Z5DXZ67VYSJU7ZEGLUB7QWVY7Z2LSRRU
X-MailFrom: dfoxfranke@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ntp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: ntp@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Ntp] Re: Wrong NTS key exporter context in use for AES-128-GCM-SIV
List-Id: Network Time Protocol <ntp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/AQIz5D-T3cmRMi6lnnFEApeC0S8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Owner: <mailto:ntp-owner@ietf.org>
List-Post: <mailto:ntp@ietf.org>
List-Subscribe: <mailto:ntp-join@ietf.org>
List-Unsubscribe: <mailto:ntp-leave@ietf.org>

On Tue, Sep 17, 2024 at 10:24 AM Miroslav Lichvar <mlichvar@redhat.com>
wrote:

> On Mon, Sep 16, 2024 at 08:59:48AM -0400, Daniel Franke wrote:
> > What I would suggest you do is publish a specification which explains the
> > issue and defines a "Chrony AES-128-GCM-SIV workaround" NTS-KE record
> type,
> > with an empty body and its critical bit cleared. A server which has the
> > fix, upon receiving an NTS-KE request with the record present, will
> respond
> > with it present in turn, and will record somewhere in the cookie that the
> > fix was negotiated. Initially, fixed servers will continue to perform the
> > noncompliant context calculation with any client which doesn't negotiate
> > the fix, but eventually (probably not for a very long time,
> unfortunately)
> > can drop support for broken clients and always perform the compliant
> > calculation. From the client's perspective, a server which negotiates the
>
> Ok, so if I understand it correctly there would be three phases needed
> to resolve this problem:
>
> - all implementations with AES-128-GCM-SIV support have to support
>   both context calculations and the new record type, defaulting to the
>   noncompliant calculation
>
> - all implementations switching their default to the compliant
>   calculation
>
> - implementations removing support for the workaround record type
>
> Any overlap between the phases or any implementations not following
> this plan would cause interoperability problems. How likely this is to
> succeed?
>
> I'm wondering, is there any practical problem with the noncompliant
> context that it couldn't be specified as an exception and avoid the
> migration to the compliant context? Maybe a new AEAD will be specified
> in the mean time and most implementations will not care about
> AES-128-GCM-SIV anymore at that point?
>

It sounds like you're suggesting making a flag-day change to the standard,
and I'm against doing that on account of a bug that existed in one
implementation.  The benefit of introducing the new record type is that
this works within RFC8915's existing extension mechanisms and doesn't
require a standards action, since the registration requirement for new
record types is merely "specification required".

The three phases you list are what would happen in an ideal world, yes,
although any server implementations other than Chrony will likely want to
go to phase 2 from the beginning. However, I'm not assuming that we'll
necessarily ever make it to phase 2 or phase 3. If we sit at phase 1
forever, then we all get to live with a little extra cruft in our
codebases, but I don't think it's any cruftier than your proposed
alternative.