[dns-dir] some comments on draft-os-ietf-sshfp-ecdsa-sha2-04.txt

[Peter Koch <[e-mail]>]

Hi Ondrej,

i came across another review of <draft-os-ietf-sshfp-ecdsa-sha2-04.txt>
and would like to add some remarks.  I've copied the DNS Directorate
for information.  Not sure what the status of the draft is - the
datatracker confuses me by claiming 'wg document', but i do not see
which WG?  Generally the draft looks like a good idea!

To start with some formalities, the header and abstract claim the draft
updates RFC 4255. I would suggest it does not.  It updates two IANA
registries defined and seeded by RFC 4255, but it does not (to my
reading) change any content of RFC 4255.   If it were to update 4255,
it should probably adjust the registry policies from "IETF consensus"
as per RFC 2434 to "IETF Review" as per RFC 5226, but that's probably
for another venue to discuss.

Second, the document aims at Standards Track and I do not see why.
An IETF/IESG reviewed RFC would be sufficient.  Not saying it
should be less than ST, but what's the purpose here?  Later serving
as normative reference?

In section 3.2 the use of an ECDSA fingerprint is defined.  I could
not find the description of the Fingerprint in RFC 5656.
Furtheron it reads

   ECDSA public key fingerprints MUST use the SHA-256 algorithm for the
   fingerprint as using the SHA-1 algorithm would weaken the security of
   the key.

First, could the claim 'would weaken the security' be substantiated
(maybe by reference) a bit?  Second, what is the consequence, i.e.
who is supposed to act on a violation? Is it the DNS implementation
(hard to achieve with 'transparent' RR types), the DNS operator or
the consuming entity?  I would suggest to reverse the logic here and
only demand that a consuming party MUST ignore SHA-1 FPs for ECDSA.

In 4.1, the SHA-256 fingerprint is introduced. The consuming entity
   is advised "Secure Shell
   implementations which support SHA-256 fingerprints MUST prefer a SHA-
   256 fingerprint over SHA-1 if both are available for a server.  If
   the SHA-256 fingerprint is tested and does not match the supplied
   key, then the key MUST be rejected rather than testing the
   alternative SHA-1 fingerprint."

This assumes that both FPs are for the same key? Couldn't it happen that
the server offers an RSA and an ECDSA key, using SHA-1 for the former
and ECDSA for the latter?

Nit: Add some text after the headline "5. Examples", e.g.

  The following examples provide reference for both the newly defined
  ECDSA algorithm number and the use of the SHA-256 fingerprint
  combined with both the new and the existing algorithm numbers.

The examples refer to "OpenSSH format" without any reference.

The references to the DNSSEC RFCs are probably informative only.

Best regards,
    Peter