Paul Vixie writes:
> if we must say this, s/vendors/implementers/, please. some of us when
> we play with dns or dnssec don't share our resulting code. --vixie
Good catch; I've changed all references.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
Matthijs Mekking writes:
> Can we make use of the keyword MAY? This allows I think for text that
> will not get out of date:
>
>Validating resolvers MAY return an insecure response when processing
>NSEC3 records with iterations larger than 0. Validating resolvers MAY
>also return
Petr Špaček writes:
> I believe that this property renders salt practically useless, so let
> me propose a modified section 2.4:
[snip]
Thanks for the text and it seems well agreed upon, so I replaced section
2.4 with your text after making some editing related tweaks. Feel free
to re-read it
Matthijs Mekking writes:
> 3.2. Recommendation for validating resolvers
>
> I understand why the new text is here, but I think this now actually
> gives too little advice for operators and vendors.
>
> I know, this is a vague comment, I need to think about it a bit more.
Whoops, good catch
Petr Špaček writes:
> > 3.1. Best-practice for zone publishers
> > I wonder if we can make the requirement even stronger by saying "If
> > NSEC3 must be used, then an iterations count of 0 MUST be used to
> > alleviate computational burdens." (MUST instead of SHOULD).
> > Or is there a valid
On 26/11/2021 12.32, Petr Špaček wrote:
You are right right, I did not consider "crack names which do not
exist yet" scenario and focused only on dictionary reuse across zones.
Do you have specific proposals for draft text?
No, I don't have any ideas for improvements. The current salt
On 27. 11. 21 7:12, Viktor Dukhovni wrote:
On Fri, Nov 26, 2021 at 12:32:19PM +0100, Petr Špaček wrote:
Also, when we are theorizing, we can also consider that resalting
thwarts simple correlation: After a resalt attacker cannot tell if a set
of names has changed or not. With a constant salt
On Fri, Nov 26, 2021 at 12:32:19PM +0100, Petr Špaček wrote:
> Also, when we are theorizing, we can also consider that resalting
> thwarts simple correlation: After a resalt attacker cannot tell if a set
> of names has changed or not. With a constant salt attacker can detect
> new and removed
Petr Špaček wrote on 2021-11-26 01:24:
...
Maybe your proposed text can be prepended/appended to the current
content of 3.2. Recommendation for validating resolvers, so we can keep
the "vendors are encouraged to continue evaluating NSEC3 iteration count
deployments" part?
if we must say
On 26. 11. 21 11:49, Vladimír Čunát wrote:
On 25/11/2021 13.00, Petr Špaček wrote:
IMHO in the context of NSEC3 the salt would make sense _only_ if it
were rotated faster than attacker was able to walk the zone. Once
attacker has list of hashes available for offline cracking the salt
does not
On 25/11/2021 13.00, Petr Špaček wrote:
IMHO in the context of NSEC3 the salt would make sense _only_ if it
were rotated faster than attacker was able to walk the zone. Once
attacker has list of hashes available for offline cracking the salt
does not do anything useful anymore.
I disagree;
On 26. 11. 21 9:43, Matthijs Mekking wrote:
On 25-11-2021 13:00, Petr Špaček wrote:
On 25. 11. 21 9:33, Matthijs Mekking wrote:
3.2. Recommendation for validating resolvers
I understand why the new text is here, but I think this now actually
gives too little advice for operators and
On 25-11-2021 13:00, Petr Špaček wrote:
On 25. 11. 21 9:33, Matthijs Mekking wrote:
3.2. Recommendation for validating resolvers
I understand why the new text is here, but I think this now actually
gives too little advice for operators and vendors.
I know, this is a vague comment, I
Petr Špaček wrote on 2021-11-25 04:00:
On 25. 11. 21 9:33, Matthijs Mekking wrote:
...
3.1. Best-practice for zone publishers
...
This section is IMHO missing a scary warning to explain the reasons. Let
add one couple sentences (+ "extra" keyword to differentiate it from the
implicit
On 25. 11. 21 9:33, Matthijs Mekking wrote:
Hi Wes,
I think the changes are moving the document in the right direction.
Some comments:
3.1. Best-practice for zone publishers
I wonder if we can make the requirement even stronger by saying "If
NSEC3 must be used, then an iterations count of
Hi Wes,
I think the changes are moving the document in the right direction.
Some comments:
3.1. Best-practice for zone publishers
I wonder if we can make the requirement even stronger by saying "If
NSEC3 must be used, then an iterations count of 0 MUST be used to
alleviate computational
internet-dra...@ietf.org writes:
> Title : Guidance for NSEC3 parameter settings
> Authors : Wes Hardaker
> Viktor Dukhovni
> Filename: draft-ietf-dnsop-nsec3-guidance-02.txt
> Pages : 10
> Date
17 matches
Mail list logo
