Subject: [TLS] PSS for TLS 1.3

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 Mar 2015 15:09:31 -0700

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. However, we could adopt
PSS for signatures outside of the certificate context. Roughly
speaking, we have three options:

1. Do not adopt PSS.
2. Adopt PSS as the only signature format for non-certificate
   signatures (but require acceptance of PKCS#1 1.5 for
   certificates)
3. Negotiate the use of PSS versus PKCS#1 1.5

Obviously, if we want to move to PSS, option #2 is simplest, but
the sentiment at the interim was to survey the WG to see whether
there was widespread enough support for generating and verifying
PSS to make this feasible [0].

Please use this thread to discuss.

-Ekr

[0] FWIW, this doesn't appear to be a problem for NSS.

---

From: Brian Smith <[email-masked]>
Date: Sun, 22 Mar 2015 15:53:40 -1000

> PSS to make this feasible [0].

PSS with which parameters?

My suggestion is that, if PSS is used, (SHA-256, MGF-SHA-256, 32-byte
salt) should be used with the SHA-256-based PRF and that (SHA-384,
MGF-SHA-384, 48-byte salt) should be used with the SHA-384-based PRFs.

[1] notes that there is a security advantage to using the same digest
function for the MGF as was used for digesting the signed data. It
would be a mistake to mandate support for MGF-SHA-1 in PSS signatures
in TLS 1.3, because a TLS 1.3 implementation shouldn't be need to
implement SHA-1 at all.

Some implementations are hard-coded to support only MGF-SHA-1 and 20
byte salts. It is better to require those implementations to be
updated than to require all implementations to implement SHA-1 just
for the MGF.

Cheers,
Brian

[1] https://tools.ietf.org/html/rfc3447#section-8.1

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 Mar 2015 20:21:01 -0700

> PSS with which parameters?

I would be fine with mandating a minimum of SHA-256.

-Ekr

---

From: Peter Bowen <[email-masked]>
Date: Sun, 22 Mar 2015 20:38:29 -0700

On Sun, Mar 22, 2015 at 3:09 PM, Eric Rescorla <[email-masked]> wrote:
> 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.  Currently there is no way to use PSS
signed certificates with TLS at all, which is a problem.  I agree with
the move to EC* as the preferred algorithm, but it seems like
enhancing non-EC signatures makes sense for the same reason as fixing
FFDHE.

Possibly the SignatureAlgorithm extension could carry both (1) rsa and
(tbd) rsa-pss?

Thanks,
Peter

---

From: Hanno Böck <[email-masked]>
Date: Mon, 23 Mar 2015 11:22:32 +0100

I'm glad this comes up. I wanted to push for it again, but didn't find
the time lately.

On Sun, 22 Mar 2015 15:09:31 -0700

>    signatures (but require acceptance of PKCS#1 1.5 for

+1

I think this totally makes sense. I think we should see Signatures for
PKI separately that for TLS (i.e. signing certificates versus signing
handshakes). Pushing PKI to support PSS can be done separately, but it
is probably much more difficult due to backwards compatibility issues.
But it doesn't need to happen inside the TLS 1.3 specification.
(and the tech / spec for doing so is already available)

I have some ideas how this should be done though. The PSS spec
currently allows a wide range of flexibility. It is for example in
theory possible to use two different hash functions within the same
signature (there's a hash and an mgf that's based on a hash). I think it
would make implementations much easier if the spec defined a
pre-defined set of sane parameters and doesn't allow the full
flexibility of PSS. Also - which seems obvious - the use of insecure
parameters (sha1, I'm looking at you) should be forbidden completely.

(and if this helps: I wrote my diploma thesis on pss a few years ago
and the nss implementation was originally written by me. I think I have
a pretty good idea about the issues surrounding PSS, if anyone feels
they have any questions I'm glad to try to answer them.)

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

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 23 Mar 2015 11:47:22 +0100

> 3. Negotiate the use of PSS versus PKCS#1 1.5

Does (3) imply the usage of signatureAlgorithms to negotiate? I guess
that's the more natural approach, as a client could support both RSA and
PSS_RSA at the same time.

However, that is complicated by the fact that new ciphersuites are
needed to use RSA_PSS on the end certificates. That's because the
ciphersuite name contains the type of the certificate of the peer.
I have argued about abolishing that [0].

Overall, I'm not sure how useful is a connection with PSS signature in
the handshake, but with a PKCS #1 1.5 signature in the certificate.
However, that looks like the only path to deprecate PKCS #1 1.5 and move
to PSS (if the WG thinks it's worth it).

regards,
Nikos

[0]. https://github.com/tlswg/tls13-spec/issues/98

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Mar 2015 08:13:16 -0500

On Sun, Mar 22, 2015 at 10:38 PM, Peter Bowen <[email-masked]> wrote:

> certificates are supported.

I would think that in option #2, we would also require support for this.

> Currently there is no way to use PSS

This seems like the obvious design if we opt for the negotiation route.

Best,
-Ekr

Thanks,

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 23 Mar 2015 14:12:05 +0000

> I think this totally makes sense. I think we should see Signatures for PKI
> separately that for TLS (i.e. signing certificates versus signing handshakes).
> Pushing PKI to support PSS can be done separately, but it is probably much
> more difficult due to backwards compatibility issues.

+1

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Mar 2015 15:31:11 -0400

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.

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.  So, I think that means the suggested signaling needs to provide a list of certificate signature algorithms that are supported, with a clear mandatory to implement.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Mar 2015 15:34:10 -0400

> (and the tech / spec for doing so is already available)

We want to accomodate the uptake of ECC, so ...

If RSA keys, then sign handshake with RSA-PSS.
If ECC keys, then sign handshake with ECDSA.

Russ

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 23 Mar 2015 19:42:26 +0000

Hi

On 23/03/2015 14:34, "Russ Housley" <[email-masked]> wrote:

>>PKI

Just a quick heads-up with my CFRG hat on. We should soon be making a
start over there on defining signature schemes for use with the curves
that we have now selected; our DH deliberations are nearing completion.

One quick question for this group: how important is it to you to have
ECDSA - or something very close to it (e.g. a derandomised version) - for
TLS use, and how much appetite is there for adopting schemes that deviate
more significantly from ECDSA (e.g. EdDSA)?

This question will surely be covered in forthcoming CFRG discussions as
well, but I think it's useful to ask the question here too, given that TLS
will be the first and primary customer for what we're working on in CFRG.

Cheers

Kenny

>
>Russ
>
>_______________________________________________
>TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tls

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 Mar 2015 19:11:28 +0200

> more significantly from ECDSA (e.g. EdDSA)?

My personal view (I have also looked at what this would take):
Not important, I would very much like a modern signature system (esp.
inversion-free[1]).

But I would want:
- Both curves usable in the same signature framework.
- Only use common hash function propeties for both curves[2], especially
  for verification interop[3].

Assignments required:
- TLS signaturealgorithm codepoint
- TLS namedcurve codepoints
- OIDs for the signature curves
- OIDs for PKIX (Signature,Hash) algorithm pair.

All can be done with RFC & expert review.

[1] Inversions are not only highly annoying to implement safe way,
but are also pretty slow.

[2] Good test: Does this work with standard-issue SHA-512?

[3] This is for the case if anything happens to the primary algorithm.

-Ilari

---

From: [email-masked] (Martin Rex)
Date: Thu, 26 Mar 2015 10:31:39 +0100 (CET)

> 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.

Most TLSv1.2 implementors seem to have delibertately (or accidentally)
ignored the botched semantics of the TLSv1.2 signature_algorithm extension
with respect to the signatures on certificates, however.

> 
> 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.

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.

> 
> 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.

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.

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.

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 26 Mar 2015 12:49:40 +0200

> 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.

> transform, but the policy crap described in rfc4055.

Well, it is PKIX...

> 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?

> 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...).

> 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.
 
> 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

---

From: Russ Housley <[email-masked]>
Date: Thu, 26 Mar 2015 11:40:12 -0400

> transform, but the policy crap described in rfc4055.

I do not know what you are referencing.  There are ways to limit a particular key to PSS if desired.

Russ