[keyassure] PROPOSAL: Revision of DANE client requirements
Zack Weinberg <zack.weinberg@sv.cmu.edu> Mon, 28 March 2011 16:45 UTC
Return-Path: <zack.weinberg@gmail.com>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934E23A6842 for <keyassure@core3.amsl.com>; Mon, 28 Mar 2011 09:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZonjedNPsAC for <keyassure@core3.amsl.com>; Mon, 28 Mar 2011 09:45:22 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id EF2253A659C for <keyassure@ietf.org>; Mon, 28 Mar 2011 09:45:21 -0700 (PDT)
Received: by vws12 with SMTP id 12so2846213vws.31 for <keyassure@ietf.org>; Mon, 28 Mar 2011 09:46:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=wjUxgsYqBt0IPfkMIfs9tmUCassioDJC9zRSwkV7V20=; b=NNmUT697g35fugaQ7QsHYvi3hHs8dr8cyVLCdOZeA8rK2MTCIbCyurxOz10PW/8Z57 YLm1+1Tdft3D/mUt8zSCmllPOWyUFSzyK0Qdw1a5u+2qQoq7WGyQOb1Ya3CFVHwZLkBG 1yZFVyKVSQ3x+tzJKXnYyb4CiHVAGp7X7tVWY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=RzGn7PXKILoqHT8e4JrOqZPHKvTfRcpylMz7kHwwunNa89dFiHd/LWAnZ923MfUrxZ tna63WaXMwJx34bk3DfkKwT18NBWPx7w0SlrQvMCd6DD4O1eqDDZ9eY0jwwPGlJPeRaS QR/WXX2xusj47HrBnFAKS38Lk3q0AuGRm0j/8=
MIME-Version: 1.0
Received: by 10.52.18.103 with SMTP id v7mr5952516vdd.64.1301330810283; Mon, 28 Mar 2011 09:46:50 -0700 (PDT)
Sender: zack.weinberg@gmail.com
Received: by 10.52.166.34 with HTTP; Mon, 28 Mar 2011 09:46:50 -0700 (PDT)
Date: Mon, 28 Mar 2011 09:46:50 -0700
X-Google-Sender-Auth: MJ3fvkE7jFdy1zuvqj3XpFQEXQs
Message-ID: <AANLkTikregQCBOovJz4yrcyet+60yT0EMxRkXFw0wqVi@mail.gmail.com>
From: Zack Weinberg <zack.weinberg@sv.cmu.edu>
To: keyassure@ietf.org
Content-Type: text/plain; charset="UTF-8"
Subject: [keyassure] PROPOSAL: Revision of DANE client requirements
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Mar 2011 16:45:23 -0000
I'd like to propose some revisions to the text of DANE. Specifically, I want to make the requirements upon TLS clients that implement the spec clearer, and I also want to consolidate them in one place. The current draft (http://tools.ietf.org/html/draft-ietf-dane-protocol-06) scatters client requirements all around the text, and it is IMO a bit too vague about exactly what *is* a requirement. I want to avoid a situation where not all clients interpret TLSA records the same way, and I also want to avoid a situation where a site administrator might be confused about the effects of adding TLSA records to their zones. With a few exceptions, I believe all my proposed changes are strictly editorial -- that is, I have not removed or added any requirements upon TLS clients, I have just made it clearer what they are. The exceptions are: First, it is not clear to me whether the present intent of the spec is that a TLSA record for site S specifying certificate X forbids a compliant client from proceeding with the handshake if it receives certificate Y. I think the answer to this question must be an unambiguous "yes", and I have made changes to that effect in my edits. If the answer is meant to be "no", then I will have to raise a formal objection, because that would IMHO mean that DANE provided no improvements over the status quo. Second, I have added constraints on client behavior based on DNSSEC status alone. This is arguably out of scope for this standard, but I think the additions are necessary to preserve the security benefits of DANE in the presence of active tampering with the DNS. Third, I have added text about a potential non-security use of TLSA records -- to enable TLS handshake optimizations -- and about user override of TLSA-based rejection of a certificate. These were not addressed in the current draft, but I believe they add value. I am speaking as a security researcher and as a Web browser implementor. I am not speaking on behalf of any other individual or organization; however, I have received positive feedback on earlier drafts of these edits from other browser implementors. Thanks for your attention, zw ---- proposal begins ---- Section 1.2: Delete the sentence "The DNSSEC signature MUST be validated on all responses in order to assure the proof of origin of the data" and the subsequent paragraph break. (An equivalent, but more specific, requirement will reappear in section 3.) Section 1.3: Delete the entire second paragraph. Section 2.2: Replace the paragraph that begins "Both types are structured ..." with this text: Certificates of type 1 and 2 MUST be in PKIX format: that is, they must be structured according to the formatting rules in RFC 5280, and encoded using ASN.1 DER. However, as described in section 3.4, type 1 certificates do not need to adhere to all the semantic rules in RFC 5280. If it is desired to use other certificate formats with this specification in the future, those formats must be assigned their own certificate type numbers, and the definition of "associated" in section 3.1 of this specification must be revised appropriately. Delete the paragraph that begins "Certificate types 1 and 2 explicitly only apply ..." (having been folded into the above). Section 2.3: Delete all text before the beginning of section 2.3.1. (Equivalent but clearer text will reappear in section 3.) Section 2.3.1: Move contents to section 3.4 (marked below). Section 3: Replace entire section with this text: 3. Client application behavior in the presence of TLSA records The primary purpose of TLSA records is security. However, TLSA information might also be useful for protocol optimizations that require advance knowledge of what the server's end-entity certificate should be. Clients that use TLSA information only for such optimizations, and not for security decisions, are exempt from all other requirements in this section. Clients that make security decisions based on TLSA information MUST be, or have access to, security-aware DNS resolvers as defined by RFC 4033. The rest of this section applies only to such clients, which will be referred to as "DANE clients". 3.1. Definitions A certificate received in the TLS handshake is said to _match_ a TLSA record if: o The TLSA record has reference type 0 and the certificate from the handshake is byte-for-byte identical to the certificate for association; or o The TLSA record has some other reference type, and the hash of the certificate from the handshake (using the hash algorithm specified by the reference type) is byte-for-byte identical to the certificate for association. A certificate bundle received in the TLS handshake is said to be _associated_ with a domain name by DANE, if a TLSA record for the host, protocol, and port exists, the end-entity certificate in the bundle contains a name record that matches the host, and: o The TLSA record has certificate type 1, and it matches the end-entity certificate in the bundle; or o The TLSA record has certificate type 2, it matches one of the non-end-entity certificates in the bundle, and the end-entity certificate in the bundle has a valid chain to the certificate that matched the TLSA record. 3.2. DNSSEC validation DANE clients MUST NOT proceed with a connection to a server if the DNSSEC validation status is "bogus" for _any_ DNS records relating to that server. DANE clients MUST ignore TLSA records whose DNSSEC validation status is "insecure" or "indeterminate" (however, such records MAY be used for TLS handshake optimizations as mentioned above). DANE clients MUST also ignore TLSA records whose certificate type or hash type they do not understand. A TLSA record whose DNSSEC status is "secure", and whose certificate and hash types are understood by the client processing it, will henceforth be referred to as a _trusted_ TLSA record. 3.3. DANE validation The presence in the DNS of a trusted TLSA record is an assertion by the zone administrator that the legitimate server(s) for that host, protocol, and port will use certificate bundles that can be associated with the domain name by that record (as defined in section 3.1), and no others. Therefore, a DANE client in possession of a trusted TLSA record for a server MUST determine whether that TLSA record associates the server's domain name with the certificate bundle it provides in the TLS handshake. If it does not, a DANE client MUST reject the end-entity certificate and abort the TLS handshake with an "access_denied" error. This rule applies even if the end-entity certificate would have been trusted in the absence of the TLSA record. Conversely, if the TLSA record _does_ associate the server's certificate bundle with its domain name, a DANE client MUST treat the end-entity certificate as possessing a valid chain to a trust anchor, until the TTL of the TLSA record expires. In other words, under these circumstances a DANE client MUST NOT reject a server's end-entity certificate solely for lack of a trust anchor. Furthermore, if the TLSA record providing the association has certificate type 1, a DANE client MUST NOT reject an end-entity certificate for violation of the PKIX rules that are relaxed by section 3.4 of this specification. However, if there is any _other_ reason why a server's end-entity certificate would have been rejected in the absence of TLSA information, a DANE client SHOULD still reject that certificate. For instance, if a certificate anywhere in the server's bundle has expired or has been revoked by its issuing CA, a DANE client SHOULD reject the end-entity certificate, even if the TLSA record matches a point in the chain before the invalid certificate. DANE associations provide a trust anchor _only_ for end-entity certificates, even if the TLSA record has certificate type 2. A DANE client MUST NOT allow any non-end-entity certificate in a certificate bundle that is anchored by a DANE association to become trusted for any domain name other than the one in the original association. DANE does not assure any information in a certificate other than the public key and its binding to host, protocol, and port. Most importantly, DANE does _not_ assure any non-DNS name records. 3.4. Relaxation of PKIX semantics for self-signed certificates (insert former contents of section 2.3.1 here) 3.5. User override DANE clients SHOULD NOT allow their human users to force the establishment of a connection that has been aborted for any of the reasons listed in sections 3.2 or 3.3. A client that has good reason not to comply with this requirement, such as a forensic tool, SHOULD assume that the other end of a forced connection is actively malicious. Therefore, the client SHOULD take precautions to avoid compromising the local computer or any of the user's data, such as: o Not transmitting "cookies" or any other information that should be confidential to the legitimate server; o Not executing any code (e.g. JavaScript) received over the connection; o Not triggering further network traffic based on the normal semantics of the data received (e.g. images referenced by an HTML page) without explicit user instructions to do so. ---- proposal ends ----
- [keyassure] PROPOSAL: Revision of DANE client req… Zack Weinberg
- [keyassure] TLSA record does not mandate the give… Michael Richardson
- Re: [keyassure] TLSA record does not mandate the … Zack Weinberg
- Re: [keyassure] TLSA record does not mandate the … Jay Daley
- Re: [keyassure] TLSA record does not mandate the … Zack Weinberg
- Re: [keyassure] TLSA record does not mandate the … Jay Daley
- Re: [keyassure] TLSA record does not mandate the … Paul Wouters
- Re: [keyassure] TLSA record does not mandate the … Richard L. Barnes
- Re: [keyassure] PROPOSAL: Revision of DANE client… Paul Wouters
- Re: [keyassure] TLSA record does not mandate the … Zack Weinberg
- Re: [keyassure] PROPOSAL: Revision of DANE client… Zack Weinberg
- Re: [keyassure] TLSA record does not mandate the … Zack Weinberg
- Re: [keyassure] PROPOSAL: Revision of DANE client… Paul Wouters