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

From: Peter Gutmann <[email-masked]>
Date: Mon, 14 Oct 2013 10:58:57 +0000

=?UTF-8?B?SGFubm8gQsO2Y2s=?= <[email-masked]> writes:

>legacy compatibility is exactly the point. Implementations must be prepared
>to communicate to servers / clients that do not support the new version.

Never underestimate that amount of weight that carries.  There was an attempt,
some years ago, to mandate RSA-PSS for certificates.  It met with pretty much
universal rejection, to the extent that people would probably ignore the
requirement even if it was made a MUST in the spec (at the time it was
described as "X9.42 all over again", a reference to another MUST that everyone
ignored), and as a result was dropped.

The problem with -PSS is that it doesn't real fix anything in -1.5 (I know
it's *theoretically* better, but unless you do -1.5 really badly there's no
practical weakness that would encourage an upgrade).  Counting against that is
the near-insurmountable cost of a changeover (everyone has to redeploy global
crypto infrastructure from scratch).

Peter.

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 14 Oct 2013 11:08:59 +0000

Since ECDHE_RSA or DHE_RSA says that the Server public key is RSA, the SPKI in the Server certificate would indicate it is RSA 1.5 or PSS and you do not need additional cipher suites.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Gutmann
Sent: Monday, October 14, 2013 6:59 AM
To: <[email-masked]>
Subject: Re: [TLS] Using RSA PSS in TLS

=?UTF-8?B?SGFubm8gQsO2Y2s=?= <[email-masked]> writes:

>legacy compatibility is exactly the point. Implementations must be 
>prepared to communicate to servers / clients that do not support the new version.

Never underestimate that amount of weight that carries.  There was an attempt, some years ago, to mandate RSA-PSS for certificates.  It met with pretty much universal rejection, to the extent that people would probably ignore the requirement even if it was made a MUST in the spec (at the time it was described as "X9.42 all over again", a reference to another MUST that everyone ignored), and as a result was dropped.

The problem with -PSS is that it doesn't real fix anything in -1.5 (I know it's *theoretically* better, but unless you do -1.5 really badly there's no practical weakness that would encourage an upgrade).  Counting against that is the near-insurmountable cost of a changeover (everyone has to redeploy global crypto infrastructure from scratch).

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

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 14 Oct 2013 11:19:20 +0000

Oops.  My bad.  I mixed up signature algorithms with SPKI.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Gutmann
Sent: Monday, October 14, 2013 6:59 AM
To: <[email-masked]>
Subject: Re: [TLS] Using RSA PSS in TLS

Peter.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 14 Oct 2013 12:19:12 +0100

> Since ECDHE_RSA or DHE_RSA says that the Server public key is RSA, the SPKI in the Server certificate would indicate it is RSA 1.5 or PSS and you do not need additional cipher suites.

But, when the server is deciding which of its 1 or more certs to send, 
how can it tell whether or not the client supports PSS?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 14 Oct 2013 11:21:48 +0000

Rob,

I was in error in the first place.  So, the original question remains of how to tell each other of PSS.

-----Original Message-----
From: Rob Stradling [mailto:[email-masked]] 
Sent: Monday, October 14, 2013 7:19 AM
To: Santosh Chokhani; <[email-masked]>
Subject: Re: [TLS] Using RSA PSS in TLS

> Since ECDHE_RSA or DHE_RSA says that the Server public key is RSA, the SPKI in the Server certificate would indicate it is RSA 1.5 or PSS and you do not need additional cipher suites.

But, when the server is deciding which of its 1 or more certs to send, how can it tell whether or not the client supports PSS?

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 14 Oct 2013 14:19:42 +0200

> Oops.  My bad.  I mixed up signature algorithms with SPKI.

If the certificate contains id-RSASSA-PSS (RFC 4055) in SubjectPublicKeyInfo, the client could tell, but there are
several issues with that approach:
- The use of id-RSASSA-PSS is optional
- The specification of the PSS-parameters in id-RSASSA-PSS is optional (RFC 5756)
- Most implementations don't support id-RSASSA-PSS (see http://rsapss.hboeck.de/rsapss-1.0.2.pdf)

As far as I understand RFC 5246, the Server Key Exchange message specifies the signature algorithm only by the enum {
dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa, ...}.

Johannes

-- 
Johannes

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 28 Oct 2013 13:29:07 +0100

> I was in error in the first place.  So, the original question remains of how to tell each other of PSS.

In TLS 1.2, the "signature_algorithms" extension is used to signal the supported / requested signature algorithms by
both client and server. In order to support PSS in that extension, a new code point (or several, depending on the PSS
parameters to be supported) had to be assigned in the corresponding IANA registry.
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16

IMO it is not necessary to define new cipher suites. The semantics of "RSA" in cipher suites (and KeyExchangeAlgorithm
indicated in the the server key exchange messages) could be widened to comply with both PKCS#1v1.5 and PSS, and the use
of PSS would be defined eligible only if it has been signaled in the "signature_algorithms" extension by the other peer.
Likewise, the semantics of RSA in the certificate_types field in the Certificate Request message could be clarified that
an rsa key may refer to SPKI rsaPublicKey (general RSA key) as well as to SPKI id-RSASSA-PSS (PSS key), but that
PSS-keys are eligible only if PSS had been listed by the client in the signature_algorithms extension.

Thus, the changes seem limited and backward interoperability would be preserved in the specs.

Although the definition of new code points in the TLS SignatureAlgorithm Registry does not necessarily require a
standards track RFC, I am not sure if the change / extension of existing semantics in TLS 1.2 doesn't require the
standard track anyway.

Johannes

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 28 Oct 2013 14:27:47 +0100

> of PSS would be defined eligible only if it has been signaled in the "signature_algorithms" extension by the other peer.

The signature algorithm that was actually used is specified (within a DigitallySigned struct) by an
SignatureAndHashAlgorithm identifier of the same type as used in the "signature_algorithms" extension. Thus, the code
points in this registry can be used for both signaling support of PSS and specifying the PSS as the signature algorithm
that was actually selected.

-- 
Johannes