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 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 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
-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
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
On 2/20/2010 8:48 AM, Paul Wouters wrote:
On Sat, 20 Feb 2010, Alex Bligh wrote:
There are two meachanisms to provide authenticated proof of
exsitance/non-existance in DNSSEC.
I don't believe either provides proof of existence (apart from
existence of the NSECx record).
Yep - agreed.
If
In message 315ad36e-879a-4512-a6a8-b64372e3d...@sinodun.com, John Dickinson w
rites:
Hi,
It might also be worth adding a line at the start reminding of the need for N
SEC and NSEC3 - namely that the signing and serving of the zone are separate
operations and that it is therefore necessry
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 SHA-1?
Roy
___
DNSOP mailing list
On Sun, Feb 21, 2010 at 4:22 PM, Mark Andrews ma...@isc.org wrote:
In message 315ad36e-879a-4512-a6a8-b64372e3d...@sinodun.com, John Dickinson
w
rites:
Hi,
It might also be worth adding a line at the start reminding of the need for N
SEC and NSEC3 - namely that the signing and serving of
On Sat, 20 Feb 2010, Alex Bligh wrote:
There are two meachanisms to provide authenticated proof of
exsitance/non-existance in DNSSEC.
I don't believe either provides proof of existence (apart from
existence of the NSECx record).
If you can proof one, you can also proof the other :)
I
I think Olafur's point is a good one, but I'm unhappy with the prose.
Some suggested changes below.
On Sat, Feb 20, 2010 at 08:37:16AM -0500, Olafur Gudmundsson wrote:
There are two meachanisms to provide authenticated proof of
exsitance/non-existance in DNSSEC. A clear text one and a
I think Olafur's point is a good one, but I'm unhappy with the prose.
Some suggested changes below.
Same here.
Nits:
There are to mechanisms to provide authenticated proof of
s/to/two/
Each mechanism includes a list of all the RRTYPEs present at the
s/includes/stores/
The clear text
Thanks Evan and Andrew fot translating my thoughts into better prose.
Evan, you captures my meaning.
Olafur
On 20/02/2010 4:31 PM, Evan Hunt wrote:
I think Olafur's point is a good one, but I'm unhappy with the prose.
Some suggested changes below.
Same here.
Nits:
There are to
Alex,
I have taken your recommendations and added them to the current text. Also the
other discussion about enumarability of highly structured zones found a place.
However, I did do some slight rephrasing. I don't think I changed the spirit of
your suggestions.
The text in my current draft
On Wed, 17 Feb 2010, Olaf Kolkman wrote:
Though all agree DNS data should be accessible through query
mechanisms, a side effect of NSEC is that it allows the contents of a
zone file to be enumerate in full by sequential query. Whilst for
Small typos: enumerated and sequential queries
On Feb 17, 2010, at 4:03 PM, Paul Wouters wrote:
On Wed, 17 Feb 2010, Olaf Kolkman wrote:
Though all agree DNS data should be accessible through query
mechanisms, a side effect of NSEC is that it allows the contents of a
zone file to be enumerate in full by sequential query. Whilst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/17/2010 05:37 PM, Paul Wouters wrote:
5.3. NSEC3 parameters
The NSEC3 hashing includes the FQDN in its uncompressed form. This
over its uncompressed form? The hash does not 'include' it.
I overlooked this when I copied the text from
--On 23 January 2010 12:25:00 -0500 Olafur Gudmundsson o...@ogud.com
wrote:
Opt-out was designed for large delegation-only/mostly zones, in almost all
other cases it should not be used.
And this was the only use case I was suggesting was excepted from
the blanket should not (in fact I
On Fri, 22 Jan 2010, Paul Wouters wrote:
On Fri, 22 Jan 2010, Alex Bligh wrote:
I meant computational resource requirements resultant from crypto
operations, not algorithmic complexity.
I had no problems doing this on a 1.2M domains TLD zone, using off the
shelf hardware, integrating into
On Jan 21, 2010, at 6:52 PM, Paul Wouters wrote:
On Thu, 21 Jan 2010, Olaf Kolkman wrote:
In trying to get a reasonable version 2 out of the door before Anaheim I am
trying to identify and where possibly close open issues.
As a reminder:
--On 22 January 2010 12:04:07 +0100 Olaf Kolkman o...@nlnetlabs.nl wrote:
Strawman text said:
Though some claim all data in the DNS should be considered public, it
sometimes is considered to be more then private, but less then public
data.
That does not describe the problem well, in that
--On 22 January 2010 23:09:11 +1100 Mark Andrews ma...@isc.org wrote:
Additionally NSEC3 provides no real benefit is highly structured zones
like IP6.ARPA. It is relatively easy to enumerate a IP6.ARPA zone even
if it is using NSEC3 by making use of the zone's structure.
e164.arpa. is
Paul,
--On 22 January 2010 14:51:38 -0500 Paul Wouters p...@xelerance.com wrote:
the NSEC3 RR chain. Therefor, Opt-Out should be avoided if possible.
1. Therefor*e*
2. I don't think the last sentence follows from the foregoing, in that
this behaviour is desirable for the zone operator! (I
At 20:31 + 1/22/10, Alex Bligh wrote:
contents) in example.org. So, whilst opt-out should be avoided
across intervals containing secure delegations, I see no reason
to avoid it across intervals that don't contain secure delegations.
Opt-out is restricted to intervals that contain only
--On 22 January 2010 15:45:54 -0500 Edward Lewis ed.le...@neustar.biz
wrote:
contents) in example.org. So, whilst opt-out should be avoided
across intervals containing secure delegations, I see no reason
to avoid it across intervals that don't contain secure delegations.
Opt-out is
Paul,
I was talking about the situation where example.org is signed, the .org
is optout and exemple.org does not exist. For many, it is impossible
to register all typo-squat domains, so this is a real scenario.
Ah, didn't spot the 'e'.
Having verifiable deniability for typo-squated domaims
--On 23 January 2010 04:56:33 + Alex Bligh a...@alex.org.uk wrote:
Having verifiable deniability for typo-squated domaims is very useful.
If expensive, where 99% of your domains are unsigned.
By which I mean expensive given this isn't the cheapest attack vector.
If I want to typo
51 matches
Mail list logo
