[9fans] Are we ready for DNSSEC ?

[9fans] Are we ready for DNSSEC ?

[maht]

By the end of May, all the root servers should be running DNSSEC

http://royal.pingdom.com/2010/01/19/the-internet-is-about-to-get-a-lot-safer/

Is Plan9 ready for such a move?

Re: [9fans] Are we ready for DNSSEC ?

[erik quanstrom]

On Wed Jan 20 08:27:58 EST 2010, maht-9fans@maht0x0r.net wrote:
> By the end of May, all the root servers should be running DNSSEC
>
> http://royal.pingdom.com/2010/01/19/the-internet-is-about-to-get-a-lot-safer/
>
> Is Plan9 ready for such a move?

there are two answers to this:

yes, if you mean by this that plan 9 dns will continue to
operate.

no, if you mean by this that plan 9 dns will be able to use
or serve dnssec records.

one would likely need to start with a different structure
than ndb/dns currently has to get dnssec.  but i think that
the most of the query logic could be reused.

- erik

Re: [9fans] Are we ready for DNSSEC ?

[Patrick Kelly]

On Jan 20, 2010, at 8:42 AM, erik quanstrom <quanstro@quanstro.net>
wrote:

> On Wed Jan 20 08:27:58 EST 2010, maht-9fans@maht0x0r.net wrote:
>> By the end of May, all the root servers should be running DNSSEC
>>
>> http://royal.pingdom.com/2010/01/19/the-internet-is-about-to-get-a-lot-safer/
>>
>> Is Plan9 ready for such a move?
>
> there are two answers to this:
>
> yes, if you mean by this that plan 9 dns will continue to
> operate.
>
> no, if you mean by this that plan 9 dns will be able to use
> or serve dnssec records.
>
> one would likely need to start with a different structure
> than ndb/dns currently has to get dnssec.  but i think that
> the most of the query logic could be reused.
As I understand it; It is an extension, the base DNS stuff should not
change.
What would need to be changed in ndb, or would looking at the source
be better?
>
> - erik
>

Re: [9fans] Are we ready for DNSSEC ?

[erik quanstrom]

> > one would likely need to start with a different structure
> > than ndb/dns currently has to get dnssec.  but i think that
> > the most of the query logic could be reused.
> As I understand it; It is an extension, the base DNS stuff should not
> change.
> What would need to be changed in ndb, or would looking at the source
> be better?

i think your understanding ma be incomplete.  dnssec
requires that the rrs be chained together in a particular
order.  and any change to a rr triggers resigning.  it
may be doable, but i think it would be easier to start
with dnssec in mind.

- erik

Re: [9fans] Are we ready for DNSSEC ?

[Patrick Kelly]

On Jan 20, 2010, at 10:33 AM, erik quanstrom <quanstro@coraid.com>
wrote:

>>> one would likely need to start with a different structure
>>> than ndb/dns currently has to get dnssec.  but i think that
>>> the most of the query logic could be reused.
>> As I understand it; It is an extension, the base DNS stuff should not
>> change.
>> What would need to be changed in ndb, or would looking at the source
>> be better?
>
> i think your understanding ma be incomplete.  dnssec
> requires that the rrs be chained together in a particular
> order.  and any change to a rr triggers resigning.  it
> may be doable, but i think it would be easier to start
> with dnssec in mind.
That makes their use of the word extension wrong, but in that case
starting over would seem (and probably is) best.
Thanks.
>
> - erik
>

Re: [9fans] Are we ready for DNSSEC ?

[erik quanstrom]

> > i think your understanding ma be incomplete.  dnssec
> > requires that the rrs be chained together in a particular
> > order.  and any change to a rr triggers resigning.  it
> > may be doable, but i think it would be easier to start
> > with dnssec in mind.

> That makes their use of the word extension wrong, but in that case
> starting over would seem (and probably is) best.

i think it fits the definition of extension.  the protocol is
compatable with dnssec-unaware implementations.

- erik

Re: [9fans] Are we ready for DNSSEC ?

[Patrick Kelly]

>
>> That makes their use of the word extension wrong, but in that case
>> starting over would seem (and probably is) best.
>
> i think it fits the definition of extension.  the protocol is
> compatable with dnssec-unaware implementations.
Since part of the base was modified, but it's still backwards
compatable extension isn't the right term, I can not think of the
proper word; I am being anal.

At any rate, was there a date this would be implimented? I'm looking
forewards to seeing how much this actually fixes.
> - erik
>

Re: [9fans] Are we ready for DNSSEC ?

[Russ Cox]

> starting over would seem (and probably is) best.

http://www.jwz.org/doc/cadt.html

Re: [9fans] Are we ready for DNSSEC ?

[erik quanstrom]

On Wed Jan 20 12:49:14 EST 2010, rsc@swtch.com wrote:
> > starting over would seem (and probably is) best.
>
> http://www.jwz.org/doc/cadt.html

you have a design then that will
do dnssec without any rewriting?

- erik

Re: [9fans] Are we ready for DNSSEC ?

[Patrick Kelly]

On Jan 20, 2010, at 12:47 PM, Russ Cox <rsc@swtch.com> wrote:

>> starting over would seem (and probably is) best.
>
> http://www.jwz.org/doc/cadt.html
>
Given the small amount of information I had...
I havent even looked at the source yet...

Re: [9fans] Are we ready for DNSSEC ?

[Russ Cox]

On Wed, Jan 20, 2010 at 10:17 AM, erik quanstrom <quanstro@coraid.com> wrote:
> On Wed Jan 20 12:49:14 EST 2010, rsc@swtch.com wrote:
>> > starting over would seem (and probably is) best.
>>
>> http://www.jwz.org/doc/cadt.html
>
> you have a design then that will
> do dnssec without any rewriting?

i certainly think it can be done without starting over from scratch.

russ

Re: [9fans] Are we ready for DNSSEC ?

[John Barham]

> By the end of May, all the root servers should be running DNSSEC
>
> http://royal.pingdom.com/2010/01/19/the-internet-is-about-to-get-a-lot-safer/
>
> Is Plan9 ready for such a move?

Reading what D. J. Bernstein has to say about DNSSEC is always fun.
See e.g. this paper http://cr.yp.to/talks/2009.08.10/slides.pdf about
abusing DNSSEC to launch denial of service attacks.  He has also
proposed an alternative to DNSSEC, http://dnscurve.org/.

Re: [9fans] Are we ready for DNSSEC ?

[erik quanstrom]

> > By the end of May, all the root servers should be running DNSSEC
> >
> > http://royal.pingdom.com/2010/01/19/the-internet-is-about-to-get-a-lot-safer/
> >
> > Is Plan9 ready for such a move?
>
> Reading what D. J. Bernstein has to say about DNSSEC is always fun.
> See e.g. this paper http://cr.yp.to/talks/2009.08.10/slides.pdf about
> abusing DNSSEC to launch denial of service attacks.  He has also
> proposed an alternative to DNSSEC, http://dnscurve.org/.

this isn't a technical discussion.  regardless of the merits,
they're not implementing dnscurve on the root servers.
they're implementing dnssec.

so if you're interested in securing dns, say to prevent ssl
mitm attacks, i only see three choices
1.  hold your nose.  do dnssec.
2.  put your head in the sand.
3.  convince the world to use dnscurve.

- erik

Re: [9fans] Are we ready for DNSSEC ?

[Russ Cox]

> so if you're interested in securing dns, say to prevent ssl
> mitm attacks, i only see three choices
> 1.  hold your nose.  do dnssec.
> 2.  put your head in the sand.
> 3.  convince the world to use dnscurve.

if the goal is avoiding ssl mitm attacks,
dns is the least of your worries. a mitm will
just take over the connection attempt for the
actual ip address.  the solution there is
to implement proper ssl certificate chain checking.

russ

Re: [9fans] Are we ready for DNSSEC ?

[erik quanstrom]

> if the goal is avoiding ssl mitm attacks,
> dns is the least of your worries. a mitm will
> just take over the connection attempt for the
> actual ip address.  the solution there is
> to implement proper ssl certificate chain checking.

doesn't work with the recent renegotiation bug.
it's a server attack, not a client attack.  but i don't
think one can dismiss dns as a non-issue.

- erik

Re: [9fans] Are we ready for DNSSEC ?

[Russ Cox]

On Sat, Jan 23, 2010 at 5:01 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> if the goal is avoiding ssl mitm attacks,
>> dns is the least of your worries. a mitm will
>> just take over the connection attempt for the
>> actual ip address.  the solution there is
>> to implement proper ssl certificate chain checking.
>
> doesn't work with the recent renegotiation bug.

disable renegotiation.

> but i don't
> think one can dismiss dns as a non-issue.

dns is a non-issue if the rest of ssl is working.
dns is irrelevant if it isn't.

russ

Re: [9fans] Are we ready for DNSSEC ?

[erik quanstrom]

> > doesn't work with the recent renegotiation bug.
>
> disable renegotiation.
>
> > but i don't
> > think one can dismiss dns as a non-issue.
>
> dns is a non-issue if the rest of ssl is working.
> dns is irrelevant if it isn't.

the renegotiation bug is a protocol flaw.  i'm
not so sure i trust ssl enough to decide i don't
care of dns gets hijacked.

- erik

Re: [9fans] Are we ready for DNSSEC ?

[hiro]

so you need to have a more "secure" dns because you don't trust your ssl?

On Sun, Jan 24, 2010 at 2:18 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> > doesn't work with the recent renegotiation bug.
>>
>> disable renegotiation.
>>
>> > but i don't
>> > think one can dismiss dns as a non-issue.
>>
>> dns is a non-issue if the rest of ssl is working.
>> dns is irrelevant if it isn't.
>
> the renegotiation bug is a protocol flaw.  i'm
> not so sure i trust ssl enough to decide i don't
> care of dns gets hijacked.
>
> - erik
>
>

Re: [9fans] Are we ready for DNSSEC ?

[erik quanstrom]

On Sun Jan 24 08:21:50 EST 2010, 23hiro@googlemail.com wrote:
> so you need to have a more "secure" dns because you don't trust your ssl?

do you feel dnssec provides the same or worse security?  why?

the simple answer to your question is yes.  the renegotiation bug
in ssl requires you to start talking to the wrong server.  (this attack
wouldn't be necessary if you're attacker is behind the ssl termination pts.)
a similar attack could work against imperfect certificate checking.
since the easiest way to get someone to the wrong place is to give
them the wrong address, i think a more secure dns helps.

as to fixing the renegotiation bug by turning it off: do you feel
confident that you know how to do this (is it possible) with every
bit of ssl-capable equipment you own?  i don't.  i also don't think
it's the only attack than can be facilitated by first owning dns.

more food for thought.  the ca chains just aren't that well-verified.  it
was easy enough to get a bogus microsoft certificate a few years
back.  if you can own dns, and get a bogus bigco.com cert, you're
in business.

- erik

Re: [9fans] Are we ready for DNSSEC ?

[Tim Newsham]

> dns is a non-issue if the rest of ssl is working.
> dns is irrelevant if it isn't.

Except when SSL has chinks in its armor.  Like incidents of
certificate authorities being convinced to give out certs for
domains that don't belong to the requestor.  Or bugs in SSL
cert validation that compares names only up to the NUL character
and certificate authorities willing to make CERTs with NULs
in the cert name. Or certificate authorities giving out unqalified
"local" certificates that can be repurposed as non-local certs.
Or simply the fact that the majority of the
SSL using population has been trained to disreguard SSL mismatches
by clicking through any dialog box that appears while browsing.

At any rate, it would be nice having a certificate system that
was more closely tied to the DNS heirarchy...

> russ

Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com

Re: [9fans] Are we ready for DNSSEC ?

[Russ Cox]

you are changing the topic.

your original mail claimed to be worried
about man-in-the-middle attacks.  that means
the attacker can respond to arbitrary traffic;
the fact that you can verify the dns response
is irrelevant if when you try to connect to the
correct ip address the attacker handles it
and you don't take advantage of ssl certificates
to catch that.

russ

Re: [9fans] Are we ready for DNSSEC ?

[Tim Newsham]

> you are changing the topic.
>
> your original mail claimed to be worried
> about man-in-the-middle attacks.  that means
> the attacker can respond to arbitrary traffic;
> the fact that you can verify the dns response
> is irrelevant if when you try to connect to the
> correct ip address the attacker handles it
> and you don't take advantage of ssl certificates
> to catch that.

True, unless DNS provides a certificate that is bound
to the session in some way.

> russ

Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com

Re: [9fans] Are we ready for DNSSEC ?

[erik quanstrom]

On Sun Jan 24 17:15:17 EST 2010, newsham@lava.net wrote:
> > you are changing the topic.
> >
> > your original mail claimed to be worried
> > about man-in-the-middle attacks.  that means
> > the attacker can respond to arbitrary traffic;
> > the fact that you can verify the dns response
> > is irrelevant if when you try to connect to the
> > correct ip address the attacker handles it
> > and you don't take advantage of ssl certificates
> > to catch that.
>
> True, unless DNS provides a certificate that is bound
> to the session in some way.

if one misdirects the original connection via dns and
then uses the renegotiation bug, is this not a
mitm attack?

- erik

Re: [9fans] Are we ready for DNSSEC ?

[Wes Kussmaul]

Tim Newsham wrote:
>> dns is a non-issue if the rest of ssl is working.
>> dns is irrelevant if it isn't.
>
> Except when SSL has chinks in its armor.  Like incidents of
> certificate authorities being convinced to give out certs for
> domains that don't belong to the requestor.

http://instigations.com/fudili/certsetc.html (scroll down)