869053 - GPG KEY Not Found In Your DNS Records

Status: RESOLVED WONTFIX

(Infrastructure & Operations :: DNS and Domain Registration, task)

Description

[Bry8Star]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20100101 Firefox/10.0

Steps to reproduce:

Hi, i tried to obtain GPG KEY code or KEY file & KEY fingerprint from your DNSSEC authenticated full DNS response, the (public-side) (master or 2nd-level) GPG KEY which you use to SIGN your binary installer-files.

So that i can VERIFY your binary installer-files with more/higher surety, that files are indeed from MOZILLA.ORG, and, want to eliminate the possibility/risk of : installer-file is NOT FROM some MITM source, or not from a DNS-spoofed server, or not a different-layer/cast based IP-Forwarding based fake/middle server, or, downloaded file is not a fake file with fake's correct sha1, or not a fake mozilla.org SSL/TLS certificate or intercepted OCSP (certificate verification related) non-HTTPS traffic using installer-file, or not a compromised installer-file claiming itself that it is from Mozilla.org, etc.

To eliminate above risk scenarios, (for now) i have chosen & installed DNS-Trigger (an "Unbound" based) local dns-resolver in my Windows-XP (professional) machine . It is configured properly . I can query pre-known to be correctly dnssec signed sites, and receive proper 'AD' & related responses, and i can also receive correct errror messages for wrongly signed sites such as : http://www.rhybar.cz/ , http://www.dnssec-failed.org/ etc. 

For example by using such commands toward local DNS-Resolver:

dig @127.0.0.1 -c in -t any mozilla.org +dnssec +additional +tcp
dig @127.0.0.1 -c in -t any dnssec-failed.org +dnssec +additional +tcp
dig @127.0.0.1 -c in -t any rhybar.cz +dnssec +additional +tcp
(the 'dig' tool is from bind-util, and was obtained via Cygwin on Windows).

And trace can be done if needed, and/or view debug related data of DNSSEC chain verifying and server connections.

I have also configured an OpenSSH based Socks5 tunnel toward a different (remote) computer in WAN side. This Socks5 tunnel is listening on 127.0.0.1:8088 in my/local computer, it is to enable/allow me, do dns query from a different computer which has a different ISP than my this/local computer, to check & to be sure my dns response are indeed right and same or not.

I have configured a 'socat' instance to forward TCP DNS queries toward a very specific Public DNSSEC Supported & Validating DNS-Resolver/DNS-Server, via going through that Socks5 based tunnel, and send DNS query from that remote WAN side computer : i create the tunnel with this below command . Below command-line is placed inside "socat.cmd", a windows batch-file (which was created using 'Notepad2' type of Text-Editor). And i run it from inside "Command Prompt" ( in keyboard i press : Windows Flag Button + R button , then i type cmd.exe > Ok ) :

@start  "socat 127.0.0.1:54 127.0.0.1:8088 217.31.204.130" /D"%ProgramFiles%\socat\" socat.exe TCP4-LISTEN:54,fork  SOCKS4A:127.0.0.1:217.31.204.130:53,socksport=8088

Then i used, such as these commands with SOCAT based tunnel: 

dig @127.0.0.1 -c in -t any -p 54 mozilla.org +dnssec +additional +vc
dig @127.0.0.1 -c in -t any -p 54 dnssec-failed.org +dnssec +additional +vc
dig @127.0.0.1 -c in -t any -p 54 rhybar.cz +dnssec +additional +vc

i have also changed destination public dns server (IP-address : 217.31.204.130), and restarted tunnels and compared dns query results.

And alternative to 'socat', the 'DNS2SOCKS' type of tool can also be used to forward dns-query via Socks5/SSH tunnels/proxies : i started-up dns2socks using below command-line, it was placed in "dns2socks.cmd" file:

@start  "dns2socks 127.0.0.1:55 127.0.0.1:8088 217.31.204.130" /D"%ProgramFiles%\dns2socks\" DNS2SOCKS.exe 127.0.0.1:8088 217.31.204.130 127.0.0.1:55 /q

Then such/below commands can be used with DNS2SOCKS based tunnel:

dig @127.0.0.1 -c in -t any -p 55 -b 127.0.0.1 mozilla.org +dnssec +additional +vc
or
dig @127.0.0.1 -c in -t any -p 55 mozilla.org. +dnssec +additional
dig @127.0.0.1 -c in -t any -p 55 -b 127.0.0.1 dnssec-failed.org +dnssec +additional +vc
or
dig @127.0.0.1 -c in -t any -p 55 dnssec-failed.org +dnssec +additional
dig @127.0.0.1 -c in -t any -p 55 -b 127.0.0.1 rhybar.cz +dnssec +additional +vc
or
dig @127.0.0.1 -c in -t any -p 55 rhybar.cz +dnssec +additional

To get GPG KEY from DNS-Record, first i used above mentioned commands to see result, if it has any TXT , CERT , TLSA , etc DNS resource records ! 
(2013-05-05, yyyy-mm-dd).

I could have also used commands shown inside below mentioned articles to obtain GPG KEY : http://www.gushi.org/make-dns-cert/HOWTO.html (old article, May 2010) , http://www.df7cb.de/blog/2007/openpgp-dns.html (old article, 2007) , http://www.gnupg.org/documentation/manuals/gnupg/ , etc . In gnupg manual file a user can look into these sections : auto-key-locate , auto-key-retrieve , pka , cert , etc.

Please do point out my mistakes in this process, RELATED TO obtaining CORRECT GPG KEY by using correct encrypted session and from correct server using DNSSEC . Please no need to explain how to obtain or do old or other alternative this or that way of doing it, which does not involve DNSSEC authenticated data (dns query-result). Sorry, I'm not interested in other type of solution, now . This posting/request related to or about DNS based, and next version of advanced and more secured DNS = DNSSEC based solution . This must also be adopted/applied along with other solutions.

-- Bright Star (Bry8Star).
bry 8 st ar a.t ya hoo d.o.t c om

Reference URLs mentioned above.




Actual results:

i tried different commands, and did not see any DNS records which showed any (public-side master or 2nd-level) GPG or PGP KEY url of any pubkey file, or any related fingerprint, or any related entire CERT PGP Key Code,
by using which, Mozilla SIGNs their binary-installer files, so that i/users can verify AUTHENTICITY of installer-files with higher level of assurity/trust-level, that it is indeed really delivered from you, and (almost) no (type of) compromisation has occurred.


Expected results:

for an example, at-least 1 dns record like below could have existed:

mozilla-signing._pka.mozilla.org.  TXT         
"v=pka1\;fpr=FINGERPRINT-HEX-NUMS-OF-SIGNING-GPG-KEY\;uri=https://www.mozilla.org/mozilla-signing.pubkey.txt"

... by assuming your signing key's email-address is [e-mail]

I would prefer to obtain the entire (master-signing or 2nd-level-signing) KEY code from TXT record, even if it is a large as 4KB. It is More Important to deliver correct ENTIRE KEY code to USERS than by using a file/url, to make sure USERS are really getting authentic entire GPG/PGP-KEY code data, and then using it to authenticate files, with lesser chance of failing points, and with lesser complexity.

Even better is to add/keep BOTH GPG/PGP option :
dig +short mozilla-signing._pka.mozilla.org. TXT -->
mozilla-signing._pka.mozilla.org. TXT "v=pka1\;fpr=FINGERPRINT\;uri=URL"
(rfc2538, rfc2440)
dig +short mozilla-signing.mozilla.org. CERT -->
mozilla-signing.mozilla.org. CERT PGP 0 0 LONG-BASE64-ENTIRE-PGP/GPG-KEY-CODE
(rfc4398, rfc3597, rfc2538, rfc2440)
 
BUT if ONLY file/URL option is mentioned/used, THEN such sensitive FILE MUST NEED TO BE DELIVERED TO USERS OVER TLS/SSL/HTTPS ENCRYPTED secured and correct CONNECTION, between mozilla.org server and users computer.

And to be 100% SURE, that we(mozilla-server & users computer) are accurately using a CORRECT SSL/TLS cert OWNED BY MOZILLA.org itself, entire TLS/SSL certificate and its fingerprint ALSO need to be placed in DNS as well. See TLSA, CERT dns-records, related documents. Again, it is more important to make sure USERS are really getting authentic files, with lesser chance of failing points, and with lesser complexity, and over correctly secured connection with correct server, so use BOTH PGP/GPG option mentioned above.

dnssec DANE protocol support built-into software like : "Extended DNSSEC Validator", "DNS-Trigger" etc already allows to obtain DNSSEC Authenticated/correct data, and then it can obtain or extract correct SSL/TLS cert & fingerprint from TLSA, CERT etc DNSSEC-authenticated data, and then it helps to initiate correct (TLS/SSL cert) encrypted/HTTPS connection in between the correct & intended (and not fake) website server, and user's computer/client.

To import entire-pgp/gpg keycode from DNS, user can do one single command:

gpg --no-default-keyring --keyring /tmp/gpg-$$ --encrypt --armor --auto-key-locate cert -r [e-mail]

( gpg is obtained via Cygwin on Windows . gpg from gpg4win can also be used ).

Please do not start to explain or show any other alternatives which does not involve next advanced and more secured version of DNS = DNSSEC.
Thank you.

-- Bright Star (Bry8Star).
bry 8 st ar a.t ya hoo d.o.t c om

Reference URLs mentioned above.

Comment 1

[Mats Palmgren (inactive)]

Seems like a server-side issue...

Comment 2

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Found in triage. Not something that RelEng has access to do, so kicking over to ServerOps (I *guess* that is a better home for this bug?). 

Also, needinfo-ing joes, dveditz and cshields in case they have any ideas.

Comment 3

[Shyam Mani [:fox2mike]]

I'm not really sure why you'd expect to find a gpg public key with a dnssec signed record. Sure, it adds a layer of assuring the user that this data hasn't been tampered with, but short of putting the entire key out there, I don't see how this whole approach makes anything better.

Also, this isn't quite standard use of DNSSEC. It's possible and helps verify the authenticity to a certain extent, but a lot of that is provided by many public gpg keyservers all over the world. I'm not sure about what your intended method of doing this accomplishes, would be nice to know that.

Comment 4

[Michal Purzynski [:michal`] (use NEEDINFO)]

It all comes down to a chain of trust. You want to be able to verify the GPG key used to sign releases, right?

I'd rather not add it to the DNS, it's not a place for it. The DNSSEC is there to provide the verified responses to your queries about some mozilla.org domains, nothing more. It's just one part of the story.

I'd say you should use the public GPG keyservers to fetch the key.

https://gpg.mozilla.org/

Use the httpS version of our server and you have both:
1. verified (by DNSSEC) IP address of the server
2. verified (by SSL) connection to the server (auth+integrity is what matters here)

Clearning the needinfo request, as I don't see anything more we could do here.