Comments on a soon to be published article on DNSsec

-----BEGIN PGP SIGNED MESSAGE-----

  My friend Anonymous (humm, he should put in SOME sort of email
address...) has written an article on actually setting up DNSsec in
the one place in the world where it might work this week, the
Netherlands.

  The article was written in Dutch, but he has translated it for
linguistic cripples like us from the USSA.  Below are my comments on a
not yet publics English translation (I don't think the Dutch has even
been published yet) of the article.  Please note that this is
_constructive_ feeback, even if it gets a bit harry.

  After I get some sleep I am going to see if following the article I
can actually create my own securied domain.  Once the article is
actually published you should too!

  Frankly, HTML stinks for literature, but we won't go into THAT just
now...  I don't know if there are any useful tools for this, but there
should be HTML 'anchors' at every header and at the begning of every
paragraph.

  Due to the current lack of such things I will reference each section
head and then the relative paragraph from that.  Oh, did I mention
that the original hypertext designs would have solved this problem?



"DNSSEC mini HOWTO"
"DNSSEC in the .nl zone"

  The 'thread' of the article is lost at the first .png and the
paragraph after that.  I puresumed you were going to show us how data
could be corrupted, and that the .pgn would be explained in the text
paragraph after it.

  Insetd the text after the .png is a image caption, even though it
looks like body text.  It should likely be indented from both sides
and done in a lighter font.  While it does describe the image, it is
no way expands on the last sentance of the second paragraph.

  The colorized DNS data .png's are interesting, but how did you get
them?  It would be quite worth while in educating folks like me if the
first line of each was the command to generate them (sand the .png
obviously).


"Digital signature"

  The first sentance in this section is wrong in English, as your use
of "their" could (should) mean the third parties data.

  In the second sentance you might start introducing the DNS mindset,
say with something like ~of a DNS KEY RR (Resource Record).~.

  The data CAN be changed, but it could not be made to match the SIG
RR's any more.

  The last sentence in this first paragrah makes little sence.  Maybe
you mean 'corrupt' rather then 'destroy'?  The last clause is just
totally messed up.

  Are you trying to talk about NS high jacking in the last clause?

  We have aother mystery illo here.

  In this illo you use implicit RR names where the first illo used
explicit RR names for EVERY RR.  It would be better to choose one.

  This illo has the end of SOA (")") in a different place then the
first one.  Consistency is important, and no I am not being a plagued
by a hobgoblin.

  Humm, all of the sudden we have TTL's showing up too.  If nothing
else I hope thats explained below somewhere.

  Two KEY RR's?  Dam, and the flags are identical, guess it would be
to much to ask the IETF for a signing and a operations flag,
considdering recent RFC's...

  Ok, minor cosmetic and IETF issues, but it looks like a signed
domain.  It would be nice to have a text version of this image in a
link as...  I would suggest adding ellipsis's to the truncated data
though, be cear when your editing technical data.


  In paragraph two I am not sure what a SIGned NXT is, maybe the
format of the NXT is self signing and so NXT RR's do not need SIG
RR's?  But they do need SIG RR's, so what are you trying to say.

  Here is a rough patch of English "us there that www.ct.nl only has
a", rewrite this a bit.

  Choose one form of DNSsec or DNSSEC and use just that.  We have been
using the DNSsec form.  It looks like you have chosen one form, but
not the one we chose.  Oh well.


"The Hint"

  Break up the first paragraph.

  You never clearly describe that the DS lives in the parent.

  In paragraph two your description sounds like I am getting the KEY
of the SERVER to compare against the hash in the DS, when I am looking
for the KEY of the DOMAIN specified in the NS that matches the DS.
This is a MAJOR problem, as the trust chan HAS to go to the domain and
not it's server.  You can see that in the .png example image that
follows this paragraph.  I presume that this is a translation error.

  I think the bug is here "hash of the key that ns.xtdnet.nl is
using".  It's the has of the key for ct.nl that ns.xtdnet.nl is
only _serving_, no 'using'.  You then compound the confusion by saying
that your going "to ns.xtdnet.nl and ask for its KEY record.", which
sounds like your getting a KEY RR for ns.xtdnet.nl rather then the KEY
for the domain ct.nl being _served_ by ns.xtdnet.nl.

  Yea, it seems subtle, it's not.

  In looking into this I can see no DS RR's from the host ns.nic.nl
for ct.nl.  If it has them it's refusing to serve them to me.

  Ug, no wonder I can't cut and paste the dam text I am trying to show
you, it's an rottn .png.  Yes, convert the .png's to HTML.

  FYI this .png has the command line that generates the text in the
.png, I think all the example .png's should be this way.

  While I think that the requested data is here in the output of
resolv.pl, I don't think the formatting is useful nor do I think the
logic is quite right in that data is not so much blessed as verified
or counter signed (my fav term).  I think it needs another go round of
output formating and trust chain logic.

  I keep looking at the output of ./resolv.pl, and my mind knows how
it feels to _be_ a Gordian Knot.


"KEY roll-overs"

  Break the second paragraph up at "So we get...".

  FYI this ZSK/KSK signing system will fail in dealing with security
breach key roll over problems, in general this system will fail.  The
meta signing key must be kept offline for this system to be really
useful.  Another thing I will claim is that key length is just NOT a a
serious operational issue except for maybe the .com folks.

  Again the confusion between a DNS server and a DNS domain/zone hits
here at "Its KSK belongs to...".  The DNS server ns.xtdnet.nl is just
a place we get RR's from, the singing (trust) of the data is linked
via the DNS name space and not where the data came from.

  You use the term RR here with out ever havinf first explained what
it means.

  The lsat two sentances of this second paragraph are out of context,
this is a good reason to break up this over large paragraph into at
least three, as you start out trying to describe the KSK/ZSK split,
then talk about the trust path and then say you proved how the KSK/ZSK
split works.  You did nothing of the sort.

  The fourth paragraph is confusing as you have switched topics, at
the word "switched", with lots of state in your head while writing
it.  This paragraph needs to be moved into the next section.  It's
English needs work too, at "The resolve this issue,".


"From DNS to DNSSEC"

  Now that I am here maybe the last paragraph needs it's OWN section!.

  Mention the EXACT name of the snapshot that needs to have it's loose
threads cut out.

  How would a user know to type "Kfnl.nl.+005+25541" in generating a
key?

"""
~> cat *key >> /var/named/fnl.nl  
"""

  The above is VERY site specific and is likely to collide with DNS
zone files named after their zones.  I know it's a pain to try to
describe where this dir is defined in /etc/named.conf, but at least
reference that definition and could you name the files with some sort
of tag?

  It seems that none of this key generation was done off line on a
secure machine, or at least not as described here?  I am at a sentance
that seems to imply that I should have been on an offline machine, but
I was never told to go to an offline machine in the first place.

  Keys (as in the trusted key for .nl) should be accompanied by a
comment stating useful human readable info like incept date,
expiration date, etc., otherwise it gets hard to know what your
trusting...

  For the various commands like the "dig +dnssec"... etc link to a
page with the CORRECT output on them, and I would suggest highlighting
the relevant sections in the output.  How can I tell if the "ad" flag
is set with out an example after all?

  Matter of fact if the data on your own disk does not verify, why
should you serve it to anyone?  As I keep saying, in this biz you
gotta eat your own dog food...


"Creating the DS record"

  The parrent does not 'secure it', they just counter sign our
securing out own domain.  This is an important point in WHO owns what
here.

  You need to say that in the .nl domain you can request...

  Here you have an nice webpage, but how do _I_ get to it?  You need
to clearly state the URL (how about a link in this online
version...).  Ah, this is whats hidden behind the [6].  Pleaes expand
it, after all a friend of mine recently said "There are no wordcount
restrictions on a webpage"...

  Whats this about two days?  WTF?  Context?  Is this protocol or BCP
or what?

  s/sent/send/

  We should be able to get the .nl signing time down...  It dam well
better be happening OFFLINE!

  The .png with the red circle (like all the illos) needs the caption
to be in a smaller font so that it's clear it's a caption.  The gripe
about two days above of mine is because the caption looks like body.

  You need to be careful once you start showing images of websites, as
I can't follow you there.  Maybe if I clicked on the small iamges and
got bigger ones that I could read?


"KSK roll-over"

  Hum, it's easy to get the wrong acronym in the wrong place in
paragraphs like this one...

  You need to prove to me (maybe in the next article) that key roll
over does not cause an interruption in service.

  After reading your article I am still not clear on the two keys,
they need a better introduction to how they work.


"Conclusion"

  The "[10]" is not a HTTP link for some reason?

  You got the name of FreeS/WAN wrong.

  This is a chance to advertise WAVEsec, as it REALLY wants to use
DNSsec! Add it!

  The same goes for dynamic DNS, OE and VPN IPsec (FreeS/WAN again).

  There is also a draft on securing DHCP with DNSsec that just got
published that you can reference.  Ask <[email protected]> for a
reference to it.




  While I have made a lot of criticisms, you have done what no one
else has attempted yet, and that is show folks how to actually _setup_
DNSsec in a way that works.

  You do know that the online version of the article lacks an author,
copyright and licence...

  Thank you.

		||ugh Daniel
		[email protected]

			Systems Testing & Project mis-Management
			The Linux FreeS/WAN Project
			http://www.freeswan.org


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: For the matching public key, finger the Reply-To: address.

iQCVAwUBPl4XzFZpdJR7FBQRAQGjiQQAj6veomLGnk0ALjFz/pDC4XTS8dp+tl4Z
khp66yEenwwgaJIEMCdA9XuS1wpDBEjXJ9BunxPDh7sTxb6V8o/TK/Z045MSns9A
NnfBl/K8fjHXvHI/c+VJkA5L5CcguPofyKq/DexmFA++KH8PAzqsUmho4xuRifL8
ODBCHVmTcVQ=
=lfY6
-----END PGP SIGNATURE-----