multiple SSHFP records for the same hostname and key type

[Oli Schacher]

Dear list

I have two servers with different host keys which provide a ssh service 
under a shared host name, in an active-passive setup. When connecting to 
ssh-service.einbeispiel.ch you reach either server A or B. This service 
name has two SSHFP records:

ssh-service.einbeispiel.ch SSHFP 4 2 <ED25519 hostkey from server A>
ssh-service.einbeispiel.ch SSHFP 4 2 <ED25518 hostkey from server B>

This has worked previously, but openssh has changed its implementation 
in 8.7., so that apparently *ALL* SSHFP records must match or the Host 
key will not be accepted. [1]

# example with OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k  25 Mar 2021
ssh -v -o HostKeyAlgorithms=ssh-ed25519 -o VerifyHostKeyDNS=yes 
ssh-service.einbeispiel.ch
[...]
debug1: found 2 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS


# example with OpenSSH_8.9p1, OpenSSL 1.1.1m  14 Dec 2021
ssh -v -o HostKeyAlgorithms=ssh-ed25519 -o VerifyHostKeyDNS=yes 
ssh-service.einbeispiel.ch
[...]
debug1: verify_host_key_dns: failed SSHFP type 4 fptype 2
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 2
debug1: mismatching host key fingerprint found in DNS
[...]
No matching host key fingerprint found in DNS.


It seems to me that this change breaks two use cases:

a) the one described above , i.e. using SSHFP records for a common 
service name provided by multiple backends with different host keys

b) the possibility to seamlessly replace a host key without breaking 
SSHFP validation, as this would require the SSHFP record to be changed 
*exactly* at the same time as the host keys. But due to DNS TTLs / 
replication delay this is not possible and there will always be a time 
frame where these records are out of sync. With the earlier behavior I 
could just add the new SSHFP record in the DNS and have both old and new 
keys active, then replace the host key on the server, then remove the 
old key from DNS SSHFP.

rfc4255[2] says

"If the algorithm and fingerprint of the key received from the SSH 
server match the algorithm and fingerprint of *one of* the SSHFP 
resource record(s) returned from DNS, the client MAY accept the identity 
of the server."

note the "one of"

So I'm wondering if the change in 8.7 from "one of" to "all" did 
consider these two cases at all. Should I change my use cases or is this 
a breakage in openssh that could be considered to be reverted?

Thanks for your help and best regards
Oli


[1] https://www.openssh.com/txt/release-8.7
[2] https://datatracker.ietf.org/doc/html/rfc4255#section-2.1