Intent to Implement and Ship: RSA-PSS for TLS

[David Benjamin]

Contact emails

davi...@chromium.org, nha...@chromium.org, sva...@chromium.org

Spec

https://tools.ietf.org/html/draft-ietf-tls-tls13-15#section-4.2.2

https://tools.ietf.org/html/rfc3447

(TLS, so W3C TAG review not applicable)

Summary

Among many other changes, TLS 1.3 will revise the signature algorithms mechanism and switch from RSASSA-PKCS1-v1_5 to RSASSA-PSS (also known as RSA-PSS). While our TLS 1.3 implementation is still in progress, we intend to ship the new signature algorithms to our TLS 1.2 implementation early.

Motivation

RSA-PSS has a security proof and avoids a number of problems with the older ad-hoc RSA signature algorithm, so it is used in TLS 1.3 and QUIC. This will make it available to TLS 1.2 as well.

More importantly, this is the first time in the history of TLS that we have added new signature algorithms. Although the protocol allows for new algorithms to be added, unexercised joints tend to rust shut as buggy software is deployed to the ecosystem unnoticed. By shipping this part of TLS 1.3 early, we hope to pave the road for this part of the new protocol. (Or perhaps we will learn of insurmountable ecosystem problems and need to change the protocol.)

Interoperability and Compatibility Risk

RSASSA-PKCS1-v1_5 signatures will still be accepted over TLS 1.2, so correct TLS stacks will continue to work as before. TLS parameters are negotiated, so it is, in theory, safe to add new ones. As noted, in reality, servers may always have unnoticed bugs. We are aware of one affected implementation which was fixed a year ago. Data from scanning a list of top sites suggests the impact should be small enough to overcome (35 hosts out of about 500,000). We will reach out to affected sites and monitor the change as it progresses through Chrome’s release channels.

There is well-established consensus that TLS 1.3 will use RSA-PSS and RSA-PSS itself was specified over 10 years ago, so needing to change things is unlikely. Should that still happen, parameter negotiation means the chances of a server depending on our early deployment is negligible. Such servers would not interoperate with any other client.

Ongoing technical constraints

None. RSA-PSS will be needed for TLS 1.3 anyway, and the new signature algorithm mechanism makes things cleaner than before. This will further simplify our code by removing our version-dependent signature algorithms list.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

https://crbug.com/642416

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5748550642171904

Requesting approval to ship?

Yes

[Mike West]

This plan LGTM. The fallback properties seem reasonable, and in case something goes wrong, this gives us an opportunity to feedback into 1.3 before it's carved into an RFC. Will you be shipping an off-switch to remove the new signature from the negotiation, just in case things explode in some messy way?

-mike

[David Benjamin]

We've never actually had to use any of those emergency shut-off switches we keep putting in. Since it's so early in the release process and we didn't find very many problematic hosts (from checking WHOIS, two companies cover around half of the 35 hosts---I was going to start reaching out once the change is in Chrome Canary so they have something to test against), I figured we'd see how things look on Canary and Dev first and, if it looks risky, go through the trouble of routing a knob here before branch.

(BoringSSL doesn't even let you configure signature algorithms right now. We were just going to add it to BoringSSL by default like we did for X25519, so we'll also have early warning from other BoringSSL consumers in Google. Although Chrome is certainly the primary indicator of ecosystem issues.)

[Jochen Eisinger]

Do you have some idea about how many enterprises might rely on this for internal hosts? Would it be easy to rip this out again late in the beta phase (as that's usually the earliest we hear back from enterprises...)?

[David Benjamin]

We can't really know without shipping it. This isn't enterprises relying on an old feature. It's their software having a parsing bug. We can never truly know the impact without trying things. It's just baseline risk to deploying new features. Imagine if some server couldn't handle new HTTP headers with more than two hyphens. We won't find that out without trying.

(Once other things in my queue clear up, I'll send out another Intent later this week or next which hopes to lower this baseline risk in the future. But it won't be able to help this one.)

Ripping it out would be very easy. The change is pretty small. (It's just enabling something by default rather than gating it on enabling our in-progress TLS 1.3 code.)

[Mike West]

I buy it. Launching and seeing what happens SGTM.

-mike

[Chris Harrelson]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Jochen Eisinger]

lgtm2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

LGTM3

lgtm2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[David Benjamin]

A quick update: we got a report that the new SignatureSchemes in TLS 1.3 actually conflict with a MUST-level requirement in TLS 1.2, and this was breaking a WebRTC DTLS implementation. This is easily fixed by renumbering to avoid TLS 1.2 values. The latest revision of the TLS 1.3 spec has been updated, and we will be using those values instead:

https://tlswg.github.io/tls13-spec/#rfc.section.4.2.3

Yay for finding problems out before the spec is finalized.

Details for those curious: In TLS 1.2, a signature algorithm was a pair of uint8s, a HashAlgorithm and a SignatureAlgorithm. This decomposition isn't universal (Ed25519 does not have a prehash) and doesn't capture everything you'd like (ECDSA has both a curve and a hash), so for TLS 1.3 we are replacing with a uint16 SignatureScheme. The old pairs are strategically allocated as SignatureSchemes to align with the old hash/sig pairs and we reserve all values corresponding to known HashAlgorithms so there would be no confusion.

However, it turns out TLS 1.2 had a MUST-level requirement that clients do not advertise hash/sig pairs which use sig = anonymous (0) and rsa_pss_sha256 was allocated as 0x0700. The fix is simply to also reserve anything which ends in 0x00 to 0x03 and allocate avoiding those. Then new SignatureSchemes will read as unknown hash *and* unknown signature, so they'll be ignored.

LGTM3

lgtm2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.