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

[Daniel Migault <[e-mail]>]

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
>