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

Daniel:

> Should we consider adding / replacing PKCS1v1.5
> by RSA-PSS for the signature format.

An early version of the spec called for PSS. After strong objections - most 
prominently Peter Gutmann's; it is possible there were others - I changed 
back to PKCS1v1.5. The main objections were:

- PSS is not as universally available;
- adding a new type of padding would impose costs on highly 
resource-constrained implementations who would now have to support both.

I have no objections to adding PSS. At this point, it would have to be added 
as separate variants. For example: rsa-sha2-256-pss, rsa-sha2-512-pss.

The existing names already have widely implemented / accepted meanings with 
PKCS1v1.5.

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

The issue are penalties in software already deployed. Servers are often used 
for 5-10 years without update. Users actively resist updates, even if we 
urge otherwise. Often, there's no one to perform an update. The 
administrator who configured the server has left. The people who use it are 
afraid, because they don't have anyone who understands their setup if it 
breaks. A new spec won't fix this deployed base.

Software that's aware of this spec is suggested to implement the 
"server-sig-algs" extension with EXT_INFO. This eliminates any need to guess 
what signature algorithm to use. That is this spec's recommendation.

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

The issue does not arise from implementations penalizing known algorithms, 
it arises from old software penalizing unknown algorithms. Old software 
cannot know whether an unknown algorithm is stronger or weaker than what it 
supports.

An option we have is to recommend new implementations to not penalize 
unknown algorithms, because they could be stronger versions of known ones. 
That could be sensible. But the "server-sig-algs" extension already removes 
the need to try an algorithm the server doesn't support.

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

We can put in instructions that work and will realistically be followed, or 
we can put in instructions that don’t work.

Due to existing deployed base, falling back to “rsa-sha2-256” when the 
server does not send “server-sig-algs” will not work. If the spec is made to 
require this, implementers will ignore it for compatibility. Worse, there 
will then be poor guidance toward a solution that does work.

In my opinion, the way to deprecate ssh-rsa is to implement the new 
signature methods; implement the "server-sig-algs" extension to allow them 
to coexist; allow for several years of new deployment; and then, for new 
implementations to start disabling "ssh-rsa" by default.

denis

----- Original Message -----
From: Daniel Migault
Sent: Saturday, March 25, 2017 17:40
To: curdle
Subject: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.txt

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.

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle 