Security/DNSSEC-TLS: Difference between revisions

Latest revision as of 03:07, 7 February 2012

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=` }}

@@ Line 1: / Line 1: @@
-This set of pages documents the TLS domain validation through DNSSEC project.
+{{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
-TLS sessions require a chain of trust to authenticate the server to the client. Currently this is achieved through a series of PKIX certificates that link the server's certificate to a trusted root certificate stored in by the client. Trusted root certificates are issued by Certificate Authorities. Currently, nothing prevents any authority from signing a certificate for any domain name.
+|Feature lead engineer=David Keeler
+}}
-DNSSEC is a method of authenticating DNS records that also uses a chain of trust. In the case of DNSSEC, the trust structure is identical to the DNS hierarchy. For example, only the entity in charge of .com can sign the record that authenticates example.com, and only the (single) entity in charge of the (single) root can sign the record that authenticates .com.
+{{FeaturePageBody
+|Feature overview=This feature performs domain validation in TLS sessions by using DNSSEC chains.
-To validate a DNS record, its RRSIG record and corresponding DNSKEY must be obtained. If the signature checks out (using the key), then the key record must be checked (recursively). This process eventually arrives at a key signing key for a given level in the  DNS hierarchy. To go up the hierarchy, the DS record for the level must be authenticated by a DNSKEY in the next level up. If that succeeds, then the process continues (i.e. the DNSKEY in the next level up must be authenticated, and so forth). Eventually the root of trust is arrived at, whereupon the original DNS record has been validated.
+|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 functional spec=https://wiki.mozilla.org/Security/DNSSEC-TLS-details
-DANE, CAA (Certification Authority Authorization), and 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 specifies 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 implementation notes=Tracking bug: [https://bugzilla.mozilla.org/show_bug.cgi?id=672239 672239]
+}}
-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.
+{{FeatureInfo
+|Feature priority=Unprioritized
-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.
+|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.
-=Goals=
-Goals
-==Primary==
-* asdf
-** asdf
-**# asdf
-==Secondary==
-* foo
-** foo
-*** Note: foo
-=Compatibility=