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

[Ondřej Surý <[e-mail]>]

Hi Peter,

thanks for the review.  I am preparing new revision based on last call
and area secretariates comments, so I'll merge your comments as well.

I am starting to find how unbelievably hard is to add just two new numbers
to IANA registry in IETF :).  This draft will be soon in better shape
than the one which actually did something (added support to SSH protocol).

O.

On 4. 1. 2012, at 19:17, Peter Koch wrote:

> 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

--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[e-mail]    http://nic.cz/
 tel:[phone]       fax:[phone]
 -------------------------------------------