Re: [dns-operations] Evaluation of NSEC3-encloser attack
It appears that Jim Reid said: > > >> On 27 Mar 2024, at 19:37, Ondřej Surý wrote: >> >> Both salt and iterations have absolutely no value for NSEC3 security (see >> the RFC you just quoted), so just always use empty salt and zero iterations. >There’s no added value in fiddling with salt to fit into the SHA1 block. > >IMO, there’s no added value in using NSEC3. My understanding is that if you want to prevent zone enumeration you are better off with RFC 4470 white lies. You'd only need NSEC3 if your zone security is so critical that you need to do offline signing. But the overlap between the zones that are that critical and the ones that try to keep their contents secret (realizing that passive DNS makes the whole thing pretty silly) is vanishingly small. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Evaluation of NSEC3-encloser attack
> On 27 Mar 2024, at 19:37, Ondřej Surý wrote: > > Both salt and iterations have absolutely no value for NSEC3 security (see the > RFC you just quoted), so just always use empty salt and zero iterations. > There’s no added value in fiddling with salt to fit into the SHA1 block. IMO, there’s no added value in using NSEC3. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Evaluation of NSEC3-encloser attack
On Wed, Mar 27, 2024 at 07:17:01PM +, Matthew Richardson via dns-operations wrote: > Viktor Dukhovni wrote:- > > >I do hope that, as a community, we'll continue to steadily streamline > >acceptable NSEC3 parameters (per RFC9276) down to 0 additional > >iterations and short enough salt values (that don't result in additional > >SHA-1 input blocks). > > What would be the largest salt length to ensure that such additional input > blocks are not required? The SHA-1 hash function "comresses" 64 bytes of input (a 512-bit block) to 20 bytes of output, 8 of the trailing input bytes are a 64-bit message length, and there's at least 1 byte (0x80) of padding. https://datatracker.ietf.org/doc/html/rfc3174#section-4 Whether additional SHA-1 blocks are required depends on the length of the owner-name: https://datatracker.ietf.org/doc/html/rfc5155#section-5 If the owner name and salt fit into 55 bytes, a single SHA-1 block would be sufficient, otherwise a second or more SHA-1 block may be required. Worst case is 255 bytes of owner name (wire form) + 255 bytes of salt, which would require 9 SHA-1 blocks. With a zero length salt, one gets to hash 55 bytes of owner-name in a single SHA-1 block. -- Viktor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Evaluation of NSEC3-encloser attack
Both salt and iterations have absolutely no value for NSEC3 security (see the RFC you just quoted), so just always use empty salt and zero iterations. There’s no added value in fiddling with salt to fit into the SHA1 block. Ondrej -- Ondřej Surý (He/Him) > On 27. 3. 2024, at 20:17, Matthew Richardson > wrote: > > Viktor Dukhovni wrote:- > >> I do hope that, as a community, we'll continue to steadily streamline >> acceptable NSEC3 parameters (per RFC9276) down to 0 additional >> iterations and short enough salt values (that don't result in additional >> SHA-1 input blocks). > > What would be the largest salt length to ensure that such additional input > blocks are not required? > > -- > Best wishes, > Matthew ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Evaluation of NSEC3-encloser attack
--- Begin Message --- Viktor Dukhovni wrote:- >I do hope that, as a community, we'll continue to steadily streamline >acceptable NSEC3 parameters (per RFC9276) down to 0 additional >iterations and short enough salt values (that don't result in additional >SHA-1 input blocks). What would be the largest salt length to ensure that such additional input blocks are not required? -- Best wishes, Matthew --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Evaluation of NSEC3-encloser attack
> On 25. 3. 2024, at 20:17, Viktor Dukhovni wrote: > > I do hope that, as a community, we'll continue to steadily streamline > acceptable NSEC3 parameters (per RFC9276) down to 0 additional > iterations and short enough salt values (that don't result in additional > SHA-1 input blocks). Amen to that! Ondřej -- Ondřej Surý (He/Him) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Evaluation of NSEC3-encloser attack
On Mon, Mar 25, 2024 at 09:27:06AM +0100, Haya Shulman wrote: > Our evaluations demonstrate that the two attack vectors are fundamentally > different from the perspective of their practical impact: KeyTrap > introduces a realistic immediate threat for exploitation by hackers. In > contrast, with NSEC3-encloser attack a comparable load on resolvers is not > possible, not only that with a single NSEC3-encloser attack no packet is > lost, but also no latency is introduced to the resolvers. The high volume > of NSEC3-encloser attack traffic, of more than hundreds of packets per > second, makes the NSEC3-encloser attack visible. Therefore, the high attack > volume in tandem with the meager benefit for adversaries (only a small > fraction of benign packets dropped) implies that such attacks do not pose a > practical threat. Reading the paper, I get an impression that the described attack isn't nearly as stressful on the resolver CPU as it could be. If I understood the measured attack correctly, a more "malicious" approach could substantially (~100x) increase the per-query-response CPU cost. Perhaps qualitatively changing the relative impact assessment? I do hope that, as a community, we'll continue to steadily streamline acceptable NSEC3 parameters (per RFC9276) down to 0 additional iterations and short enough salt values (that don't result in additional SHA-1 input blocks). -- Viktor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
