> On 29 Nov 2021, at 7:55 am, Michael Bauland wrote:
>
>> The iteration count distribution for the TLDs is presently:
>> # TLDs NSEC3 iterations
>> --
>> 147 0
>> 458 1
>> 1 2
>> 14 3
>> 112 5
>> 4 8
>> 545 10
>> 29 12
>> 1 13
Hi Viktor, hi all,
thanks for making us aware of the NSEC3 iteration count topic.
On 08.11.2021 18:29, Viktor Dukhovni wrote:
On 8 Nov 2021, at 6:07 am, Petr Špaček wrote:
TL;DR
I say we should go for 0 and acknowledge in the text we are not there yet.
This means reaching out to the TLD
On 09. 11. 21 18:57, Viktor Dukhovni wrote
On 9 Nov 2021, at 4:11 am, Petr Špaček wrote:
I don't see need to specify _a_ value here. I think better approach is
acknowledge current state of things. What about something like this?
---
As for November 2021, the limit of 150 iterations for
> On 9 Nov 2021, at 4:11 am, Petr Špaček wrote:
>
> I don't see need to specify _a_ value here. I think better approach is
> acknowledge current state of things. What about something like this?
>
> ---
> As for November 2021, the limit of 150 iterations for treating answer as
> insecure is
On 08. 11. 21 14:41, Wes Hardaker wrote:
Petr Špaček writes:
Thanks for the detail notes Petr, very helpful.
From my point of view the RFC does not need to stick to the value
currently implemented in resolvers.
Good point, and maybe the right phrasing I should have used should have
been
On Mon, 8 Nov 2021, Viktor Dukhovni wrote:
These points make a good starting point for a draft recommending to not
use NSEC3:
* Accept that sufficiently determined adversaries will mount a dictionary
attack, but there won't be many of them. Make do with NSEC3 and zero
iterations.
* Accept
> On 8 Nov 2021, at 12:55 pm, A. Schulze wrote:
>
> sorry for maybe asking an already answered question,
> but why is NSEC3 considered to have no benefit at all?
My take is that NSEC3 provides little benefit beyond the initial
(0th) iteration.
> I'm still on "NSEC allow zone-walks while NSEC3
Am 05.11.21 um 20:19 schrieb Olafur Gudmundsson:
> The document should strongly discourage any use of NSEC3
Hello,
sorry for maybe asking an already answered question,
but why is NSEC3 considered to have no benefit at all?
I'm still on "NSEC allow zone-walks while NSEC3 don't"
At least
> On 8 Nov 2021, at 6:07 am, Petr Špaček wrote:
>
> TL;DR
> I say we should go for 0 and acknowledge in the text we are not there yet.
This means reaching out to the TLD operators again... They were quite
cooperative ~6 months back, but I wouldn't want to take them for granted
and keep asking
Miek Gieben writes:
> [ Quoting in "Re: [DNSOP] nsec3-parameters opinio..." ]
> >The document should strongly discourage any use of NSEC3
>
> I would very much see a sentence/paragraph stating this in the
> document as well.
Folks, can we boil this down to a concrete suggestion. Section 3.1
Petr Špaček writes:
Thanks for the detail notes Petr, very helpful.
> From my point of view the RFC does not need to stick to the value
> currently implemented in resolvers.
Good point, and maybe the right phrasing I should have used should have
been "what value would implementations refuse to
On 08. 11. 21 9:34, Matthijs Mekking wrote:
I concur with Benno.
For Bind 9, there is no technical challenge to set the iteration cap at
a lower value.
We prefer the value to be as low as possible, because it adds no real
value at a real resource cost.
But we will likely not implement
I concur with Benno.
For Bind 9, there is no technical challenge to set the iteration cap at
a lower value.
We prefer the value to be as low as possible, because it adds no real
value at a real resource cost.
But we will likely not implement blindly a maximum that will cause lots
of operational
Vladimír Čunát writes:
> I'm convinced that 150 was just a quick stop-gap compromise and that
> from the start vendors expected that dnsop might set it lower later.
> Therefore I don't think this *argument* for keeping 150 is really
> valid.
Thanks; as I said in the original, I think we need
Miek Gieben writes:
> To update, my 'wants' would actually be 0.
Thanks Miek,
Its always hard to interpret what people say into hard numbers :-)
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
> On 5 Nov 2021, at 3:19 pm, Olafur Gudmundsson wrote:
>
> Publishing iteration count higher than 10 is reckless as that affects the
> performance of recursive resolvers in particular the ones that run on small
> CPE equipment.
>
> The document should strongly discourage any use of NSEC3
>
Publishing iteration count higher than 10 is reckless as that affects the
performance of recursive resolvers in particular the ones that run on small CPE
equipment.
The document should strongly discourage any use of NSEC3
For the that want to keep using it the limit should be real low of
Wes,
On 05/11/2021 09:40, Vladimír Čunát wrote:
On 04/11/2021 23.44, Wes Hardaker wrote:
The most important sticking point is there are 4 implementations (thank
you for the links Matthijs) that have implemented 150. Since DNSOP
strives for implementations of specs, I think this is the number
On 04/11/2021 23.44, Wes Hardaker wrote:
The most important sticking point is there are 4 implementations (thank
you for the links Matthijs) that have implemented 150. Since DNSOP
strives for implementations of specs, I think this is the number we
should publish*unless the vendors speak up and
[ Quoting in "[DNSOP] nsec3-parameters opinions g..." ]
I was waiting for the last discussion to die down (and then, um, for me
to finally examine the opinions). The results are in from the people
that weighed in:
| who | wants | accepts|
Folks,
I was waiting for the last discussion to die down (and then, um, for me
to finally examine the opinions). The results are in from the people
that weighed in:
| who | wants | accepts|
|--+---+|
| Peter
21 matches
Mail list logo
