On Fri, Oct 17, 2014 at 3:20 PM, Joe Abley <jabley@hopcount.ca> wrote:

On 17 Oct 2014, at 16:55, Warren Kumari <warren@kumari.net> wrote:

echo -n '. '; wget -q -O - https://data.iana.org/root-anchors/Kjqmt7v.crt | openssl x509 -text -inform der| grep 'Subject:' | cut -d ' ' -f16- > root.anchor

Now can I have a cookie?

You can if you can explain what your trust on the retrieved Kjqmt7v.crt file is based on, and how you came up with that filename.

'm blindly trusting the SSL. As for the filename -- I looked at https://data.iana.org/root-anchors and found something that ended in .crt. So, where's my cookie? (you didn't have to say that they had to be reasonable explanations...)

Also, I'm taking five points off your score for using wget instead of curl, but that's just because I'm unreasonable.

Unless you skipped to the end, your trust in that certificate is based on trust in whatever CDN ICANN is using for data.iana.org (which you don't know, don't pretend you looked)

... actually I *did* look, but that is only because wget threw all of its toys out the cot because it didn't have Digicert in its trust store... I was going to get all huffy at you fir that, but then I realized it didn't have *anything* in its trust store, because I'd replaced it with an empty test one, for testing....

and the TLS (or, let's be pessimistic, SSLv3) that was negotiated between your wget and the CDN's servers. This doesn't smell very good to me, and I think we can aim higher.

Oh yes, 100% agree. We can, and should, do better -- however, even the blindly trust SSLv3 is better than the current solution which most folk use, which is, AFAICT, 'dig +short DNSKEY > root.ta' and then some futzing with vi... Actually, that;s not really true -- I'm fairly sure *most* people use the TA that comes with their OS distribution.

(Needlessly snotty, passive aggressive way of pointing out that the technique in the draft is simple enough that many folk may be doing this without an "implementation")

The intention was that you would be able to find many certificates on data.iana.org, and that you would keep looking until you found one with a valid signature chain back to a certificate you actually trust (e.g. a code-signing cert used for software updates, etc).

The signature in the cert you retrieved was made by a proof-of-concept IANA CA which properly ought to be trusted by nobody. The PGP detached PGP and S/MIME signatures in that directory are similarly untrustworthy.

Yup. I once tried to "securely" get the TA, just as an exercise. The process went something like: dig +short DNSKEY > file1 cut-n-paste from https://iana.org > file2 curl (see!) https://data.iana.org/root-anchors/icann.pgp, then much looking at the key and wondering what possible use I can make of it, seeing as I've never met someone called DNSSEC Manager <dnssec@iana.org> <many hours of fascinated clicking in the gnupg.org website later, wondering why it's a 1024bit DSA key while the root key itself is a 2048 bit RSA key, and if this matters at all, some time reading SP800, some more time on keylength.com, some time idly staring out the window, a brief sojourn on the wikipedia page for Pierre de Fermat which led, as all wikipedia adventures eventually do, to something related to ice-cream (I have a clever proof of this somewhere), in this case "Chilled caramel topping" (Fermat -> Newton -> Newtonian fluid -> non-newtonian fluid -> caramel topping -> ice-cream)) After a frozen snickers bar I returned, finally managed to make gpg show me the signatures on that key, recognized Olaf K and then decided I had lost interest in the whole game...

What was envisaged was that DNSVendor, Inc. would make arrangements with ICANN to retrieve a trusted copy of the CSR containing the root zone trust anchor set and sign it according to their normal certificate management practices with a key that client software has a means to trust, and publish the resulting certificate on data.iana.org along with similar certificates from NameVendor, Inc. and anybody else who has a need to distribute software to bootstrap trust in DNSSEC.

Yup. It's a nice theory, but I suspect that the process goes something like (assuming the DNS folk at DNSVendor know about the draft): Engineer 1: Oooh! That's kinda cool, let's do that. Engineer 2: Erm. Sure. Wait, what exactly do we sign? And with what key? And how do customer's trust whatever key we use?! Oh, we bake it into... well... Meh, we'll figure that bit out later, let's go do this. Engineer 1: 'k, first approve my change, CL #34434.1 Engineer 2: What?! Huh?! You are passing the output of unsigned char *foo (int) to void bar (*double), in what world is that a good idea. Engineer 1: Well, I make sure it really is a .. well... <sometime later> Engineer 1: Great, I fixed the CL and also started writing the IANA cert thing. Lawyer -- So, explain what exactly it means to sign this key, and who has the liability if we sign the wrong key? What are we attesting to *exactly*? And, what happens if IANA rolls the root and we don't resign? (somehow this is a very technical lawyer). Engineer 1 and 2: Um... well... we... it's exactly the same as currently, where we sign our distribution... Lawyer -- .. and that includes us signing stuff from other people, who don't work for just, does it? Engineer 1 and 2: ... well, there is this whole /contrib directory, and... yeah, um, we'll come back later when you are less busy... Engineer 1 and 2, exist stage right...

This has been poorly communicated, or there is no interest, or there is some other reason why this has not happened.

I'm guessing it is both that it is a: a draft and it is unclear if the process will stay that same (seeing as folk keep leaving ICANN), b: more work / complexity and c: the current solution of slapping the key somewhere and having it signed by the unix distro seems to be working... (insert monty python Spanish Inquisition "... our chief weapons are ... " trope). Don't get me wrong, I really do think that this document is useful, and important, and should be tidied and published, but I think that main uses of it will be: a: grabbing the TA over TLS from the iana web page and comparing the key with what dig says and b: verifying pgp signatures against people we know. I'd personally prefer that the key itself be signed by a bunch of known people (and not that the key be signed by a key signed by people... ), but this is harder... W

Joe

-- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf