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

From: Daniel Migault <[email-masked]>
Date: Sat, 25 Mar 2017 19:40:26 -0400

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.

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Sun, 26 Mar 2017 11:56:14 -0600

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,

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

Yours,
Daniel

Abstract

2.  Public Key Algorithms

    string    "ssh-rsa"
    mpint     e
    mpint     n

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
[email-masked]
https://www.ietf.org/mailman/listinfo/curdle

---

From: Daniel Migault <[email-masked]>
Date: Sun, 26 Mar 2017 15:39:40 -0500

Hi,

Thanks for the response. Please see mine inline. In short I agree with your
responses. I believe it would be good to add rsa-sha2-256-pss,
rsa-sha2-512-pss.

Yours,
Daniel

On Sun, Mar 26, 2017 at 12:56 PM, denis bider (Bitvise) <
[email-masked]> wrote:

> 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:
>
> 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 the motivations. I personally think it would be good to add
rsa-sha2-256-pss, rsa-sha2-512-pss

> 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
> "server-sig-algs" extension with EXT_INFO. This eliminates any need to
> guess what signature algorithm to use. That is this spec's recommendation.
>
>
> Agree, my recommendation on penalties was mostly for new implementations
that do not implement ext_info. Maybe you are right having ext_info solve
this issue better.

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

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

> Maybe that would be good to explain how the option is also helping to
deprecate suites in the security consideration section.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 27 Mar 2017 00:41:27 +0000

denis bider (Bitvise) <[email-masked]> writes:

>- adding a new type of padding would impose costs on highly resource-
>constrained implementations who would now have to support both.

A third point is that there's no security advantage to using PSS.  It has a
more rigorous design than PKCS #1 1.5, but there's no indcation that 1.5 is
less secure.  So it's something that offers no obvious benefit but requires
implementing and supporting yet another new crypto mechanism.

I don't mind if it's there as a MAY for people who really feel the need to
make that particular fashion statement, as long as 1.5 is still there as a
MUST.

Peter.