|
|
| (36 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| This set of pages documents the TLS domain validation through DNSSEC project. This document is currently a work in progress. There are likely many errors.
| | {{FeatureStatus |
| | | |Feature name=DNSSEC-TLS |
| == Goal ==
| | |Feature stage=Development |
| Implement domain validation for TLS connections using DNSSEC in Firefox. That is, in addition to sending a certificate in the TLS handshake, a server would send sufficient DNSSEC records to convince the client of its identity and establish public key material.
| | |Feature status=In progress |
| | | |Feature health=OK |
| == Background == | | }} |
| | | {{FeatureTeam |
| For more background information on TLS and DNSSEC, click [[Security/DNSSEC-TLS/Background|here]].
| | |Feature lead engineer=David Keeler |
| | | }} |
| === Embedding Certificate Information in DNS ===
| | {{FeaturePageBody |
| [http://tools.ietf.org/html/draft-ietf-dane-protocol-07 DANE], [http://tools.ietf.org/html/draft-hallambaker-donotissue-04 Certification Authority Authorization (CAA)], and [http://tools.ietf.org/html/rfc2538 CERT] records are all methods of embedding certificate information in DNS records. With DANE, either the public key or entire certificate (or the hash thereof) may be put in a TLSA record that specifies, for example, the certificate or public key to be used for connecting to example.com tcp port 443 (in the record _443._tcp.example.com). CAA uses the hash of the certificate and can specify that any certificate issued for (for example) example.com must be rooted by the hashed certificate. CAA uses TYPE257 records. CAA has other policy options, as well. CERT simply embeds a certificate in a DNS record. For the time being, while CAA is powerful, it has been determined to be too complicated for this use case. Furthermore, CERT can only specify whole certificates, not just public keys, and is thus too restrictive. Thus, DANE alone will initially be supported.
| | |Feature overview=This feature performs domain validation in TLS sessions by using DNSSEC chains. |
| | | |Feature users and use cases=Server administrators can put key/certificate information in DNS records they control (e.g. TLSA records). This information is verifiable through DNSSEC. The browser can then use this in place of or alongside certificate chain validation. |
| === Domain Validation === | | |Feature functional spec=https://wiki.mozilla.org/Security/DNSSEC-TLS-details |
| To use DNSSEC to perform domain validation, a key or certificate must be put in a DANE record corresponding to the server to validate. Then, during the TLS handshake, the chain of DNSSEC records from that record to an agreed-upon root must be sent along with the server certificate. The client can walk this chain of records to a trusted root to validate the material. If this succeeds, the client then uses either the embedded key material or the key material in the server certificate (that hast just been validated by the DNSSEC chain) as the public key for a key exchange. Note that if the DANE record consists of an entire certificate and that certificate will always be sent in the TLS handshake, the DANE record itself may be omitted. In this case, the RRSIG record for the DANE record will have to be used to validate the certificate sent in TLS.
| | |Feature implementation notes=Tracking bug: [https://bugzilla.mozilla.org/show_bug.cgi?id=672239 672239] |
| | | }} |
| Obviously this mechanism could work out of band. That is, instead of embedding the DNSSEC chain in the TLS handshake, the client could perform simultaneous DNSSEC lookups to verify the material in the server certificate. However, this would be significantly slower as it would involve multiple round-trip communications with another server.
| | {{FeatureInfo |
| | | |Feature priority=Unprioritized |
| === How this is Different from Certificates ===
| | |Feature theme=Security Leadership |
| | | |Feature roadmap=Platform |
| This mechanism does not require the involvement of a certificate authority. A server can issue a self-signed certificate and bind that certificate to a DANE record (either by key, whole certificate, or hash of either). Then, provided there exists a valid DNSSEC chain back to the root of trust, the self-signed certificate will be authenticated by that chain in the TLS handshake.
| | |Feature secondary roadmap=Security |
| | | }} |
| Alternatively, a server can use a certificate issued by a CA. In this case both the certificate chain and the DNSSEC chain must be valid.
| | {{FeatureTeamStatus}} |
| | |
| This mechanism prevents CAs mis-issuing certificates. If a CA issues a certificate it was not supposed to, and that certificate gets used, it will not match the contents of the DANE/CAA record. Of course, the server with the bad certificate could simply omit the DNSSEC chain, so if none is sent, perhaps we should perform the out of band DNSSEC chain verification ourselves.
| |
| | |
| == DNSSEC Chains ==
| |
| | |
| The process of verifying a DNSSEC chain is discussed in general [[Security/DNSSEC-TLS/Background#Verifying a DNSSEC Chain|here]].
| |
| | |
| The format of a serialized DNSSEC chain sent in this protocol consists first of a series of the following:
| |
| | |
| * A DS (and corresponding RRSIG) record for a zone to enter, in wire format.
| |
| * The DNSKEY (and corresponding RRSIG) records for that zone, in wire format. The DS must correspond to one of the keys.
| |
| | |
| Each zone entered must be directly inner to the previous zone. The root zone may be omitted, because it is assumed that the client already has the DNSSEC keys for the root. The final entry is a TLSA (and corresponding RRSIG) record, again in wire format.
| |
| | |
| It is possible to optimize away some fields of these records, but at the moment this is not being done.
| |
| | |
| For reference, another proposal for the serialization of a DNSSEC chain is [http://tools.ietf.org/html/draft-agl-dane-serializechain-00 here]. Note that this proposal does not follow exactly the wire format of DNS records. Consequently, preexisting code cannot be used to serialize, parse, or validate the chain. Additionally, more flexibility means more opportunities for insecure verifier behavior. This proposal is not currently being used in this project.
| |
| | |
| == Google Chrome ==
| |
| | |
| According to [http://www.imperialviolet.org/2011/06/16/dnssecchrome.html Adam Langley's Weblog], DNSSEC validation of TLS (specifically HTTPS) sessions is enabled by default in the canary and dev channels of Chrome. It is achieved through the server sending a self-signed certificate that contains as an X509 extension a blob of data corresponding to the DNSSEC chain. The leaf of the chain is a CAA record. The root of the chain is implicitly the root zone key signing key (the key itself is not included).
| |
| | |
| == Security Considerations ==
| |
| | |
| Using this mechanism, the ability to produce material that authenticates a domain is tied to the doman name hierarchy. That is, an arbitrary organization cannot masquerade as another party unless they control a level of the domain system closer to the root and on the same path as their target. This prevents the current situation where certificate authorities can issue certificates for domains they should not be allowed to. However, this still means that the organization in charge of the root zone can masquerade as any domain, and the organizations in charge of top level domains can masquerade as any domain below theirs, and so on.
| |
| | |
| If a certificate is sent that includes a certificate chain, the certificate chain must validate up to a trusted root. This root is either the certificate identified by the DANE record in the DNSSEC chain or a trusted root CA certificate.
| |
| | |
| OCSP/CRL checking
| |
| | |
| Revocation
| |
| | |
| Configuration of DNSSEC is not significantly more difficult than configuring DNS. As long as private keys are not exposed, it would be difficult to configure DNSSEC in a way that is operable yet insecure.
| |
| | |
| TLS intercepting proxies essentially man-in-the-middle connections made to them. With certificate-based domain validation, users simply install an exception corresponding to the certificate of the proxy, allowing it to be a root of trust. The same idea could be used here, but it would be cumbersome. The proxy would have a root DNSKEY trusted by users. Upon any connection, the proxy could create a chain of DNS records rooted by that key. The users would then verify that chain. This obviously does not work if the DNSSEC chain lookup is done out of band. Another option is to simply fall back on certificate-based validation (with an exception installed by users). Hopefully the proxy itself would verify the DNSSEC chain in its connection to the actual server.
| |
| | |
| == DNSSEC Libraries ==
| |
| | |
| [http://www.nlnetlabs.nl/projects/ldns/ ldns], [https://www.dnssec-tools.org/ DNSSEC-Tools], and [http://unbound.net/download.html Unbound] all use BSD licenses. Thus far, I've had the most success using ldns. Unbound uses ldns.
| |
| | |
| == Creating a TLSA Record == | |
| | |
| Material embedded in a TLSA record must follow the [http://tools.ietf.org/html/draft-ietf-dane-protocol-07 specification]. This involves making the decision of what to embed. As mentioned above, the embedded material may be a certificate identifying an end entity (i.e. the server clients will connect to), a certification authority's certificate (where that certificate is an ancestor of a certificate on the server), or a public key (which may correspond to either of the two situations). Then, the actual data embedded may be the full representation, a sha256 hash, or a sha512 hash. Different decisions may be appropriate for different situations.
| |
| | |
| Once the certificate type and reference type are determined, the appropriate values can be used to construct an entry that goes into the zone file for the DNS server that is authoritative for the domain name in question. For instance, if the sha256 hash of a public key were to be used, the entry might look like this:
| |
| | |
| WWW.EXAMPLE.COM. 60 IN TYPE65468 \# 34 0301731050b68ae9bb14f894a0fd3c2dbe4210336942cdd69036235593ca582e787d
| |
| | |
| (Where the entry is intended to be a single contiguous line.) This specifies a record of type 65468 (experimental number for TLSA) that is 34 bytes long. The "03" at the beginning indicates a public key, and the "01" indicates sha256. The rest is the hash.
| |
| | |
| == Contact ==
| |
| David Keeler (irc: keeler, email: d[irc name]@mozilla.com)
| |
Please use "Edit with form" above to edit this page.
Status
| DNSSEC-TLS |
| Stage |
Development |
| Status |
In progress |
| Release target |
` |
| Health |
OK |
| Status note |
` |
{{#set:Feature name=DNSSEC-TLS
|Feature stage=Development
|Feature status=In progress
|Feature version=`
|Feature health=OK
|Feature status note=`
}}
Team
| Product manager |
` |
| Directly Responsible Individual |
` |
| Lead engineer |
David Keeler |
| Security lead |
` |
| Privacy lead |
` |
| Localization lead |
` |
| Accessibility lead |
` |
| QA lead |
` |
| UX lead |
` |
| Product marketing lead |
` |
| Operations lead |
` |
| Additional members |
` |
{{#set:Feature product manager=`
|Feature feature manager=`
|Feature lead engineer=David Keeler
|Feature security lead=`
|Feature privacy lead=`
|Feature localization lead=`
|Feature accessibility lead=`
|Feature qa lead=`
|Feature ux lead=`
|Feature product marketing lead=`
|Feature operations lead=`
|Feature additional members=`
}}
Open issues/risks
`
Stage 1: Definition
1. Feature overview
This feature performs domain validation in TLS sessions by using DNSSEC chains.
2. Users & use cases
Server administrators can put key/certificate information in DNS records they control (e.g. TLSA records). This information is verifiable through DNSSEC. The browser can then use this in place of or alongside certificate chain validation.
3. Dependencies
`
4. Requirements
`
Non-goals
`
Stage 2: Design
5. Functional specification
https://wiki.mozilla.org/Security/DNSSEC-TLS-details
6. User experience design
`
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
Tracking bug: 672239
Stage 5: Release
10. Landing criteria
`
{{#set:Feature open issues and risks=`
|Feature overview=This feature performs domain validation in TLS sessions by using DNSSEC chains.
|Feature users and use cases=Server administrators can put key/certificate information in DNS records they control (e.g. TLSA records). This information is verifiable through DNSSEC. The browser can then use this in place of or alongside certificate chain validation.
|Feature dependencies=`
|Feature requirements=`
|Feature non-goals=`
|Feature functional spec=https://wiki.mozilla.org/Security/DNSSEC-TLS-details
|Feature ux design=`
|Feature implementation plan=`
|Feature security review=`
|Feature privacy review=`
|Feature localization review=`
|Feature accessibility review=`
|Feature qa review=`
|Feature operations review=`
|Feature implementation notes=Tracking bug: 672239
|Feature landing criteria=`
}}
Feature details
| Priority |
Unprioritized |
| Rank |
999 |
| Theme / Goal |
Security Leadership |
| Roadmap |
Platform |
| Secondary roadmap |
Security |
| Feature list |
` |
| Project |
` |
| Engineering team |
` |
{{#set:Feature priority=Unprioritized
|Feature rank=999
|Feature theme=Security Leadership
|Feature roadmap=Platform
|Feature secondary roadmap=Security
|Feature list=`
|Feature project=`
|Feature engineering team=`
}}
Team status notes
| |
status |
notes |
| Products |
` |
` |
| Engineering |
` |
` |
| Security |
` |
` |
| Privacy |
` |
` |
| Localization |
` |
` |
| Accessibility |
` |
` |
| Quality assurance |
` |
` |
| User experience |
` |
` |
| Product marketing |
` |
` |
| Operations |
` |
` |
{{#set:Feature products status=`
|Feature products notes=`
|Feature engineering status=`
|Feature engineering notes=`
|Feature security status=`
|Feature security health=`
|Feature security notes=`
|Feature privacy status=`
|Feature privacy notes=`
|Feature localization status=`
|Feature localization notes=`
|Feature accessibility status=`
|Feature accessibility notes=`
|Feature qa status=`
|Feature qa notes=`
|Feature ux status=`
|Feature ux notes=`
|Feature product marketing status=`
|Feature product marketing notes=`
|Feature operations status=`
|Feature operations notes=`
}}