[dane] Repost: "DANE-TA(2) ? Full(0)" certificate chain matching?
Viktor Dukhovni <viktor1dane@dukhovni.org> Wed, 26 March 2014 22:25 UTC
Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2381A03DB for <dane@ietfa.amsl.com>; Wed, 26 Mar 2014 15:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxDka3E-bLPm for <dane@ietfa.amsl.com>; Wed, 26 Mar 2014 15:25:14 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 257F01A0274 for <dane@ietf.org>; Wed, 26 Mar 2014 15:25:13 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DC63D2AAC73; Wed, 26 Mar 2014 22:25:11 +0000 (UTC)
Date: Wed, 26 Mar 2014 22:25:11 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140326222511.GE13649@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/zk4Grky4ivfiVMDa-0Un1bdbuJM
Subject: [dane] Repost: "DANE-TA(2) ? Full(0)" certificate chain matching?
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Mar 2014 22:25:17 -0000
[ Repost, no feedback received. Question summary: * Are clients supposed to check "signed-by" via bare TA keys (2 1 0) that have no matching certificate in the server's chain (say root TA left out of chain per normal PKIX practice)? * Are clients supposed to be able to augment the server chain with any (2 0 0) DANE-TA certificate obtained from DNS, if that certificate is missing from the server's chain? ] I believe we have reached consensus on DANE-EE(3) end-entity X.509 cert verification: - No name checks based on certificate content (TLSA base domain sufficient) - No expiration checks based on certificate content (DNSSEC sufficient) It is time to consider the issues for DANE-TA(2). The first issue is: With records of the form: _25.mx.example.com. TLSA DANE-TA(2) <selector> <some-digest-alg> {blob} where the matching type is really a digest, not Full(0), we've observed that the server operator had better include the matching certificate in his TLS handshake certificate (chain) message, because the verifying client can't match a digest against a certificate it does not have. What do we want to say about: _25.mx.example.com. TLSA DANE-TA(2) SPKI(1) Full(0) {DER-encoded key} In this case the client still typically has no corresponding certificate in hand, and so, if the server does not provide a matching certificate in the TLS handshake, the client cannot "compare" the TLSA record with the server's chain. However, if the server's chain starts with a certificate signed with the trust anchor key in question (obtained from the TLSA record), the client can in principle verify the chain. The Postfix SMTP client in fact does exactly this, uses any "IN TLSA 2 1 0" trust anchor keys to verify "signed-by" even when the server does not present a corresponding TA issuing certificate in his chain. So the question is: - Are clients expected to do this? In other words can servers expect to be able to elide TA certs from their chains when the TA key is in a "2 1 0" TLSA record? - If clients are not expected to do this, there is little point in "IN TLSA 2 1 0", with the key also inside a certificate in the server's chain, it makes a lot more sense to publish "IN TLSA 2 1 X" for some suitable set of digests X. A related question is whether with "DANE-TA(2) Cert(0) Full(0)", there is again a practical need to duplicate the certificate in the server's chain "for matching", or whether this time the server really can avoid duplication, because the client has the cert in hand. Note: The OPS draft discourages "Full(0)" due to potential issues with DNS payload bloat, but these are nevertheless valid, and it would be good to settle on the semantics. -- Viktor.
- [dane] Repost: "DANE-TA(2) ? Full(0)" certificate… Viktor Dukhovni