Re: [TLS] Using RSA PSS in TLS

On Wed, Jan 14, 2015 at 4:31 PM, Hanno Böck <hanno@hboeck.de> wrote:
> On Wed, 14 Jan 2015 15:32:42 +0100
> CodesInChaos <codesinchaos@gmail.com> wrote:
>
>> 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.
>
> 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.

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.

>
>
> [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/
>
> mail/jabber: hanno@hboeck.de
> GPG: BBB51E42
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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