On 06-Feb-14 09:14, Klaus Darilion wrote:
Not quite. It would enable a solution, but it doesn't solve it unless named also checks for a collision, picking a new salt and re-trying in that case. That would be a good idea (though creating a test case would be a good student challenge). [If it isn't tested, it doesn't work...]On 06.02.2014 14:58, Cathy Almond wrote:On 06/02/2014 12:58, Timothe Litt wrote:On 06-Feb-14 05:56, Cathy Almond wrote:On 05/02/2014 18:54, David Newman wrote:The Michael W. Lucas DNSSEC book recommends changing NSEC3 salt every time a zone's ZSK changes.Is this just a matter of a new 'rndc signing' command, or is some actionneeded to remove the old salt? thanks dnrndc signing -nsec3param ... I would expect the old NSEC3 chain and old NSEC3PARAM record to be removed, once the new chain is in place.(Similarly, the new NSEC3PARAM record will not appear in the zone untilthe new NSEC3 chain has been completely generated). CathyThis seems silly. Why should a person have to select a salt at all? It's just a random number, and people are really bad at picking random numbers. Seems like a miss in 'DNSSEC for humans' :-) There should be a mechanism to tell named to pick a random number anduse it for the salt. (I suggest '*' - '-' already means 'none'.) namedalready has to know how to get random numbers, so this should not be difficult. It should work for records supplied in UPDATE transactions as well as rndc signing.A bit more work to have it function when loaded from a zone file, thoughthat doesn't seem unreasonable. (E.g. if read from a zone file, pick a salt, treat the record as if loaded with that value, and do all the requisite (re-)signing.)I'm copying bind9-bugs so this doesn't get lost. Please don't copy thatlist if you comment on this. (Careful with that 'reply all'!) Timothe Litt ACM Distinguished EngineerSounds like a good idea - thanks.Indeed. It would also solve the theoretical problem of NSEC3 hash collisions (see my email from 3. Feb 2014)regards Klaus
Note also the RFC 5155 recommendation:
In case it wasn't obvious, I should have noted that the length would be a config file entry.The salt SHOULD be at least 64 bits long and unpredictable, so that an attacker cannot anticipate the value of the salt and compute the next set of dictionaries before the zone is published.
Timothe Litt ACM Distinguished Engineer -------------------------- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. This communication may not represent my employer's views, if any, on the matters discussed.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users