Last Call Review of draft-os-ietf-sshfp-ecdsa-sha2-
review-os-ietf-sshfp-ecdsa-sha2-genart-lc-dupont-2011-12-15-00

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments 
you may receive.

Document: draft-os-ietf-sshfp-ecdsa-sha2-04.txt
Reviewer: Francis Dupont
Review Date: 20111210
IETF LC End Date: 20120103
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: not a real issue but I am not convinced there is a real
crypto reason to give up SHA-1. At the first view the attack against
SSHFP is a pre-image one, but:
 - I leave the question to cryptographers of the security directorate
 - there are many not-crypto reasons to move from SHA-1 to SHA-256

Nits/editorial comments:
 - I'd like to get only the SHA-256 name and no variants, in particular
  no SHA256 (my idea is to always use the same name)

 - IMHO the 'OpenSSH' format is just the PEM format

 - IMHO the multi-line fingerprint in text RRs must be enclosed
  by parenthesis to be correctly parsed

 - 1 page 3: the abbrev RR should be introduced as soon as the term
 'resource record' is used

 - 1 page 3: ; and -> ;

 - 3.2.1 page 4: this is the MUST I am not convinced by the justification
 (BTW I suggest to fix the justification if it is too wrong, and
  to keep the MUST)

 - 7 page 7: software implementations -> implementations

 - 7 page 8: BTW I like the disclaimer:
   ... Regardless of whether or not the attacks on SHA-1 will
   affect SSHFP, it is believed (at the time of this writing) that SHA-
   256 is the better choice for use in SSHFP records.

 - 8.2 page 9: Di!erential -> Differential

 - Author's Address: CZ -> Czech Republic

Regards

Francis.Dupont at fdupont.fr