-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/22/2010 04:53 AM, Roy Arends wrote:
On Feb 21, 2010, at 7:22 PM, Mark Andrews wrote:
NSEC3
has a non zero false positive rate due to the fact that the names
are hashed.
Are you going on again about the possibility of hash collisions is
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group of
the IETF.
Title : DNSSEC Trust Anchor History Service
Author(s) : W. Wijngaards, O. Kolkman
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group of
the IETF.
Title : DNSSEC Trust Anchor History Service
Author(s) : W. Wijngaards, O. Kolkman
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
The dnsop wg adopted this draft at the IETF meeting and with discussion
on the mailing list afterwards.
The draft-ietf-dnsop-dnssec-trust-history-00 is a copy of
draft-wijngaards-dnsop-trust-history-02.
draft-ietf-dnsop-dnssec-trust-history-01
On Feb 22, 2010, at 4:44 AM, W.C.A. Wijngaards wrote:
On 02/22/2010 04:53 AM, Roy Arends wrote:
On Feb 21, 2010, at 7:22 PM, Mark Andrews wrote:
NSEC3
has a non zero false positive rate due to the fact that the names
are hashed.
Are you going on again about the possibility of hash
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Roy,
On 02/22/2010 02:14 PM, Roy Arends wrote:
Nah, we love collisions, it makes it all so more efficient. Besides,
I think the probability of finding a bug in authoritative server
software is way higher than a hash-collision.
Yes, I agree
--On 22 February 2010 14:41:19 +0100 W.C.A. Wijngaards
wou...@nlnetlabs.nl wrote:
I am not saying this makes NSEC3 a unchoosable option; but it
is a tradeoff, and if you can use NSEC because you do not need the
benefits of NSEC3, you should, because it'll drive down bandwidth and
cpu usage
Using NSEC instead of NSEC3 because you fear SHA1 collisions does not
seem sensible, as if you fear SHA1 collisions, you have other more
significant problems with DNSSEC to worry about, and thus this is
not, in my opinion, reasonable. And it isn't sensible to suggest
users worry about it. If
At 11:17 -0500 2/22/10, Matt Larson wrote:
+1, total and complete agreement. I am adamantly opposed to including
any text about SHA1 hash collisions in an NSEC3 context.
I'll agree. We are using NSEC in dotUS and not NSEC3. It wasn't
because of the risk of hash collisions in SHA1. We
On Feb 22, 2010, at 11:12 AM, Evan Hunt wrote:
Using NSEC instead of NSEC3 because you fear SHA1 collisions does not
seem sensible, as if you fear SHA1 collisions, you have other more
significant problems with DNSSEC to worry about, and thus this is
not, in my opinion, reasonable. And it
On Mon, Feb 22, 2010 at 8:52 AM, Roy Arends r...@dnss.ec wrote:
On Feb 22, 2010, at 11:12 AM, Evan Hunt wrote:
Using NSEC instead of NSEC3 because you fear SHA1 collisions does not
seem sensible, as if you fear SHA1 collisions, you have other more
significant problems with DNSSEC to worry
This is absurd. If we're going to do this, I'd like the security
considerations to reflect all of the non-zero probabilities of errors
occuring (those that have a higher probability).
I just answered this point in private mail to someone else, failing to
realize until after I'd sent it that it
--- SNIP ---
Precisely.
I realize it's hard to grasp precisely how small the statistical
chances of a collision are, but they are just unbelievably small. Acting as if
it is
something that might actually happen just makes you look silly.
Actually Erik ... the problem isn't the
On Mon, Feb 22, 2010 at 9:23 AM, Evan Hunt e...@isc.org wrote:
This is absurd. If we're going to do this, I'd like the security
considerations to reflect all of the non-zero probabilities of errors
occuring (those that have a higher probability).
I just answered this point in private mail to
On Feb 22, 2010, at 12:23 PM, Evan Hunt wrote:
This is absurd. If we're going to do this, I'd like the security
considerations to reflect all of the non-zero probabilities of errors
occuring (those that have a higher probability).
My point is not to say that hash collisions are a problem or
--On 22 February 2010 09:05:47 -0800 Eric Rescorla e...@rtfm.com wrote:
On Mon, Feb 22, 2010 at 8:52 AM, Roy Arends r...@dnss.ec wrote:
On Feb 22, 2010, at 11:12 AM, Evan Hunt wrote:
Alex Bligh wrote:
Using NSEC instead of NSEC3 because you fear SHA1 collisions does not
seem sensible ...
In message 699b9362-b927-4148-b79e-2aeb6d713...@dnss.ec, Roy Arends writes:
On Feb 22, 2010, at 4:44 AM, W.C.A. Wijngaards wrote:
On 02/22/2010 04:53 AM, Roy Arends wrote:
On Feb 21, 2010, at 7:22 PM, Mark Andrews wrote:
NSEC3
has a non zero false positive rate due to the fact that
In message fd83b7a9-583c-4e6c-9301-414d043db...@dnss.ec, Roy Arends writes:
On Feb 22, 2010, at 11:12 AM, Evan Hunt wrote:
Using NSEC instead of NSEC3 because you fear SHA1 collisions does not
seem sensible, as if you fear SHA1 collisions, you have other more
significant problems with
On 2010-02-22, at 19:13, Mark Andrews ma...@isc.org wrote:
The problem is that one is using a hash, not the strength
of the hash.
Precisely. See another remark in this thread about excluded middle
and so on.
--
Andrew Sullivan
a...@shinkuro.com
In message 222b7737-d294-4ef1-9f14-de4ca4c70...@dnss.ec, Roy Arends writes:
On Feb 22, 2010, at 6:41 PM, Mark Andrews wrote:
=20
The real problem is that a SHA1 hash collision would render all =
signatures wi
th RSASHA1 vulnerable. Haven't heard you about that.=20
=20
Hogwash. A
--On 23 February 2010 11:06:50 +1100 Mark Andrews ma...@isc.org wrote:
Drunk Sysadmins, Rouge Registrar, etc, etc.
I'm sure that it will be a very large section.
Apart from the slightly higher risk of software bugs because NSEC3
is more complicated. The other items have no impact of the
On 02/22/10 11:59, Evan Hunt wrote:
Note that RFC 5155 takes the time to put the issue to rest not once but
twice:
I am on the fence regarding the necessity of mentioning the hash
collision issue in 4641bis. While other potential security concerns are
not directly relevant to the topic, this
* 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
required. The salt is used as a roll over. The
* Roy Arends:
So, a collision (that is nothing more than a collision) is a problem
for NSEC3, but not for RSASHA1?
You still need a collision over somewhat structured data.
Chosen-prefix collisions (with different prefixes) are likely not
*that* far away after that, and those break RSASHA1
24 matches
Mail list logo
