Subject: Re: [TLS] Using RSA PSS in TLS

From: Florian Weimer <[email-masked]>
Date: Wed, 14 Jan 2015 15:15:53 +0100

On 10/14/2013 10:39 AM, Johannes Merkle wrote:
> While the current discussion on this list is about ECC, I would like to raise the question if it were not desirable to
> allow usage of provably secure RSA-PSS signatures from PKCS#1v2.1 in TLS.

So it seems that using RSA-PSS is difficult (although CAs could offer to 
issue multiple certificates which could be switched as needed if a 
server operator doesn't want to make both RSA-PSS signatures and PKCS#1 
1.5 signatures).

What about changing PFS for the RSA ciphersuites so that they continue 
to use RSA encryption, and not rely on an RSA signature for server 
authentication?  From my point of view, this removes one major objection 
to enabling PFS (namely, as it stands now, it's a completely different 
protocol, potentially with drastically different security properties).

-- 
Florian Weimer / Red Hat Product Security

---

From: CodesInChaos <[email-masked]>
Date: Wed, 14 Jan 2015 15:32:42 +0100

On Wed, Jan 14, 2015 at 3:15 PM, Florian Weimer <[email-masked]> wrote:
> What about changing PFS for the RSA ciphersuites so that they continue to
> use RSA encryption, and not rely on an RSA signature for server
> authentication?

Switching from PKCS#1v1.5 encryption to OAEP is just as tricky as
switching from PKCS#1v1.5 signing to PSS signatures.

I consider the risk of PKCS#1v1.5 encryption far bigger than the risk
of PKCS#1v1.5 signatures.
I'm not aware of any attack against  PKCS#1v1.5 signatures, they
merely lack a security proof.
PKCS#1v1.5 encryption is problematic since detectable decryption
failures can act as an oracle. Implementations need to be really
careful to avoid these.

---

From: Fedor Brunner <[email-masked]>
Date: Wed, 14 Jan 2015 18:23:19 +0100

Better solution would be to use RSA-KEM (see basic description in RFC
5990) instead of PKCS#1v1.5 encryption.

The RSA-KEM is secure in the random oracle model (modelling the KDF as a
random oracle), with very good security guarantees:

Johan Hastad and Mats Naslund. The security of all RSA and discrete log
bits.
http://www.nada.kth.se/~johanh/hnrsaacm.pdf

Victor Shoup. A Proposal for an ISO Standard for Public Key Encryption.
https://eprint.iacr.org/2001/112.pdf

On 14.01.2015 15:32, CodesInChaos wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hanno Böck <[email-masked]>
Date: Thu, 15 Jan 2015 01:28:15 +0100

On Wed, 14 Jan 2015 15:15:53 +0100
Florian Weimer <[email-masked]> wrote:

> > While the current discussion on this list is about ECC, I would
> > like to raise the question if it were not desirable to allow usage
> > of provably secure RSA-PSS signatures from PKCS#1v2.1 in TLS.
> 
> So it seems that using RSA-PSS is difficult (although CAs could offer
> to issue multiple certificates which could be switched as needed if a 
> server operator doesn't want to make both RSA-PSS signatures and
> PKCS#1 1.5 signatures).

There's nothing difficult about PSS.
Sure, it is not "nice" to use the same key for PKCS #1 1.5 and 2.1. But
I'm not aware of anything even close to an attack, it's "just" good
cryptographic practice.

Right now TLS uses the same key for encryption and signatures, which is
basically the same problem. Nobody has raised this as an issue ever
as far as I'm aware.

We should simply switch to PSS. I plan to submit a pull request to do
that as soon as I find time for it.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Hanno Böck <[email-masked]>
Date: Thu, 15 Jan 2015 01:31:49 +0100

On Wed, 14 Jan 2015 15:32:42 +0100

> merely lack a security proof.

Bleichenbacher's signature forgery attack [1], which has recently been
re-discovered in combination with some ASN.1 issues under the name
BERserk [2].

Sure, these are "mere implementation issues". You can do PKCS #1 1.5
signatures right - just like you can do PKCS #1 1.5 encryption right.
It's just that people did it wrong multiple times. I don't see simliar
risks with PSS, it's the much more robust solution.

[1] https://www.ietf.org/mail-archive/web/openpgp/current/msg00999.html
[2] http://www.intelsecurity.com/advanced-threat-research/
-- 
Hanno Böck
http://hboeck.de/

---

From: [email-masked] (Martin Rex)
Date: Thu, 15 Jan 2015 01:50:32 +0100 (CET)

Hanno Böck wrote:

[ Charset UTF-8 unsupported, converting... ]
> risks with PSS, it's the much more robust solution.

The problem really is the original bogus approach how to _verify_
PKCS#1 v1.5 signatures.
If the spec was tightened to prohibit *all* kinds of parsing
of the RSA-decrypted BT01 padding signature plaintext,
and instead required rebuilding of the BT01 padding from the input hash
value and input hash oid, and comparison of the newly composed result
with what the RSA decryption returned, then none of the parser problems
for RSA PKCS#1 v1.5 signatures would have existed.

That approach to RSA signature verification is actually the one
recommended by PKCS#1 v2.1 for the RSASSA-PKCS1-V1_5-VERIFY operation.

  https://tools.ietf.org/html/rfc3447#section-8.2.2

And given its age (rfc3447 was published in February 2003),
the more robust verification _could_ have been required for
TLSv1.1 (2006) and TLSv1.2 (2008), but such improvements seem
to have been rotting in the same forgotten drawer as Serge Vaudenay's
proposed fix to the CBC mac-pad-encrypt weakness...

-Martin

---

From: Geoffrey Keating <[email-masked]>
Date: 14 Jan 2015 18:11:18 -0800

>   https://tools.ietf.org/html/rfc3447#section-8.2.2

Would this actually work?  I suspect implementations use slightly
inconsistent padding generation...

---

From: Watson Ladd <[email-masked]>
Date: Thu, 15 Jan 2015 10:38:39 -0800

> risks with PSS, it's the much more robust solution.

You *cannot* do PKCS 1.5 encryption right. The countermeasures to
Bleichenbacher depend on enforcing additional structure on the
messages, which SSL imposed by accident. As everyone should know, many
implementations still do not get this right. (Can't name which ones,
but even if they make the check, they may expose timing channels that
are exploitable: there was a German PhD thesis a year or two ago that
investigated exactly this, and broke some Java implementations).

Implementors are clearly not reading the documents we produce in a
more than cursory manner: RFC 2437 tells you exactly how to avoid
these issues, and refers to papers explaining how bad things can go.
That was in 1998! Yet we still see bugs in PKCS 1.5 signature
verification caused by not following the spec.

RSA-OEAP has similar error oracle issues,
https://www.iacr.org/archive/crypto2001/21390229.pdf. It's a moot
point because we aren't using an RSA encryption based method in TLS
1.3, but there is an obviously secure alternative in the ROM, namely a
variant of RSA-KEM, which doesn't have these implementation issues.

We need to think in terms of "how badly is the coder who writes things
going to mess up" when designing, and check that the actual deployed,
running code, is doing the right thing. The downgrade dance is an
example of something that should have been visible years ago. RC4
insecurity was known in 2001. POODLE is in a text document from 2004.
Encrypt-then-MAC was since 2000-20001, and we didn't properly fix it
for 13 years afterward.

In terms of the original thread necromancy, yes, the security
properties are different: one set has PFS. I'm not sure what
properties are being discussed, especially given that we now know
almost everything about TLS's actual security, that make changing
tough.

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 16 Jan 2015 12:09:05 +0100

> investigated exactly this, and broke some Java implementations).

Jager, Schinzel and Somorovsky also showed how XML encryption is vulnerably and there was also this report about
practical attacks against hardware implementations:
https://eprint.iacr.org/2012/417

-- 
Johannes

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Fri, 16 Jan 2015 13:52:25 +0100

> inconsistent padding generation...
Appparently [1] NSS and BoringSSL has been doing that for a few months now
(though NSS seems to take steps to allow some variation), maybe they could
provide some feedback?

[1]: https://www.imperialviolet.org/2014/09/26/pkcs1.html

Manuel