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

[Ralph Droms <[e-mail]>]

I have a couple of followups in line

Otherwise, is the DNS Directorate OK with rev -07 of this document?

- Ralph

On Jan 27, 2012, at 3:00 AM 1/27/12, Ondřej Surý wrote:

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

E.g., an Informational RFC would suffice.

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

Section 3.2 seems to have changed.  What was the ultimate resolution of this discussion point?

> 
>> 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]
> -------------------------------------------
> 
> _______________________________________________
> dns-dir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-dir