Subject: [TLS] RSA-PSS in TLS 1.3

From: Joseph Salowey <[email-masked]>
Date: Mon, 29 Feb 2016 09:32:04 -0800

We seem to have good consensus on moving to RSA-PSS and away from PKCS-1.5
in TLS 1.3.  However, there is a problem that it may take some hardware
implementations some time to move to RSA-PSS.  After an off list discussion
with a few folks here is a proposal for moving forward.

We make RSA-PSS mandatory to implement (MUST implement instead of MUST
offer).   Clients can advertise support for PKCS-1.5 for backwards
compatibility in the transition period.
Please respond on the list on whether you think this is a reasonable way
forward or not.

Thanks,

J&S

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 29 Feb 2016 17:39:45 +0000

> Please respond on the list on whether you think this is a reasonable way

My instinct is to mandate PSS and let PKCS#1 rest in peace.

-- 
	Viktor.

---

From: Hanno Böck <[email-masked]>
Date: Mon, 29 Feb 2016 19:00:21 +0100

On Mon, 29 Feb 2016 09:32:04 -0800
Joseph Salowey <[email-masked]> wrote:

> Please respond on the list on whether you think this is a reasonable
> way forward or not.

I recently already saw the message here asking for PKCS #1 1.5
compatibilty and was quite angry about it, but as there wasn't much
discussion I thought this issue would go away. It seems it did not.

RSA-PSS was specified as RFC 3447 in 2003. That was 13 years ago.

Therefore we can conclude:
* Whoever created that hardware implementation either did so more than
  13 years ago (probably unlikely) or deliberately created hardware
  crypto with sub-standard algorithm support.
* This can mean a couple of things:
a) The hardware vendor knew about it and expected that they could
prevent a move to RSA-PSS by lobbying standardization bodies (this is
what they seem to do right now). In this case they deliberately want to
weaken security and that behavior should not be encouraged.
b) They didn't know about RFC 3447. That probably means they shouldn't
develop crypto products at all.
c) Something else?
whatever the reason was, I can't find any reason I would find in any
way acceptable. I think the TLS working group should not encourage such
vendor behavior. Instead I think the opposite should happen: A clear
statement that deploying sub-standard crypto technologies isn't
acceptable and whoever does it has to expect breakage in the future.

TLS suffered a lot in the past from misguided attempts to provide
backwards compatiblity to weak algorithms. Most of the fancy
named vulns in the past years can somehow be traced back to this
problem.

PKCS #1 1.5 is a real problem. The last PKCS #1 1.5 signature related
vuln that could've been prevented by using RSA-PSS was found 2 months
ago [1]. The last one in a major implementation (BERserk) was in 2014.

tl;dr: I don't think supporting PKCS #1 1.5 in TLS 1.3 is reasonable.
Let's not repeat the mistakes from the past.

[1]
https://blog.filippo.io/bleichenbacher-06-signature-forgery-in-python-rsa/

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

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

---

From: Benjamin Beurdouche <[email-masked]>
Date: Mon, 29 Feb 2016 19:10:54 +0100

> Let's not repeat the mistakes from the past.

I agree, we started 1.3 by removing old and deprecated stuff. We should not allow it now and risk weakening our work...

B.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 29 Feb 2016 20:48:34 +0200

> On 29 Feb 2016, at 7:39 PM, Viktor Dukhovni <[email-masked]> wrote:
> 

+1

As always, certificates are fine to be signed with PKCS#1, because we are not specifying certificate signatures, but in-protocol signatures *are* up to us. 

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Mon, 29 Feb 2016 20:53:33 +0200

> On 29 Feb 2016, at 8:00 PM, Hanno Böck <[email-masked]> wrote:
> 

Yeah, such as all of their customers are using PKCS#1 because that is what everybody uses in all current versions of TLS and several other protocols?

Regardless, hardware vendors should rejoice. We’re giving their customers a good reason to buy new hardware.

Yoav

---

From: Brian Smith <[email-masked]>
Date: Mon, 29 Feb 2016 09:00:54 -1000

> Please respond on the list on whether you think this is a reasonable way

I agree with the others that TLS should use exclusively RSA-PSS (with all
the parameters fixed according to the digest function used to digest the
data) when RSA is used in the protocol. Implementations that can't support
PSS in hardware can either implement it in software or use ECDSA or keep on
using TLS 1.2.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 29 Feb 2016 11:04:38 -0800

On 02/29/2016 09:32 AM, Joseph Salowey wrote:
> We seem to have good consensus on moving to RSA-PSS and away from 
> PKCS-1.5 in TLS 1.3.  However, there is a problem that it may take 
> some hardware implementations some time to move to RSA-PSS.  After an 
> off list discussion with a few folks here is a proposal for moving 
> forward.
>

I think that supporting PKCS1.5 fallback is the right thing to do for 
faster adoption of TLS 1.3, as specified above.

PKCS #1.5 is allowed by 
https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-6.3.2.1 in 
X.509 certificates. X.509 certificate chain is a part of TLS handshake. 
The above proposal is about not restricting one type of signature, the 
end-entity signature, to PSS. This applies to client authentication, 
server authentication, or both.

Without a generous advance warning about PKCS#1.5 removal by TLS 1.3, we 
have to deal with already deployed hardware. Had vendors and customers 
knew that TLS 1.3 will remove PKCS #1.5, we probably would have ended up 
with more PSS-friendly Internet. PKCS#1.5 is still fine for FIPS 140, 
Common Criteria, and in CA certificates in TLS 1.3.

The WG can chose to remove PSS from one type of signature in TLS1.3. The 
affected implementations will need to cap negotiation at TLS 1.2.

For more details: 
https://www.ietf.org/mail-archive/web/tls/current/msg19096.html

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 29 Feb 2016 19:15:49 +0000

I originally was okay with the proposal, but Brian made me think about the timeline.  And I liked Yoav’s sentiment ☺
RSA-PSS only for TLS 1.3

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 29 Feb 2016 12:35:57 -0800

On 02/29/2016 09:32 AM, Joseph Salowey wrote:
 > PKCS-1.5 in TLS 1.3.  However, there is a problem that it may take some
 > hardware implementations some time to move to RSA-PSS.  After an off
 > list discussion with a few folks here is a proposal for moving forward.
 >

I think that supporting PKCS1.5 fallback is the right thing to do for 
wider adoption of TLS 1.3, as specified above.

PKCS #1.5 is allowed by 

Without a generous advance warning about PKCS#1.5 removal by TLS 1.3, we 
have to deal with already deployed hardware. Had vendors and customers 
knew that TLS 1.3 will remove PKCS #1.5, we probably would have ended up 
with more PSS-friendly Internet. Even now PKCS#1.5 is allowed by FIPS 
140, Common Criteria, and in CA certificates in TLS 1.3, and earlier TLS.

The WG can chose to remove PSS from one type of signature in TLS1.3. 
This will result in affected implementations capping negotiation at TLS 
1.2. There is no other fix in some cases.

For more details: 

(I posted earlier, but don't see the message. Sending this one more 
time, slightly edited)

---

From: Dave Garrett <[email-masked]>
Date: Mon, 29 Feb 2016 17:28:06 -0500

> wider adoption of TLS 1.3, as specified above.

I think it's long past the time where everyone has to acknowledge that within protocols, there's no such thing as a "fallback" specified as an option. There's simply allowed and not allowed, with the former having no incentive to go away. Arguing to keep it now is equivalent to arguing to keep it forever.

Dave

---

From: Hanno Böck <[email-masked]>
Date: Mon, 29 Feb 2016 23:36:17 +0100

On Mon, 29 Feb 2016 12:35:57 -0800
Andrey Jivsov <[email-masked]> wrote:

> Without a generous advance warning about PKCS#1.5 removal by TLS 1.3,
> we have to deal with already deployed hardware. Had vendors and
> customers knew that TLS 1.3 will remove PKCS #1.5, we probably would
> have ended up with more PSS-friendly Internet.

Ok, look, I really would like to understand what you're trying to say
here.

What would such a warning look like? We have an RFC for PSS since 2003.
We had several attacks showing the weakness of PKCS #1 1.5. Wasn't that
warning enough? If not, how would such a warning look like? I'd really
like to know, because we will have similar situations in the future
and I'd like to avoid people lobbying in the background to continue
supporting weak crypto.

There will be some new TLS version some day and we will try to get
better algorithms into it. So how do we warn you next time?

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

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 29 Feb 2016 20:52:11 -0800

On 02/29/2016 02:36 PM, Hanno Böck wrote:
> We have an RFC for PSS since 2003.
> We had several attacks showing the weakness of PKCS #1 1.5.

In the face of such danger, what's your opinion on PKCS #1.5 signatures 
being perfectly fine in TLS 1.3 ? I refer to signatures in X.509 certs 
in the latest https://tools.ietf.org/html/draft-ietf-tls-tls13-11.

Why not ban PKCS #1.5 altogether from TLS 1.3? It will not only make TLS 
1.3 more secure, but code simpler and footprint smaller. Besides, it's 
reasonable: TLS 1.2 already allows PSS in X.509 certs.

You are arguing for the benefit of suddenly mandating a steel door on a 
grass hut. Joseph Salowey's proposal gives an option for the door, 
consistent with how TLS 1.2 does this for X.509 certs.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 1 Mar 2016 15:56:53 +1100

>From my perspective, this is fine.  I would like to say that we won't
ever support PKCS#1.5 for TLS 1.3, but I think that I would rather
have users on 1.3 with PKCS#1.5 than have them stuck on 1.2.

It seems like others are taking the position that we should say "MUST
NOT use PKCS#1.5".  I would love for that to be the case, but I want
to separate decision path for that, preferably one that is somewhat
under my control.  Once we have information about usage for each
signature scheme, I'll be happy to arrange for another "break the web"
day.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 1 Mar 2016 04:59:47 +0000

> signature scheme, I'll be happy to arrange for another "break the web"

It is much easier to mandate PSS in TLS 1.3 now, than to remove it
later.  Servers that can't do PSS will use TLS 1.2.  This avoids
a break-the-web day.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 1 Mar 2016 05:06:47 +0000

> later.  Servers that can't do PSS will use TLS 1.2.  This avoids

Sorry, ... than to remove *PKCS#1.5* later ...

-- 
 	Viktor.