Re: [TLS] PSS for TLS 1.3

[Ilari Liusvaara <[e-mail]>]

On Thu, Mar 26, 2015 at 10:31:39AM +0100, Martin Rex wrote:
> Russ Housley wrote:
> > 
> > On Sun, Mar 22, 2015 at 10:38 PM, Peter Bowen <[e-mail]> wrote:
> > On Sun, Mar 22, 2015 at 3:09 PM, Eric Rescorla <[e-mail]> wrote:
> >> During the interim we discussed discussion about adopting PSS for
> >> RSA signatures in TLS 1.3.
> >>
> >> Clearly, we will not be able to just adopt PSS because certificates
> >> will continue to be signed with PKCS#1 1.5.
> > 
> > I would like to see TLS 1.3 allow certificates signed using PSS (RFC
> > 4055 and 3447) and provide a way to signal the server that such
> > certificates are supported. 
> 
> Originally, using certificates signed with PSS "just works" with SSLv3
> and TLS, provided that the PKI-implementation called by the TLS stack
> implements it. (openssl-0.9.8 does not,  Windows XP & 2003 do not).
> 
> A problem was newly created in 2008 specifically for TLSv1.2 by the
> botched semantics of the TLSv1.2 signature_algorithms TLS extension,
> which conflates the algorithms used for "digitally_signed" within the
> TLS protocol and the algorithms used by CAs to issue certs.

You mean "MUST be the same" semantics, deliberately banning PSS (I think
I saw that in some place) or one can't assume that what can be validated
as digitally_signed can be validated as cert signature?

<semantics being ignored>

BTW: I saw one TLS stack (AFAIK, it was TLS 1.2 capable) that had no
problem using RSA key for the server certificate and DSA key for the
client certificate (or vice versa)... Dunno how complant that is.

> > I have wanted to see migration of signatures on certificates from
> > PKCS#1 v1.5 to PSS for many years.  I think this is a nice step for
> > that to happen.
> 
> The major problem with RSA-PSS is not the PKCS#1 v2.1 RSA-PSS signature
> transform, but the policy crap described in rfc4055.

Well, it is PKIX...

> To reliably support RSA-PSS in TLS, we would have to first fix the TLSv1.2
> signature_algorithms extension by replacing it with one that uses
> resonable semantics and clearly seperates the digitally-signed transform
> within the TLS protocol from the signatures on X.509 certificates,
> otherwise the installed base would have to limit itself to at most TLSv1.1.

So one can't assume the client supports the same algos for both?

> > 
> > That said, I'd like to see this done in a way that also encourages the
> > transition to ECDSA for the signatures on the certificates.
> 
> ECDSA is a well-known flawed signature scheme, and from the attacks
> that have been published, there currently seems to exists no implementation
> that will not leak the private key through online signatures.  And for
> verification of offline signatures, RSA is much faster.

Well, on low security levels it is much faster. On high level it becomes
slower (unless ECC gets broken).
 
ECDSA is very difficult to implement just without having timing attacks
out the wazoo[1]. And looking at internal strucure of P-256, that makes
it even more difficult (Weierstrass, bad order, etc...).

> Considering that NSA has been pushing ECDSA with NSA curves intensively
> long before the Snowden leaks, it would be silly to assume that their
> curves are not backdoored.

Also, (EC)DSA was inferrior to state-of-the-art already when it was
proposed. And the reasons why are AFAIK classified.
 
> We currently won't loose anything (of value) by obsoleting the ECDSA
> signature scheme and deprecating the NSA curves, by moving to safe curves
> and a less dangerous signature scheme than ECDSA.

Well, some do have to use it... But most don't.


[1] I _think_ I have done so once. It was quite slow and pulled off
invented-less-than-10-years-ago tricks with ECC that won't work with
NIST/NSA curves.

And I was specially taking timing attacks into consideration. Somebody
who doesn't know about this stuff won't even stand a chance.

 

-Ilari