Re: [TLS] TLS 1.3 draft-07 sneak peek

[[e-mail] (Martin Rex)]

Hanno Böck wrote:
> 
>> Hanno Böck wrote:
>>> On RSA there was only limited discussion, but I had the impression
>>> there is hardly an argument for not going with PSS
>> 
>> You seem to believe that RSA-PSS is better than PKCS#1 v1.5 signature
>> padding.  Could you elaborate why you believe this to be?
> 
> The most obvious reason is the Bleichenbacher signature forgery attack
> and related issues like BERserk.  I can hardly think how anything
> similar could happen with PSS.

Both are pure implementation issues, and the solution to both have been
well-known and specified several years before TLSv1.2:

http://tools.ietf.org/html/rfc3447#section-9.2

   This encoding method is deterministic and only has an encoding
   operation.

But the designers of TLSv1.2, who _newly_ added support for
BERserk-susceptible PKCS#1 v1.5 signatures failed to require
the known-safe approach.


>
> BERserk especially highlights a new problem of the old PKCS: Having a
> complex encoding (ASN.1) directly inside a cryptographic function seems
> like a bad idea.

No, BERserk highlights two other issues.  Reckless spec writers
in combination with superficial implementers.


> 
>> It was my impression that RSA-PSS adds complexity and slows down
>> things
> 
> The added complexity is limited. The performance probably is hardly
> measurable. It's a couple of added hash calculations. But if this is a
> real concern I can try to create some benchmarks.

As I've previously wrote about RSA-PSS, the real issue is not about
the transform specified in rfc3447, but about the PKIX policy crap
expected / associated with RSA-PSS, such as what rfc4055 says.

You typically have to change low-level crypto functions to be
able to pass along the crazy (and superflous) RSA-PSS algorithm
parameters around (and the parameters necessary to be able to
perform the expected policy checks).

ECDSA signatures are much easier to accomodate with existing APIs
(they have other problems).


-Martin