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

[Miroslav Lichvar <[e-mail]>]

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