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.