On Feb 23, 2010, at 8:20 AM, Florian Weimer wrote:
* Olaf Kolkman:
5.3.3. NSEC3 Salt
The salt with NSEC3 is not used to increase the work required by an
attacker attacking multiple domains, but as a method to enable
creating a new set of hash values if at some point that might be
On Tue, 23 Feb 2010, Florian Weimer wrote:
hashes. However, NSEC records are sometimes returned in response to
DO=0 queries,
Wouldn't that be an implementation bug?
Paul
___
DNSOP mailing list
DNSOP@ietf.org
On Tue, 23 Feb 2010, Nicholas Weaver wrote:
On Feb 23, 2010, at 6:26 AM, Todd Glassey wrote:
Sorry folks - but disclosure is the rule - so something about the potential
hash collision needs to be in the document and there are liability issues for
the people and their sponsor's involved who
hashes. However, NSEC records are sometimes returned in response to
DO=0 queries,
Wouldn't that be an implementation bug?
Not if it was an ANY query. Otherwise, yes.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP
On Feb 23, 2010, at 2:03 PM, Evan Hunt wrote:
hashes. However, NSEC records are sometimes returned in response to
DO=0 queries,
Wouldn't that be an implementation bug?
Not if it was an ANY query. Otherwise, yes.
Or an NSEC query.
Roy
___
On Tue, Feb 23, 2010 at 07:09:12AM -0800, Todd Glassey wrote:
As I have said, there is no difference between this and the Jim Crow
actions which separated blacks from the white population in then US and
the application of the concept of racially unfit parties as Trolls
within the IETF,
On 02/23/10 07:42, Paul Wouters wrote:
On Mon, 22 Feb 2010, Doug Barton wrote:
My thoughts are sort of leaning in the direction that a very brief
mention of the issue combined with a reference to what Evan quoted in
5155 (which seems to handle the issue well) is probably the right
direction
On Tue, 23 Feb 2010, Doug Barton wrote:
Because NSEC3 uses a hash function there is an unimaginably small chance
that two different hostnames could produce the same hash output, and and
even smaller chance that such a collision could be exploitable by an
attacker. This issue SHOULD NOT be a
On Tue, Feb 23, 2010 at 4:26 PM, bmann...@vacation.karoshi.com wrote:
within the IETF, which also of course brings us to the question of how
many people of color are management within the IETF?.
All of them. No person that I am aware of in the ietf management
chain are
If it isn't bad enough that we're arguing about the inclusion of
infinitesimally small probabilities as risks for DNSSEC, moving onto issues of
race and colour is so much worse. This subject is entirely out of scope for
this list and there are other lists it can move to.
warmest regards
Jay
Have you boys seen this yet?
http://twitter.com/joebaptista/status/9555178362
regards
joe baptista
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 2/23/2010 1:40 PM, Paul Wouters wrote:
4641bis is DNSSEC Operational Practices. Why add something and then
immediatley say SHOULD NOT be a factor?
You snipped the bit that answered this question. The fact that very
smart people who know the protocol well even took time to discuss the
issue
12 matches
Mail list logo
