589537 - Using DNSSEC to associate TLS keys with domain names

Status: RESOLVED DUPLICATE of bug 672239

(NSS :: Libraries, enhancement)

Description

[Neil Harris]

http://tools.ietf.org/html/draft-hoffman-keys-linkage-from-dns-00 , "Using Secure DNS to Associate Keys with Domain Names For TLS", is a standards-track working draft for a way to associate TLS keys with DNS records served via DNSSEC. 

This is a tracking bug to identify the numerous technologies which need to be put in place in the Mozilla codebase in order to implement a scheme such as this.

Comment 1

[Neil Harris]

See Bug 179519 for a similar idea in the field of email; however, that idea seems not to have caught on the extent of being submitted as an Internet-Draft.

Comment 2

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

This is a more recent draft:

Using Secure DNS to Associate Certificates with Domain Names For TLS
http://www.ietf.org/id/draft-ietf-dane-protocol-06.txt

Comment 3

[Matt McCutchen]

I have a proof-of-concept implementation at https://mattmccutchen.net/cryptid/#nss-dane .  A lot of things are missing as described in the included TODO.

Comment 4

[Paul Wouters]

I have done some testing with this and had success (.12.9-8.fc14.x86_64 with firefox3.6.15-1.fc14.x86_64)

I would also like to see this method include a "TLS bare public key" for which I'm drafting a proposal at the moment for the TLS WG. This should help firefox from not needing to read "unvalidatable" information into the certificate pool (such as CN= or Expiry=) by limiting the scope to *just* the public key and the DNS hostname.

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

David, please check out Matt's work and Paul's work.

David and I (mostly David) will be working on things related this during this summer.

Comment 6

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Briefly, we are going to experiment with doing something vaguely similar to what has been done in Chromium: stapling a DNSSEC chain into the TLS handshake, instead of retrieving the DNS records over the DNS protocol itself.

Comment 7

[Paul Wouters]

(In reply to comment #2)
> This is a more recent draft:
> 
> Using Secure DNS to Associate Certificates with Domain Names For TLS
> http://www.ietf.org/id/draft-ietf-dane-protocol-06.txt

and there is now http://www.ietf.org/id/draft-ietf-dane-protocol-07.txt with support for storing just the SubjectPublicKeyInfo in DNS

Comment 8

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Chrome now has this enabled by default in dev builds:

http://www.imperialviolet.org/2011/06/16/dnssecchrome.html

Comment 9

[Matt McCutchen]

(In reply to comment #6)
> Briefly, we are going to experiment with doing something vaguely similar to
> what has been done in Chromium: stapling a DNSSEC chain into the TLS
> handshake, instead of retrieving the DNS records over the DNS protocol
> itself.

That only solves the additive part of the problem.  Additive statements have significant benefits (convenience and moving away from extensive use of cert overrides), but restrictive statements have other, equally important benefits (removing the exposure to the increasingly untrustworthy public CA system).  If you are going to proceed as above, I want to have separate RFEs for additive and restrictive statements (either two new bugs blocking this one, or narrow this one to additive and have another for restrictive) to support appropriate separate discussion and resolution.

Comment 10

[Paul Wouters]

(In reply to comment #9)
> (In reply to comment #6)
> > Briefly, we are going to experiment with doing something vaguely similar to
> > what has been done in Chromium: stapling a DNSSEC chain into the TLS
> > handshake, instead of retrieving the DNS records over the DNS protocol
> > itself.
> 
> That only solves the additive part of the problem.  Additive statements have
> significant benefits (convenience and moving away from extensive use of cert
> overrides), but restrictive statements have other, equally important
> benefits (removing the exposure to the increasingly untrustworthy public CA
> system).  If you are going to proceed as above, I want to have separate RFEs
> for additive and restrictive statements (either two new bugs blocking this
> one, or narrow this one to additive and have another for restrictive) to
> support appropriate separate discussion and resolution.

I thought this was still restrictive. The dnssec chain from the root to the server's FQDN is embedded, and you check the dnssec crypto of that chain. If that leads to the same public key as is in the cert itself, you're good to go. If not, abort.

In this case, trust came from the DNSSEC root key, not from a CA who signed the cert (though both could be done, not sure if CAs allow "new blobs" to be added to a cert though...

Comment 11

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

The goal is to eventually make it so that once the browser knows a site us using the DNSSEC-based mechanism, the site must always use the DNSSEC-based mechanism, forever. That is, once a site starts using this mechanism, we would never trust *just* a X.509 certificate chain for that site, ever again. (That is greatly oversimplifying things, and DoS, "secure undo," etc. need to be explained, but that's the gist of it.) So, it would be both an inclusion and an exclusion mechanism at the same time, and it would not be useful to separate the inclusion mechanism from the exclusion mechanism, except to say which CAs can issue EV certificates. (Note that DV certificates would become completely useless, AFAICT, in such a system.)

Comment 12

[Leen Besselink]

@Paul Wouters it didn't look like to it to me that these certificates for Chrome would allow being signed with a DNSSEC-chain and by the CA at the same time.

It is also why in the blogpost he talks about how this will improve self-signed certificates.

Which makes it pretty much useless in the real world as it isn't compatible with what most people are using now. :-(

There might be a way, which is that the CA resigns the cert every night or so, which to me seems highly unlickly to happen on a large scale. Even if they would want to do it for all the EV-certs for banks sites only it would be a big undertaking.

Comment 13

[Matt McCutchen]

(In reply to comment #11)
> The goal is to eventually make it so that once the browser knows a site us
> using the DNSSEC-based mechanism, the site must always use the DNSSEC-based
> mechanism, forever.

In other words, the effect would be like an HSTS directive "max-age=forever; requireDnssec".  And like HSTS, you are vulnerable on the first connection from each browser profile or after leaving private browsing, etc.  My RFE for a 100% solution stands.

Comment 15

[Adam Langley]

(In reply to comment #12)
> @Paul Wouters it didn't look like to it to me that these certificates for
> Chrome would allow being signed with a DNSSEC-chain and by the CA at the
> same time.

It's very unlikely that you would be able to find a CA to sign a certificate that contained an embedded DNSSEC chain. The Chrome code is designed to add DNSSEC as a way to authenticate HTTPS, not as an addition to CA authentication.

I'll take a look at any Mozilla proposals in this space, of course, but I'll let Brian figure out what he'd like to do first.

Comment 16

[Bry8Star]

"DNSSEC Validator" (www.dnssec-validator.cz) , "Extended DNSSEC Validator" (www.os3sec.org) addons now allow to see which site using correctly dnssec signed dns rr, and which are not, and which does not have any yet.

But ultimately TLSA detection should be built-into Firefox/Thunderbird/Gecko core itself , ability to use a local DNSSEC supported dns-resolver / dns-client, when present.

TLSA for Mozilla.org:

_443._tcp.mozilla.org. 300 IN     TLSA    1 1 1 Hex-Hash-Code-of-SSL-Cert

_443._tcp.www.mozilla.org. 300 IN     TLSA    1 1 1 Hex-Hash-Code-of-SSL-Cert

TLSA is aka TYPE52.

Other TLSA for Mozilla's own usage purpose:
_25._tcp.mail.mozilla.org. 300 IN TLSA 1 1 1 Hex-Hash-Code-of-SSL-Cert
_993._tcp.mail.mozilla.org. 300 IN TLSA 1 1 1 Hex-Hash-Code-of-SSL-Cert
_995._tcp.mail.mozilla.org. 300 IN TLSA 1 1 1 Hex-Hash-Code-of-SSL-Cert

in above three examples i assumed your IMAPS/993, SMTP+StartTLS/25, POP3S/995 etc services are using same host : mail.mozilla.org.

If your SSL cert for mozilla.org is in "mozilla.org.pub.crt" file.
Then "Hex-Hash-Code-of-SSL-Cert" can be found by:

openssl x509 -in mozilla.org.pub.crt -outform DER | openssl sha256 

or use "tlsa" tool, by Paul Wouters.

Other example TLSA can be viewed from such sites : 
http://www.internetsociety.org/deploy360/resources/dane-test-sites/

And also please add the "CERT PGP" dns record, for sharing your public-side (master or 2nd-level) GPG-KEY code, which you used to SIGN your binary-installers and other files. Full/entire GPG key code (public-side) can be added into CERT PGP dns record, and that is very important. For more info on this paragraph pls see this bug report : GPG KEY Not Found In Your DNS Records - https://bugzilla.mozilla.org/show_bug.cgi?id=869053

References:

* DANE https://tools.ietf.org/html/rfc6394
* TLSA https://tools.ietf.org/html/rfc6698
* CERT PGP / GPG in DNS : https://tools.ietf.org/html/rfc4398
  above doc obsoletes http://www.faqs.org/rfcs/rfc2538.html
* DNSSEC and Certificates (Oct 19, 2012) - by Shumon Huque ( How to convert any server cert or CA cert or self-signed cert or paid cert .crt file into a TLSA dns record based cert, using 'openssl' tool, for adding in DNSSEC supported domain-name, so that users/visitors can verify SSL cert from DNS record via using DANE supported apps ) : http://blog.huque.com/2012/10/dnssec-and-certificates.html
*  Article author 'Paul York' has written this article (on Nov 30, 2012), and informing us, How to use software named "Hash-Slinger"/tlsa created by 'Paul Wouters', to pull-up a SSL/TLS certificate from a web-site ( which is already pre-configured to use a SSL/TLS cert over HTTPS), and then convert that SSL/TLS cert into its equivalent TLSA dns record, so that site visitors can use it via DANE/DNSSEC supported apps : http://www.internetsociety.org/deploy360/blog/2012/11/hash-slinger-helps-you-easily-create-tlsa-records-for-dnssec-dane/
* DANE DNSSEC Test Sites - http://www.internetsociety.org/deploy360/resources/dane-test-sites/ 

-- Bright Star (Bry8Star). 
bry 8 st ar a.t ya hoo d.o.t c om
GPG_FPR=12B7 7F2C 92BF 25C8 38C6 4D9C 8836 DBA2 576C 10EC.
gpg key-id is last 8 digit of above code.

Comment 19

[:Atoll]

Bug 672239 is now the tracking bug for DNSSEC/TLS work, per https://wiki.mozilla.org/Security/DNSSEC-TLS-details so I am marking this bug as dupe-of that bug. Apologies for the noise.