New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5

[denis bider <[e-mail]>]

Alright - points taken. :-)

The feedback I've received appears to be as follows:

- 1 count of support with caveats (Terra)
- 1 count of neutral feedback (received from Thierry; my summary: deterministic intuitively better than probabilistic; but then again, this is probably not a problem with PSS)
- 1 count of strong opposition (Peter)

In addition, it appears I have misunderstood Peter, and PSS is not available in his environment after all.

All things considered, opposition + availability argument appear to be backed more strongly.

I have posted a new version of the draft, which switches back to PKCS#1 v1.5:

https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-03

I have also updated the experimental server so it implements the latest draft version (with PKCS#1 v1.5):

experiment.bitvise.com:10712

To test host authentication, set the list of host key algorithms in your KEXINIT to "rsa-sha2-256" or "rsa-sha2-512". You will need at least one of these for successful key exchange - the server doesn't offer anything else.

Once you're past host authentication, the server will send a user authentication banner with info to help test user authentication, as well.


----- Original Message -----
From: Peter Gutmann 
Sent: Wednesday, November 11, 2015 20:37
To: denis bider 
Cc: [e-mail] ; [e-mail] 
Subject: RE: rsa-sha2-256: Need YOUR opinion on PSS vs PKCS#1 v1.5

denis bider <[e-mail]> writes:

>> in my case I underestimated the amount of work by 50%,
>> I need to change two lines of code, not one.
>
>So, it turns out that there isn't an availability problem... :-)

Uhh, just in case there's any confusion over this, that's for PKCS #1.  For
PSS I would have had to implement a completely new signature mechanism from
scratch, thus my earlier email requesting use of PKCS #1.

>I am not aware of these practical flaws in PSS, though.

Not yet.  However, PSS has seen so little interest from both the crypto
community and implementers that we can't really say much about it.  For
example for some years the NIST test vectors for RSA-PSS were completely wrong
(every single test except the SHA-224 ones failed), and no-one noticed.

I'll just let that sink in for a second.  The published test vectors from a
major, effectively global in reach, standards body for RSA-PSS were wrong, and
no-one noticed.  How much attention do you think that indicates PSS has got in
practice?

>It is present in major crypto implementations, and has been added to them
>recently (OpenSSL).

Well, OpenSSL is kinda of the petri dish that everything gets hacked into, so
I'm not sure if that's a good indicator.  For example it has a convenient
remote-debug facility that allows attackers to read out your server's memory
in 64kB blocks, but I won't be adding that to my code any time soon.  It also
implements X9.31 RSA, and there was a patch for some of the ISO 9796 RSA
schemes floating around as well.  How often have you run into those in
practice?

In any case with the "close to zero interest" I was referring to
standardisation and support in major crypto-using protocols, PGP, S/MIME,
X.509, IPsec, TLS, and SSH.

>In other words, the fact that you make this argument seems to be the main
>reason PSS is not (yet?) widely adopted. This causes a circular cause and
>effect.

It can actually work both ways: We need to make a start somewhere in order to
get it adopted, or conversely if we adopt it and no-one else does we'll be
stuck supporting an orphan protocol like the lucky adopters of OAEP are.
Given that there's been close to twenty years of no interest, I'd say it's far
more likely to be the latter.

It's actually more than just passive disinterest, it was actively rejected by
the TLS WG (as OAEP for RSA key transport) in 2001 when an attempt was made to
piggyback it on top of AES adoption (in other words "if you want AES you have
to use RSA-OAEP with it", it couldn't even stand on its own merits).  I've
attached one vendor's reasoning for this at the end of this message, it talks
about AES which was the big deal at the time, substitute SHA-2 for AES to
update it to the current discussion.  RSA-KEM, yet another newer padding
scheme, was rejected by the S/MIME WG in 2002, as was OAEP.  There's another
scheme, Simple-RSA, which was proposed when the flaws in the OAEP proof were
discovered, that's also failed to see an adoption, as has SAEP and OAEP+.

>With a different algorithm, you have recently supported the opposite side of
>this argument. I argued that DSA is secure if you do X (use deterministic K);
>others (whom you've supported) argued that people won't do that, and will just
>use crypto libraries that generate K randomly.

Uhh, I never made any comment about deterministic DSA.  If I did, I would also
have argued against ECDSA, which has the same problem.  My point with DSA was
that continuing support for an algorithm that was more or less dead wasn't a
good idea.

>Except that SSH is a major protocol, and RSA is a major algorithm. If we use
>PSS, it's no longer oddball. Maybe we're not TLS, but SSH is not bush league.

It's no longer oddball, but it'll leave SSH stuck with something that no-one
else (meaning no other mainstream protocol) uses.  Redde Caesari quae sunt
Caesaris: The stated goal of this draft is to allow use of SHA-2 instead of
SHA-1, so that's what it should do.  If there's interest in introducing a new
signature scheme that's incompatible with the one that every version of SSH
for the last 20 years has been using then it should stand or fall on its own,
not piggybacked onto an update of hash algorithms.

I would be perfectly happy with a separate draft for RSA-PSS.  My sole
objection to it is having to implement a completely new signature mechanism
just to be allowed to use SHA-2.

Peter.

-- Snip --

1. Deploying AES-based ciphersuites is the primary goal

The AES block cipher provides a step up in security  from 3DES including
true 128 bit (and larger) keys, and a larger block size.  At the same
time, it provides increased performance across a wide set of platforms.

The definitions of the AES ciphersuites should introduce only the new
block cipher, not additional protocol or cryptographic mechanisms that
would complicate or delay deployment of AES.  If OAEP has benefits for
TLS it should be introduced as a separate ciphersuite using an existing
and established encryption mechanism such as 3DES.

2. RSA-OAEP is not required for security

In message to this list on 31 May, David Hopwood said:

"Using OAEP with TLS makes effectively no difference to the provable security
properties of the RSA ciphersuites, assuming that the method described in
section 7.4.7.1 of RFC 2246 is followed (i.e. the premaster secret is replaced
with a random value whenever the PKCS #1 v1.5 block is invalid).

The effect of that method is to prevent chosen ciphertext attacks in much
the same way as the "Simple RSA" scheme described in [Shoup01], which has
a tighter reduction from the RSA problem than OAEP does. To get the same
tightness of reduction when using OAEP in TLS, you would still have to
require that no information is leaked about whether the decryption of the
premaster secret succeeds or not."

So it seems that OAEP adds no benefit for TLS, since the suggested
method from RFC 2246 must be used in any case.

3. Adding RSA-OAEP adds complexity

Requiring RSA-OAEP for the AES ciphersuites means that implementations
will need to provide both RSA padding schemes.  In some situations the
extra code space and complexity won't be a problem, but some memory or
performance contrained devices would be better off without both
implemenations.  It is unlikely that AES-only deployments will be
possible in the near term, so devices will need to implement both old
and new methods for interoperability reasons.

4. Adding RSA-OAEP delays implementation

This requirement will delay the availability of the new ciphersuites for
two reasons. First, the time to implement the OAEP padding will delay
the availability of products with this capability.  Second, testing
independantly developed products will take longer since the
interoperability of both OAEP and the AES cipher will need to be tested.

5. Adding RSA-OAEP delays adoption of AES in hardware devices

Many services that use TLS rely on hardware devices to improve the
performance of TLS or to provide additional security.  These hardware
devices will need to be updated to provide both the AES cipher, and the
new RSA-OAEP encryption mechanism.  Hardware updates are typically less
frequent than updates for software packages, and

[6 = not-relevant TLS-specific issue]