[Curdle] comments on draft-ietf-curdle-rsa-sha2-03.txt

[Daniel Migault <[e-mail]>]

Hi,

Please find my comments on draft-ietf-curdle-rsa-sha2-03.txt.

In a word my comments are:
   - 1) Should we consider  adding / replacing PKCS1v1.5 by RSA-PSS for
the signature format.
   - 2) I understand that penalties are encouraging to keep ssh-rsa while
the use of sha1 is deprecated. I suggest to provide some recommendations on
how to perform penalties.

Yours,
Daniel

      Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)
                   draft-ietf-curdle-rsa-sha2-03.txt


Abstract

  This memo defines an algorithm name, public key format, and signature
  format for use of RSA keys with SHA-2 512 for server and client
  authentication in SSH connections.

MGLT: Maybe we should also add penalty recommendations as well ?

2.  Public Key Algorithms

  This memo adopts the style and conventions of [RFC4253] in specifying
  how use of a signature algorithm is indicated in SSH.

  The following new signature algorithms are defined:

    rsa-sha2-256    RECOMMENDED    sign    Raw RSA key
    rsa-sha2-512    OPTIONAL       sign    Raw RSA key

  These signature algorithms are suitable for use both in the SSH transport
  layer [RFC4253] for server authentication, and in the authentication
  layer [RFC4252] for client authentication.

  Since RSA keys are not dependent on the choice of hash function, both
  new algorithms reuse the public key format of the existing "ssh-rsa"
  algorithm as defined in [RFC4253]:

    string    "ssh-rsa"
    mpint     e
    mpint     n

  All aspects of the "ssh-rsa" format are kept, including the encoded
  string "ssh-rsa", in order to allow users' existing RSA keys to be
  used with the new signature formats, 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 [RFC3447] using SHA-2 [FIPS-180-4] as
  hash; MGF1 as mask function; and salt length equal to hash size.

MGLT: Could we also take this opportunity to upgrade the signature to
RSA-PSS ?
If "rsa-sha2-256" / "rsa-sha2-512" are already deployed in most
implementation, maybe this document could also define
"rsa-sha2-256-rsassa-pss" and "rsa-sha2-512-rsassa-pss" otherwise we could
define rsa-sha2-* with RSA-PSS.


3.  Discovery of signature algorithms supported by servers

  Implementation experience has shown that there are servers which apply
  authentication penalties to clients attempting signature algorithms
  which the SSH server does not support.

MGLT: Can we recommend to have penalties only applies when algorithms are
weaker than the one supported.

  Servers that accept rsa-sha2-* signatures for client authentication
  SHOULD implement the extension negotiation mechanism defined in
  [SSH-EXT-INFO], including especially the "server-sig-algs" extension.

  When authenticating with an RSA key against a server that does not
  implement the "server-sig-algs" extension, clients MAY default to an
  ssh-rsa signature to avoid authentication penalties.

MGLT: ssh-rsa must be deprecated, so I think we should have something
different. The fall back should be on the most recommended algorithm, or
the authentication penalty should be changed.