--- 1/draft-ietf-curdle-rsa-sha2-08.txt 2017-06-19 10:34:25.859603939 -0700 +++ 2/draft-ietf-curdle-rsa-sha2-09.txt 2017-06-19 10:34:25.891604703 -0700 @@ -1,18 +1,18 @@ Internet-Draft D. Bider Updates: 4252, 4253 (if approved) Bitvise Limited -Intended status: Standards Track May 30, 2017 -Expires: November 30, 2017 +Intended status: Standards Track June 19, 2017 +Expires: December 19, 2017 Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) - draft-ietf-curdle-rsa-sha2-08.txt + draft-ietf-curdle-rsa-sha2-09.txt Abstract This memo updates RFC 4252 and RFC 4253 to define new public key algorithms for use of RSA keys with SHA-2 hashing for server and client authentication in SSH connections. Status This Internet-Draft is submitted in full conformance with the @@ -119,22 +119,21 @@ string "ssh-rsa" mpint e mpint n All aspects of the "ssh-rsa" format are kept, including the encoded string "ssh-rsa". This allows existing RSA keys to be used with the new public key algorithms, without requiring re-encoding, or affecting already trusted key fingerprints. Signing and verifying using these algorithms is performed according to - the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash; - MGF1 as mask function; and salt length equal to hash size. + the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash. For the algorithm "rsa-sha2-256", the hash used is SHA-2 256. For the algorithm "rsa-sha2-512", the hash used is SHA-2 512. The resulting signature is encoded as follows: string "rsa-sha2-256" / "rsa-sha2-512" string rsa_signature_blob The value for 'rsa_signature_blob' is encoded as a string containing @@ -245,22 +244,22 @@ This document prescribes RSASSA-PKCS1-v1_5 signature padding because: (1) RSASSA-PSS is not universally available to all implementations; (2) PKCS#1 v1.5 is widely supported in existing SSH implementations; (3) PKCS#1 v1.5 is not known to be insecure for use in this scheme. Implementers are advised that a signature with PKCS#1 v1.5 padding MUST NOT be verified by applying the RSA key to the signature, and then parsing the output to extract the hash. This may give an attacker opportunities to exploit flaws in the parsing and vary the encoding. - Implementations SHOULD apply PKCS#1 v1.5 padding to the expected hash, - THEN compare the encoded bytes with the output of the RSA operation. + Verifiers MUST instead apply PKCS#1 v1.5 padding to the expected hash, + then compare the encoded bytes with the output of the RSA operation. 6. Why no DSA? A draft version of this memo also defined an algorithm name for use of 2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256 hashing. It is possible to implement DSA securely by generating "k" deterministically as per [RFC6979]. However, a plurality of reviewers were concerned that implementers would continue to use libraries that generate "k" randomly. This is vulnerable to biased "k" generation, and extremely vulnerable to "k" reuse. This document therefore @@ -300,23 +299,23 @@ [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, August 2013. [RFC8017] Moriarty, K., Kaliski, B., Jonsson, J. and Rusch, A., "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, November 2016. [EXT-INFO] Bider, D., "Extension Negotiation in Secure Shell (SSH)", - draft-ietf-curdle-ssh-ext-info-08.txt, May 2017, + draft-ietf-curdle-ssh-ext-info-10.txt, June 2017, . + draft-ietf-curdle-ssh-ext-info-10>. [IANA-PKA] "Secure Shell (SSH) Protocol Parameters", . Author's Address Denis Bider Bitvise Limited Suites 41/42, Victoria House