draft-ietf-curdle-rsa-sha2-08.txt		draft-ietf-curdle-rsa-sha2-09.txt
	Internet-Draft D. Bider		Internet-Draft D. Bider
	Updates: 4252, 4253 (if approved) Bitvise Limited		Updates: 4252, 4253 (if approved) Bitvise Limited
	Intended status: Standards Track May 30, 2017		Intended status: Standards Track June 19, 2017
	Expires: November 30, 2017		Expires: December 19, 2017
	Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)		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		Abstract
	This memo updates RFC 4252 and RFC 4253 to define new public key		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		algorithms for use of RSA keys with SHA-2 hashing for server and
	client authentication in SSH connections.		client authentication in SSH connections.
	Status		Status
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 33 ¶
	string "ssh-rsa"		string "ssh-rsa"
	mpint e		mpint e
	mpint n		mpint n
	All aspects of the "ssh-rsa" format are kept, including the encoded		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		string "ssh-rsa". This allows existing RSA keys to be used with the
	new public key algorithms, without requiring re-encoding, or affecting		new public key algorithms, without requiring re-encoding, or affecting
	already trusted key fingerprints.		already trusted key fingerprints.
	Signing and verifying using these algorithms is performed according to		Signing and verifying using these algorithms is performed according to
	the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash;		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.
	For the algorithm "rsa-sha2-256", the hash used is SHA-2 256.		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.		For the algorithm "rsa-sha2-512", the hash used is SHA-2 512.
	The resulting signature is encoded as follows:		The resulting signature is encoded as follows:
	string "rsa-sha2-256" / "rsa-sha2-512"		string "rsa-sha2-256" / "rsa-sha2-512"
	string rsa_signature_blob		string rsa_signature_blob
	The value for 'rsa_signature_blob' is encoded as a string containing		The value for 'rsa_signature_blob' is encoded as a string containing
	skipping to change at page 6, line 17 ¶		skipping to change at page 6, line 17 ¶
	This document prescribes RSASSA-PKCS1-v1_5 signature padding because:		This document prescribes RSASSA-PKCS1-v1_5 signature padding because:
	(1) RSASSA-PSS is not universally available to all implementations;		(1) RSASSA-PSS is not universally available to all implementations;
	(2) PKCS#1 v1.5 is widely supported in existing SSH 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.		(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		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		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		then parsing the output to extract the hash. This may give an attacker
	opportunities to exploit flaws in the parsing and vary the encoding.		opportunities to exploit flaws in the parsing and vary the encoding.
	Implementations SHOULD apply PKCS#1 v1.5 padding to the expected hash,		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.		then compare the encoded bytes with the output of the RSA operation.
	6. Why no DSA?		6. Why no DSA?
	A draft version of this memo also defined an algorithm name for use of		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		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"		hashing. It is possible to implement DSA securely by generating "k"
	deterministically as per [RFC6979]. However, a plurality of reviewers		deterministically as per [RFC6979]. However, a plurality of reviewers
	were concerned that implementers would continue to use libraries that		were concerned that implementers would continue to use libraries that
	generate "k" randomly. This is vulnerable to biased "k" generation,		generate "k" randomly. This is vulnerable to biased "k" generation,
	and extremely vulnerable to "k" reuse. This document therefore		and extremely vulnerable to "k" reuse. This document therefore
	skipping to change at page 7, line 46 ¶		skipping to change at page 7, line 46 ¶
	[RFC6979] Pornin, T., "Deterministic Usage of the Digital		[RFC6979] Pornin, T., "Deterministic Usage of the Digital
	Signature Algorithm (DSA) and Elliptic Curve Digital		Signature Algorithm (DSA) and Elliptic Curve Digital
	Signature Algorithm (ECDSA)", RFC 6979, August 2013.		Signature Algorithm (ECDSA)", RFC 6979, August 2013.
	[RFC8017] Moriarty, K., Kaliski, B., Jonsson, J. and Rusch, A.,		[RFC8017] Moriarty, K., Kaliski, B., Jonsson, J. and Rusch, A.,
	"PKCS #1: RSA Cryptography Specifications Version 2.2",		"PKCS #1: RSA Cryptography Specifications Version 2.2",
	RFC 8017, November 2016.		RFC 8017, November 2016.
	[EXT-INFO] Bider, D., "Extension Negotiation in Secure Shell (SSH)",		[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,
	<https://tools.ietf.org/html/		<https://tools.ietf.org/html/
	draft-ietf-curdle-ssh-ext-info-08>.		draft-ietf-curdle-ssh-ext-info-10>.
	[IANA-PKA] "Secure Shell (SSH) Protocol Parameters",		[IANA-PKA] "Secure Shell (SSH) Protocol Parameters",
	<https://www.iana.org/assignments/ssh-parameters/		<https://www.iana.org/assignments/ssh-parameters/
	ssh-parameters.xhtml#ssh-parameters-19>.		ssh-parameters.xhtml#ssh-parameters-19>.
	Author's Address		Author's Address
	Denis Bider		Denis Bider
	Bitvise Limited		Bitvise Limited
	Suites 41/42, Victoria House		Suites 41/42, Victoria House
End of changes. 6 change blocks.
	9 lines changed or deleted		8 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/