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

[denis bider <[e-mail]>]

I created this new address for Curdle to avoid mailing list delivery issues
due to DKIM and SPF.

Daniel:


> I believe it would be good to add rsa-sha2-256-pss, rsa-sha2-512-pss.

I can do that, but the next question is, will someone implement it?

If someone comes forward and says they'll be adding the PSS variants, I can
definitely include them.

If we do add them, this will make Peter unhappy. :) If my recollection
serves, he disliked the 512 variant, as it is.

The objection with additional variants is that if a fraction of deployments
are set up to require them, this puts pressure on others to implement them
as well. For Peter, this is a cost because his usage cases are extremely
constrained.


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

OK. I have added the following:

"This document is based on the premise that RSA is used in environments
where a gradual, compatible transition to improved algorithms will be
better received than one that is abrupt and incompatible. It advises that
SSH implementations add support for new RSA signature algorithms along with
SSH_MSG_EXT_INFO and the "server-sig-algs" extension to allow coexistence
of new deployments with older versions that support only "ssh-rsa".
Nevertheless, implementations SHOULD start to disable "ssh-rsa" in their
default configurations as soon as they have reason to believe that new RSA
signature algorithms have been widely adopted."

Does this sound well?

denis


----- Original Message -----
From: Daniel Migault
Sent: Sunday, March 26, 2017 14:39
To: denis bider (Bitvise)
Cc: curdle
Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.txt

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) <
[e-mail]> wrote:

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


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.



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.


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.


Agree.


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.

Agree

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.


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


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

_______________________________________________
Curdle mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/curdle