[keyassure] TLSA record does not mandate the given certificate

Michael Richardson <mcr@sandelman.ca> Mon, 28 March 2011 19:31 UTC

Return-Path: <mcr@sandelman.ca>
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 8938F3A68F2 for <keyassure@core3.amsl.com>; Mon, 28 Mar 2011 12:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.025
X-Spam-Level:
X-Spam-Status: No, score=-1.025 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
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 hsEVRUrkR3RD for <keyassure@core3.amsl.com>; Mon, 28 Mar 2011 12:31:45 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 0BBF33A686E for <keyassure@ietf.org>; Mon, 28 Mar 2011 12:31:44 -0700 (PDT)
Received: from marajade.sandelman.ca (unknown [85.162.122.65]) by relay.sandelman.ca (Postfix) with ESMTPS id 91E1E34074; Mon, 28 Mar 2011 15:33:21 -0400 (EDT)
Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 62E3D98B18; Mon, 28 Mar 2011 21:34:12 +0200 (CEST)
From: Michael Richardson <mcr@sandelman.ca>
To: keyassure@ietf.org
In-Reply-To: <AANLkTikregQCBOovJz4yrcyet+60yT0EMxRkXFw0wqVi@mail.gmail.com>
References: <AANLkTikregQCBOovJz4yrcyet+60yT0EMxRkXFw0wqVi@mail.gmail.com>
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 22)
Date: Mon, 28 Mar 2011 21:34:12 +0200
Message-ID: <4672.1301340852@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Subject: [keyassure] TLSA record does not mandate the given certificate
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 19:31:46 -0000

{I think you should start three threads for your three proposals}

>>>>> "Zack" == Zack Weinberg <zack.weinberg@sv.cmu.edu> writes:
    Zack> The exceptions are: First, it is not clear to me whether the present
    Zack> intent of the spec is that a TLSA record for site S specifying
    Zack> certificate X forbids a compliant client from proceeding with the
    Zack> handshake if it receives certificate Y.  I think the answer to this
    Zack> question must be an unambiguous "yes", and I have made changes
    Zack> to that effect in my edits.  If the answer is meant to be
    Zack> "no", then I will have to raise a formal objection, because
    Zack> that would IMHO mean that 
    Zack> DANE provided no improvements over the status quo.

I can't parse "yes"/"no" in the above sentence.
Do you mean:

  A TLSA record for site S specifying certificate X forbids a compliant
  client from proceeding with the handshake if it receives certificate Y. 

or do you mean to object to this statement?  I think you mean to support
it but I couldn't tell from the overview, and only from the text you supplied.

    Zack> o  The TLSA record has certificate type 1, and it matches the
    Zack> end-entity certificate in the bundle; or

    Zack> o  The TLSA record has certificate type 2, it matches one of the
    Zack> non-end-entity certificates in the bundle, and the end-entity
    Zack> certificate in the bundle has a valid chain to the certificate
    Zack> that matched the TLSA record.

...

    Zack> 3.3. DANE validation

    Zack> The presence in the DNS of a trusted TLSA record is an assertion
    Zack> by the zone administrator that the legitimate server(s) for that
    Zack> host, protocol, and port will use certificate bundles that can be
    Zack> associated with the domain name by that record (as defined in
    Zack> section 3.1), and no others.

    Zack> Therefore, a DANE client in possession of a trusted TLSA record
    Zack> for a server MUST determine whether that TLSA record associates
    Zack> the server's domain name with the certificate bundle it provides
    Zack> in the TLS handshake.  If it does not, a DANE client MUST reject
    Zack> the end-entity certificate and abort the TLS handshake with an
    Zack> "access_denied" error.  This rule applies even if the end-entity
    Zack> certificate would have been trusted in the absence of the TLSA
    Zack> record.

    Zack> Conversely, if the TLSA record _does_ associate the server's
    Zack> certificate bundle with its domain name, a DANE client MUST treat
    Zack> the end-entity certificate as possessing a valid chain to a trust
    Zack> anchor, until the TTL of the TLSA record expires.  In other words,
    Zack> under these circumstances a DANE client MUST NOT reject a server's
    Zack> end-entity certificate solely for lack of a trust anchor.
    Zack> Furthermore, if the TLSA record providing the association has
    Zack> certificate type 1, a DANE client MUST NOT reject an end-entity
    Zack> certificate for violation of the PKIX rules that are relaxed by
    Zack> section 3.4 of this specification.

    Zack> However, if there is any _other_ reason why a server's end-entity
    Zack> certificate would have been rejected in the absence of TLSA
    Zack> information, a DANE client SHOULD still reject that certificate.
    Zack> For instance, if a certificate anywhere in the server's bundle has
    Zack> expired or has been revoked by its issuing CA, a DANE client
    Zack> SHOULD reject the end-entity certificate, even if the TLSA record
    Zack> matches a point in the chain before the invalid certificate.

    Zack> DANE associations provide a trust anchor _only_ for end-entity
    Zack> certificates, even if the TLSA record has certificate type 2.
    Zack> A DANE client MUST NOT allow any non-end-entity certificate in
    Zack> a certificate bundle that is anchored by a DANE association to
    Zack> become trusted for any domain name other than the one in the
    Zack> original association.

    Zack> DANE does not assure any information in a certificate other than
    Zack> the public key and its binding to host, protocol, and port.  Most
    Zack> importantly, DANE does _not_ assure any non-DNS name records.

I like your text.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.