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

[Daniel Franke <[e-mail]>]

That sucks. I think fixing this will necessarily involve some long-term
scar tissue on the protocol, but I don't think the scar has to be too big.

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
fix definitely has it, and the client should go directly to using the
compliant calculation. If the server fails to negotiate the fix, then it's
either a broken Chrony server, or a non-broken non-Chrony server which
refuses to implement the workaround. The client should try one possibility
and then the other, in whatever order represents the greater likelihood as
of when that version of the client was released.

On Mon, Sep 16, 2024 at 4:35 AM Miroslav Lichvar <[e-mail]>
wrote:

> A year ago the chrony NTP implementation added support for the
> AES-128-GCM-SIV AEAD in order to make NTS cookies shorter and improve
> reliability over Internet, where some major operators are known to
> block or limit rate of longer NTP packets as a mitigation against
> mode-6/7 amplification attacks, as was discussed on this list many
> times before.
>
> This seems to work great, except I have now received a report from a
> wireshark developer that chrony uses a wrong exporter context for this
> AEAD. Per RFC8915 the AEAD number is included in the per-association
> context passed to the RFC5705 function, but chrony has this context
> hardcoded for AES-SIV-CMAC-128. I already forgot this fact when I was
> adding the AES-128-GCM-SIV support and there was nothing else to test
> interoperability. It doesn't support any other AEADs, so this impacts
> only AES-128-GCM-SIV.
>
> It seems there is no other NTS implementation that added support for
> AES-128-GCM-SIV yet. When that happens, it will not inteoperate with
> the current clients and servers. I think the developers will quickly
> realize that.
>
> I don't see a good way to fix this without a flag day, requiring both
> clients and servers to be updated at the same time. A fixed client
> could try both exporter contexts and see which works, but the servers
> would have to include both sets of keys (or the TLS context needed
> to generate both) in their cookies to be able to support the broken
> clients, which would make the cookies longer and cause the packets to
> be blocked or rate-limited again.
>
> Does the WG have any suggestions?
>
> --
> Miroslav Lichvar
>
> _______________________________________________
> ntp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>