[ksk-change] Action #4 - Review Joe Abley's Internet Drafts

[Warren Kumari]

On Fri, Oct 17, 2014 at 3:20 PM, Joe Abley <jabley at hopcount.ca> wrote:
>
> On 17 Oct 2014, at 16:55, Warren Kumari <warren at 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 at 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