It is possible to DoS certificate validation with name constraints and/or a large number of candidate intermediates

[briansmith]

There is a DoS attack exploits the fact that name constraint checking, in particular, has quardratic (at least) behavior. If certificate A that chains to a certificate B and certificate A has a lot of names and certificate B has a lot of name constraints, then we do a lot of checking. BoringSSL's solution was to verify that the entire certificate chain is valid modulo name constraints, and then check name constraints. (TODO: verify that this summary of what they did is accurate.) We should do that or something better.

#68 might make this easier to do; regardless this and #68 interact with each other.

[briansmith]

See also golang/go#29233.

[briansmith]

I generalized this to cover two DoS-related issues that interact:

• Name constraint checking is quadratic, so a large number of names in certs and/or a large number of name constraints could cause serious issues.
• Path building is as bad or worse in the number of candidates certificates.

Both issues are compounded by signature verification being very expensive. They are inter-related because some solutions (e.g. naively doing path building sans name constraint checks before doing name constraint checks) seem to just shift the problem around.

However, it is also the case that anti-DoS countermeasures also have significant DoS side-effects of their own: See spiffe/spire#1004, for example. This issue is especially interesting because it likely motivates the implementation of AKI/SKI matching.

[Kixunil]

Would it be possible to backport the fix for people with MSRV issues?

[briansmith]

Would it be possible to backport the fix for people with MSRV issues?

0.22.2 was released with all the fixes so far, without the MSRV bump. 0.22.4 is the release that has the MSRV bump, IIRC. However, 0.22.2 is using an unsupported version of ring whereas 0.22.4 is using a supported version of ring.

Rust 1.61 was released 18 months ago.

[djc]

@Kixunil where are your MSRV constraints coming from? I feel like we're generally pretty conservative compared to most of the ecosystem.

[Kixunil]

The new version of rustls breaks my MSRV and it updates webpki from 0.21 to 0.22. So the problem is also related to semver breaking changes.

[briansmith]

The new version of rustls breaks my MSRV and it updates webpki from 0.21 to 0.22. So the problem is also related to semver breaking changes.

That's a separate issue to be discussed elsewhere.

Ultimately there's little getting around the need for MSRV 1.61 unless ring 0.17 reduces its MSRV. But at most that would be temporary, if it were to happen at all.

[Kixunil]

1.61 is fine, rustls has 1.64, I need 1.63 (Debian stable)

[djc]

1.61 is fine, rustls has 1.64, I need 1.63 (Debian stable)

So why do you need to stick to Debian stable? I doubt the ecosystem will stick to 1.63 very long.

BTW, I'm not sure where you're getting that rustls needs 1.64 -- rustls on main only just bumped 1.60 to 1.61.

@Kixunil I agree with @briansmith you should open a new issue to discuss your needs.

[briansmith]

1.61 is fine, rustls has 1.64, I need 1.63 (Debian stable)

ring's and webpki's MSRV is 1.61. If you are running into MSRV problems, they are probably elsewhere. Thanks for letting me know that Debian Stable has 1.63, that must be the rock bottom version of Rust we need to support.

[Kixunil]

So why do you need to stick to Debian stable?

I and other people explained this already multiple times in various places, among other things: dissatisfactory security of rustup.

rustls needs 1.64 -- rustls on main only just bumped 1.60 to 1.61.

Oh, it must be tonic then which itself depends on rustls. I will investigate and open an issue s suggested.