NSEC3 and multiple key signing support. #416
Conversation
bal-e
force-pushed
the
dnssec-key
branch
2 times, most recently
from
a79aac6 to
0f54a8d
Compare
src/sign/ring.rs
Outdated
| pub fn nsec3_hash<N, SaltOcts, HashOcts>( | ||
| owner: N, | ||
| algorithm: Nsec3HashAlg, | ||
| iterations: u16, | ||
| salt: &Nsec3Salt<SaltOcts>, | ||
| ) -> Result<OwnerHash<HashOcts>, Nsec3HashError> |
There was a problem hiding this comment.
Why not just take the owner name and an Nsec3param?
There was a problem hiding this comment.
nsec3_default_hash can then be replaced by calling this function with default() for the second argument.
There was a problem hiding this comment.
Why not just take the owner name and an
Nsec3param?
I had that but took it out. There was a reason. I'll see if I can remember why.
There was a problem hiding this comment.
Ah I know why. The nsec3s() function takes an Nsec3Param struct which it uses to create the NSEC3PARAM RR at the apex of the zone. For the NSEC3PARAM RR RFC 5155 says that the opt-out flag in the flags field MUST be zero, so for RFC compliance the Nsec3Param struct passed to nsec3s() should have the opt-out flag set to zero.
Honestly I think this is a bit of a foot-gun and perhaps best not to pass an Nsec3Param to nsec3s() but instead only the other fields (algorithm, iterations, salt), however MAYBE in future it will be legal to set some of the other flag bits in the flags field and a user would want to have those set in the created NSEC3PARAM RR... so for that reason nsec3s() currently takes an Nsec3Param as input.
When generating NSEC3 RRs, and when opt-out is enabled, the flags value in the given Nsec3Param cannot be used as-is because the opt-out flag must be set to 1 (but NOT in the NSEC3PARAM RR), and rather than copy the given Nsec3Param or modify it and then pass it to nsec3_hash() I felt it was better to just pass only the values actually needed for hashing in, as NSEC3 hashing doesn't need the flags field at all, and also that way users don't have to think about what value to set the unused Nsec3Param::flags field to when invoking nsec3_hash() directly (as dnst nsec3-hash does).
src/sign/ring.rs
Outdated
| let owner_hash = OwnerHash::from_octets(hash) | ||
| .map_err(|_| Nsec3HashError::OwnerHashError)?; |
There was a problem hiding this comment.
I don't think this should return an OwnerHashError. There are two failure cases for from_octets: if the hash is more than 255 bytes (impossible since NSEC3 doesn't support any such digest algorithms) or if memory could not be allocated (in which case we should return AppendError).
There was a problem hiding this comment.
It's not clear to me from the docs on OwnerHashError that it only fails relating to length, it just says "The hashing process produced an invalid owner hash" and I have no way of knowing when that error might occur or why.
|
@bal-e: I realize that I moved the |
|
@ximon18: yeah, I think this should be moved under |
Done. |
src/sign/records.rs
Outdated
| // the apex and the original owner name." | ||
| let distance_to_root = name.owner().iter_labels().count(); | ||
| let distance_to_apex = distance_to_root - apex_label_count; | ||
| if distance_to_apex > 1 { |
There was a problem hiding this comment.
I don't think the if statement is necessary, the for loop will run for zero iterations if this condition is not true.
There was a problem hiding this comment.
True, but the if statement matches nicely with the RFC text and makes it clear that if we enter this block it is because of the condition identified by the RFC text.
tertsdiepraam
force-pushed
the
initial-nsec3-generation
branch
from
cf2f450 to
e1c1db8
Compare
… take an iterator as input, which is more flexible than being able to sign only SortedRecords. - Replace `ErrorTypeToBeDetermined` with new enum `SigningError`. - Introduce `IntendedKeyPurpose` to signal intended use of keys explicitly rather than infering intent from key flags. - Introduce `DnssecSigningKey` to associate key intent with a key and provide various constructors to simplify usage. - Introduce `SigningKeyUsageStrategy` to externalize the logic for choosing which keys to use to sign DNSKEY RRSETs and other zone RRSETs. - Use per key signature validity periods instead of per signing operation. - Improved key summary at debug level, including alg name as well as number.
…-zonemd-remove-replace-plus-pr444
…-zonemd-remove-replace-plus-pr444
…-zonemd-remove-replace-plus-pr444
…-zonemd-remove-replace-plus-pr444
- Add a full zone test of generate_rrsigs() with default config. - Change SigningKeyUsageStrategy to return Vec and have generate_rrsigs() sort and dedup the results of its fns so that DNSKEY RRs are generated in a deterministic order and that implementers don't have to create short lived HashSets. (even creating Vec isn't ideal...)
…end, otherwise inserts via a large iterator will sort per insert which is slow comparing to dedup and sort after extend (and will make use of the Sorter too).
… key usage strategies.
…y, remove them again.
… to be unsigned. - Add more tests and simplify some existing tests.
- Add a test of generate_rrsigs() with mutliple KSKs and ZSKs.
…rn just the record types they produce.
Currently lacks collision detection and tests, though has been manually tested using
ldns-verify-zone,dnssec-verifyandnamed-checkzoneboth with and without opt-out and also including both signed and unsigned delegations.I'm posting this here as a draft to allow for alignment and early feedback from the team working on various pieces of DNSSEC support for
domain.Note: This PR includes the content of #444.