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

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

Hi Peter,

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.

Fixed.  Sound reasonable.

> 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?

I am not aware of such thing as IESG reviewed RFC. RFC 2026 is no
help here.  Maybe you can point me to a reading material?

> 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.

Sounds reasonable, but if I were to reverse the login, it would also
mean that if there's an implementation which generates ECDSA with SHA-1
it wouldn't work for consuming party and it breaks the robustness
principle.

I want to say - if you create the FP use SHA-256, if you receive SHA-1
key then you may use it unless you also receive SHA-256.

> 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?

No, I don't think so.  The server always offers just one key.  And in the
unlikely scenario where more servers are behind balanced IP address you
would need to keep the keys in sync, because SSH would yell at you every
time you get different server key.

As for key rollovers - you first need to upgrade hashing algorithm
and then add new key.

> 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.

Thanks for the text, added.

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

Good catch.

> The references to the DNSSEC RFCs are probably informative only.


Fixed.

O.
--
 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]
 -------------------------------------------