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
is
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 fact
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
>>
On Feb 23, 2010, at 10:40 AM, Paul Wouters wrote:
> On Mon, 22 Feb 2010, Doug Barton wrote:
>
>> On 02/22/10 05:14, Roy Arends wrote:
>>> On Feb 22, 2010, at 4:44 AM, W.C.A. Wijngaards wrote:
The deployment of NSEC3-signed toplevel domains is a giant hash
collision test of typo dictiona
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
> >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 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 vo
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 to go.
I"m with Andrew and people. Mentio
On Mon, 22 Feb 2010, Doug Barton wrote:
On 02/22/10 05:14, Roy Arends wrote:
On Feb 22, 2010, at 4:44 AM, W.C.A. Wijngaards wrote:
The deployment of NSEC3-signed toplevel domains is a giant hash
collision test of typo dictionaries.
Not really, most (will) use Opt-Out.
Has anyone done a sid
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 vote to keep these types of key
> factor's
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
https://www.ietf.org/mailman/listinfo/dn
On 2/22/2010 8:46 PM, Doug Barton wrote:
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 conce
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 th
* 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 c
* 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
On 02/22/10 05:14, Roy Arends wrote:
> On Feb 22, 2010, at 4:44 AM, W.C.A. Wijngaards wrote:
>> The deployment of NSEC3-signed toplevel domains is a giant hash
>> collision test of typo dictionaries.
>
> Not really, most (will) use Opt-Out.
Has anyone done a side-by-side comparison of nsec/nsec3
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 o
--On 23 February 2010 11:06:50 +1100 Mark Andrews 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 decision
to cho
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
> >
On Feb 22, 2010, at 7:06 PM, Mark Andrews wrote:
>
> In message , Roy Arends writes:
>> This is absurd. If we're going to do this, I'd like the security consideratio
>> ns to reflect all of the non-zero probabilities of errors occuring (those tha
>> t have a higher probability). This includes so
On Feb 22, 2010, at 6:41 PM, Mark Andrews wrote:
>
>> The real problem is that a SHA1 hash collision would render all signatures wi
>> th RSASHA1 vulnerable. Haven't heard you about that.
>
> Hogwash. A collision is nothing more than a collision. See above.
So, a collision (that is nothing m
On 2010-02-22, at 19:13, Mark Andrews 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
___
DNSOP mailing list
DNSO
On Mon, Feb 22, 2010 at 4:24 PM, Mark Andrews wrote:
>
> In message , Eric
> R
> escorla writes:
>> Well, IMO we shouldn't have addressed this in RFC 5155 either. It falls
>> into the category of "basic assumptions"
>
> Basic assumptions should be noted.
Should we also note the Heisenberg uncert
In message , Eric R
escorla writes:
> Well, IMO we shouldn't have addressed this in RFC 5155 either. It falls
> into the category of "basic assumptions"
Basic assumptions should be noted.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
In message <20100222185157.go64...@shinkuro.com>, Andrew Sullivan writes:
> On Mon, Feb 22, 2010 at 11:17:59AM -0500, Matt Larson wrote:
>
> > I am adamantly opposed to including
> > any text about SHA1 hash collisions in an NSEC3 context.
>
> Add me to the choir. Actually, I'm opposed to inc
In message , 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 DNSSEC to worry about, and thus this
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 du
On 22 feb 2010, at 17.17, Matt Larson wrote:
> +1, total and complete agreement. I am adamantly opposed to including
> any text about SHA1 hash collisions in an NSEC3 context.
+1.
jakob
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.o
On Mon, Feb 22, 2010 at 11:59 AM, Evan Hunt wrote:
>> I have not seen anyone make a statement "NSEC3 is exactly as good as NSEC".
>>
>> I've seen the opposite by Mark Andrews:
>>
>> "Actually NSEC is technically better at proving non-existance."
>
> Mark was responding to an assertion to the con
> I have not seen anyone make a statement "NSEC3 is exactly as good as NSEC".
>
> I've seen the opposite by Mark Andrews:
>
> "Actually NSEC is technically better at proving non-existance."
Mark was responding to an assertion to the contrary ("one is NOT better
than the other") by making a bou
--On 22 February 2010 09:05:47 -0800 Eric Rescorla wrote:
On Mon, Feb 22, 2010 at 8:52 AM, Roy Arends 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 ... And it isn't sensible to
On Mon, Feb 22, 2010 at 11:17:59AM -0500, Matt Larson wrote:
> I am adamantly opposed to including
> any text about SHA1 hash collisions in an NSEC3 context.
Add me to the choir. Actually, I'm opposed to including any text
about SHA-1 hash collisions in _any_ DNSSEC context until we write the
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 pro
On Mon, Feb 22, 2010 at 9:23 AM, 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).
>
> I just answered this point in private mail to someo
--- 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 statistical
> 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
On Mon, Feb 22, 2010 at 8:52 AM, Roy Arends 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 about
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
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 didn
On Sun, 21 Feb 2010, Eric Rescorla wrote:
> On Sun, Feb 21, 2010 at 4:22 PM, Mark Andrews wrote:
> > Actually NSEC is technically better at proving non-existance. NSEC3
> > has a non zero false positive rate due to the fact that the names
> > are hashed. NSEC has a zero false positive rate.
> >
> 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.
--On 22 February 2010 14:41:19 +0100 "W.C.A. Wijngaards"
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 (slightly) for eve
-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 t
On Feb 22, 2010, at 8:14 AM, Roy Arends wrote:
> example.co.uk (lets skip the probability factor), than its just gotten a bit
> more efficient. One hash matching 2 names, i.e. we can now deny two names for
> the price of one.
can now prove existence of two names for the price of one.
Now... c
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 possibil
-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 coll
On Sun, Feb 21, 2010 at 4:22 PM, Mark Andrews 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 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
DNSOP@ietf
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 nece
Hi,
It might also be worth adding a line at the start reminding of the need for
NSEC and NSEC3 - namely that the signing and serving of the zone are separate
operations and that it is therefore necessry to create records that cover the
very large number of non-existent names that lie between th
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 yo
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 m
> 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
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 obfus
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 think
--On 20 February 2010 08:37:16 -0500 Olafur Gudmundsson
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). I think they both only provide
proof
5. Next Record type
There are currently two types of next records that are provide
authenticated denial of existence of DNS data in a zone.
I have a problem with this presentation.
There are two mechanishm to provide proof of non-existance, each has a
RR type associated with it.
The
5.2. NSEC or NSEC3
The first reason to deploy NSEC3, prevention of zone enumeration,
makes sense when zone content is not highly structured or trivially
"only makes sense" ?
How about "applies"
The algorithm choice therefor depends solely on the DNSKEY algorithm
picked.
"The n
-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
On Wed, 17 Feb 2010, Olaf Kolkman wrote:
Small typos: "enumerated" and "sequential queries"
I am not sure about the "should" in that sentence either. How about "is
accessable through query mechanisms"?
That works for me.
Also, during further editing I have changed the tone of the paragraph
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. W
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
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 ca
On Sat, Jan 23, 2010 at 08:00:17PM -0500, Matt Larson wrote:
> 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 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
--On 23 January 2010 12:25:00 -0500 Olafur Gudmundsson
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 went further an
At 15:54 22/01/2010, Alex Bligh wrote:
--On 22 January 2010 15:45:54 -0500 Edward Lewis 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.
--On 23 January 2010 04:56:33 + Alex Bligh 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 squat with a non-exis
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 i
On Fri, 22 Jan 2010, Alex Bligh wrote:
If I secure example.org, and .org is signed, OPT-OUT might cause a spoofed
exemple.org to not be caught by the user's validating resolver. Therefor,
I do think opt-out should be avoided when possible.
If I run .org, which is signed, but example.org is NOT
--On 22 January 2010 15:45:54 -0500 Edward Lewis
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" t
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 u
Paul,
--On 22 January 2010 14:51:38 -0500 Paul Wouters 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 know what
you mean
On Fri, 22 Jan 2010, Alex Bligh wrote:
completely ignores opt-out. How about
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 f
--On 22 January 2010 23:09:11 +1100 Mark Andrews 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 probably the poste
--On 22 January 2010 12:04:07 +0100 Olaf Kolkman 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 (1) it is not
the da
On Jan 22, 2010, at 1:09 PM, Mark Andrews 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.
ACK good point. Maybe we need a l
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.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
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: http://www.nlnetlabs.nl/svn/rfc4641bis/t
79 matches
Mail list logo
