Matt Corallo [Tue, 9 Jul 2024 20:33:37 +0000 (20:33 +0000)]
Ignore spurious `RRSig`s which sign `DNSKEY`s with a ZSK
There's no reason to include an `RRSig` signing `DNSKEY`s with a
ZSK - validators only care about the KSK signing `DNSKEY`s, hence
*Key*-Signing Key. However, OVH appears to include such signatures
anyway, which we must ignore.
Here we do so by pre-filtering the `RRSig`s we try to validate by
key tag before calling `verify_rrsig`. This causes us to calculate
the key tag a few extra times, but that's not a huge deal.
Matt Corallo [Tue, 21 May 2024 16:17:37 +0000 (16:17 +0000)]
Limit the number of validation steps we'll take
While proofs should be rather computation-time-limited through
limits on their size, its still nice to limit proof validation time
more directly through the same constant we already do to limit
proof construction complexity.
Matt Corallo [Wed, 21 Feb 2024 07:14:20 +0000 (07:14 +0000)]
Make `write_u16_len_prefixed_data` generic over the type of output
In the next commit this will be used to write RRs directly into
hashers when validating signatures, rather than serializing them
into `Vec`s then hashing.
Matt Corallo [Mon, 4 Mar 2024 03:22:08 +0000 (03:22 +0000)]
Swap `ring` for our own in-crate ECDSA validator
While `ring` is great, it struggles with platform support and has a
fairly involved dependency tree due to its reliance on C backends.
Further, while the `RustCrypto` org tries to stick to Rust, in
doing so it takes on more (unnecessary) dependencies and has a
particularly unusable MSRV policy. Finally, its contributor base
has historically not been particularly friendly.
Thus, sadly, there's not really a good option for doing ECDSA (non-
secp256k1) validation using a third-party crate.
Instead, we go our own way here, adding an in-crate ECDSA
validator over secp{256,384}r1.
This also adds a new bench, showing our secp256r1 validation is,
sadly, something like 50x slower than OpenSSL.
Matt Corallo [Mon, 4 Mar 2024 18:43:52 +0000 (18:43 +0000)]
Add U256/U384 and mod-const-prime wrapper utilities of both.
In the next commit we'll add support for secp256r1 and secp384r1
validation, which require 256-bit and 384-bit integers. To make
their implementation simple, we also add wrapper structs around
the new integers which are modulo a const-prime, storing and
handling the values in montgommery representation.
Matt Corallo [Sun, 3 Mar 2024 15:05:08 +0000 (15:05 +0000)]
Swap `ring` for our own in-crate RSA validator
While `ring` is great, it struggles with platform support and has a
fairly involved dependency tree due to its reliance on C backends.
Further, while the `RustCrypto` org tries to stick to Rust, in
doing so it takes on more (unnecessary) dependencies and has a
particularly unusable MSRV policy. Finally, its contributor base
has historically not been particularly friendly.
Thus, sadly, there's not really a good option for doing RSA
validation using a third-party crate.
Instead, we go our own way here, adding an in-crate RSA validator.
Matt Corallo [Sun, 3 Mar 2024 14:23:39 +0000 (14:23 +0000)]
Add a relatively simple mostly-const-fn bigint math implementation
While `ring` is great, it struggles with platform support and has a
fairly involved dependency tree due to its reliance on C backends.
Further, while the `RustCrypto` org tries to stick to Rust, in
doing so it takes on more (unnecessary) dependencies and has a
particularly unusable MSRV policy. Finally, its contributor base
has historically not been particularly friendly.
Thus, sadly, there's not really a good option for doing RSA
validation using a third-party crate.
Instead, in the next commit we'll go our own way and add an
in-crate RSA validator. This takes the first step, adding a bigint
implementation that works up to 4096 bits (the longest allowed RSA
keys in the DNS).
Sadly, once we get to EC math we'll really want most of our math
operations to be const fns, which provides some additional limits.
Absent a better way to do subslicing on rustc 1.63, this commit
introduces a dependency on the `const_slice_from_raw_parts`
feature, which appears to work fine on 1.63 with
`RUSTC_BOOTSTRAP=1` set, and was stabilized in 1.64.
Matt Corallo [Wed, 20 Mar 2024 22:03:20 +0000 (22:03 +0000)]
Move RRSig loop to after DS loop to be more mindful of KeyTrap
In general we were mostly fine regarding KeyTrap, as we largely
fail after any invalid signature and only loop if a signature or
key required an unknown algorithm. Thus, addressing KeyTrap is
mostly an exercise in adding comments.
However, we did verify all DS hashes every time we went to verify
a single DNSKey RRSig, which is potentially some work, which we
fix here, leading to a nice simplification in `verify_rr_stream`.
Matt Corallo [Sat, 2 Mar 2024 15:56:39 +0000 (15:56 +0000)]
Drop NSEC/3 records from `VerifiedRRStream::verified_rrs`
`verified_rrs` is intended to include only the records a user may
want, not signatures and proof records. Thus, like we remove
RRSIG/DS records, here we also remove NSEC/3 records.
Matt Corallo [Wed, 21 Feb 2024 02:21:26 +0000 (02:21 +0000)]
Use `bitcoin_hashes` rather than `ring` for hashing
While `ring` is great, it struggles with platform support and has a
fairly involved dependency tree due to its reliance on C backends.
Further, while the `RustCrypto` org tries to stick to Rust, in
doing so it takes on more (unnecessary) dependencies and has a
particularly unusable MSRV policy. Finally, its contributor base
has historically not been particularly friendly.
Thus, for the best platform support, we'd like to avoid both. Here
we take the first of several steps towards that goal, using
`bitcoin_hashes` for our SHA-1/SHA-2 operations instead.
Matt Corallo [Thu, 8 Feb 2024 23:53:29 +0000 (23:53 +0000)]
Allow validating SHA1 DS records
While these really shouldn't be used, they sometimes are, and
importantly we don't allow them for RRSig signature validation,
ensuring that if we find a SHA1 DS record it really is what was
meant in the parent zone and wasn't forged.