From viktor1dane@dukhovni.org Fri Mar 1 08:59:02 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A92321F938D for ; Fri, 1 Mar 2013 08:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44mHCfakvJ8U for ; Fri, 1 Mar 2013 08:59:01 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0A921F9387 for ; Fri, 1 Mar 2013 08:59:01 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BEDED2AB6E1; Fri, 1 Mar 2013 16:59:00 +0000 (UTC) Date: Fri, 1 Mar 2013 16:59:00 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130301165900.GB29992@mournblade.imrryr.org> References: <20110323230013.GA16687@np305c2n2.ms.com> <18983715-1690-4916-BBB8-F7EDA8968370@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18983715-1690-4916-BBB8-F7EDA8968370@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 18:03:43 -0000 Having read RFC 6698 multiple times recently, I would like to ask for clarification of the semantics of Certificate usage "3", aka "Domain-issued certificate". https://tools.ietf.org/html/rfc6698#section-2.1.1 Given an explicit binding in the DNS for a specified service end-point to a unique certificate (in full or by subject-publickey-info), it would seem rather unnatural to apply subject name checks to the certificate so bound. The binding in the DNS should ideally obviate any need for similar (potentially conflicting) bindings inside the certificate. In fact when one deploys a cluster of hosts with a shared key-pair that provide the same service (possibly via MX or SRV records), it would be surprising to find that a "TLSA 3 1 1" certificate binding" needs to be updated when a new host is added to the cluster in order to resign the public key with an additional name in the SAN extension, merely to duplicate the DANE binding. Thus my reading of 6698 is that usage 3 (and 1) obviate any requirement for name validation, which should only apply with certificate usage 2 and 0. However, https://tools.ietf.org/html/rfc6698#section-4 in passing and without any normative text mentions the issue of name verification without specifically commenting on any distinction between 0/2 and 1/3. I think follow-on RFCs (dane-srv perhaps) should amend or clarify this text. What is the expected interpretation of 6698 in this respect? Does it support DNS-only bindings to essentially bare public keys encapsulated in minimal X.509 structures? Is it fair to say that certificate usage 3 (and I would posit also 1) is such a binding? This matters because the text in https://tools.ietf.org/html/draft-ietf-dane-srv-02#section-7.3 which is I hear nearing final review at the IETF seems to fly in the face of (what I see as) a reanable interpretation of 6698 and suggests semantics for previously unseen certificate usage values, and in particular unconditional name checks. I should note that in my opinion, as a matter of sound design, name checks for usages "3" and "1" MUST not apply. The reason is that name checks on already "bound" (via DNSSEC + DANE) certificates add nothing to security, since a malicious DNS administrator is free to create whatever certificate contents they see fit (including a suitably matching name), and publish a "TLSA 3 1 1 " for that certificate. Thus checking names for usage "3" (and usage "1") is simply an extra opportunity for the handshake to fail, with no tangile security benefit. So in my view a name check here is an opportunity "to snatch defeat from the jaws of victory". Thanks. -- Viktor. From cloos@jhcloos.com Fri Mar 1 15:29:22 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB96D21F8CB5 for ; Fri, 1 Mar 2013 15:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.017 X-Spam-Level: X-Spam-Status: No, score=-4.017 tagged_above=-999 required=5 tests=[AWL=-1.418, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tq0kEI8LqfkA for ; Fri, 1 Mar 2013 15:29:22 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id DD41121F8CAD for ; Fri, 1 Mar 2013 15:29:21 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id D7B72400FF; Fri, 1 Mar 2013 23:28:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1362180555; bh=FmAYVvwxisZgJ6u0XrJ21F+2aJbYjS8P2eTtH0hAglU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=gU9XGIFFurw1abNs0v7MPNqBvcUcnCFBR38oFXsIeCwYVmXcwvBW06p3BoT4wsSna guvdF/2mNLv6H/Xs9jNJrPhc3+KeOQC0AouriEH+3G1ZBKBK2O1FCc2lRAEW/mBQ+b empFo+5kDmba3u+IWyy36rhtzO/8EyPqvuOF69q4= Received: by carbon.jhcloos.org (Postfix, from userid 500) id CECB16001F; Fri, 1 Mar 2013 23:28:05 +0000 (UTC) From: James Cloos To: In-Reply-To: <20130301165900.GB29992@mournblade.imrryr.org> (Viktor Dukhovni's message of "Fri, 1 Mar 2013 16:59:00 +0000") References: <20110323230013.GA16687@np305c2n2.ms.com> <18983715-1690-4916-BBB8-F7EDA8968370@vpnc.org> <20130301165900.GB29992@mournblade.imrryr.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 01 Mar 2013 18:28:05 -0500 Message-ID: Lines: 26 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130301:dane@ietf.org::OxdHtehRsERd0JTT:0001elG6 X-Hashcash: 1:30:130301:viktor1dane@dukhovni.org::ZdThruXlgvIuRv9i:000000000000000000000000000000000000DCVTN Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 23:29:22 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> Given an explicit binding in the DNS for a specified service end-point VD> to a unique certificate (in full or by subject-publickey-info), it would VD> seem rather unnatural to apply subject name checks to the certificate so VD> bound. The binding in the DNS should ideally obviate any need for similar VD> (potentially conflicting) bindings inside the certificate. Thanks for bringing that up. I seem to have glazed over at that point when I read draft-ietf-dane-srv-*. It is an interesting issue. The target for the SRV/MX TLSAs is for the server to have a single name and a single matching cert; this issue will not occur in that case and I expect that and a desire to minimise code paths are why the draft has that language. But even so, a type 3 shouldn't require any verification beyond checking that the TLSA matches as it specifies. Especially with selector 1. [I had more to write; but have to cut this short and run.... -JimC] -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From viktor1dane@dukhovni.org Fri Mar 1 20:01:24 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8AF21E80F3 for ; Fri, 1 Mar 2013 20:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8x3lU0pJafr for ; Fri, 1 Mar 2013 20:01:24 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 15F1C21E8037 for ; Fri, 1 Mar 2013 20:01:24 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C9DBD2AB727; Sat, 2 Mar 2013 04:01:22 +0000 (UTC) Date: Sat, 2 Mar 2013 04:01:22 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130302040122.GE29992@mournblade.imrryr.org> References: <20110323230013.GA16687@np305c2n2.ms.com> <18983715-1690-4916-BBB8-F7EDA8968370@vpnc.org> <20130301165900.GB29992@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 04:01:24 -0000 On Fri, Mar 01, 2013 at 06:28:05PM -0500, James Cloos wrote: > VD> Given an explicit binding in the DNS for a specified service end-point > VD> to a unique certificate (in full or by subject-publickey-info), it would > VD> seem rather unnatural to apply subject name checks to the certificate so > VD> bound. The binding in the DNS should ideally obviate any need for similar > VD> (potentially conflicting) bindings inside the certificate. > > Thanks for bringing that up. I seem to have glazed over at that point > when I read draft-ietf-dane-srv-*. > > It is an interesting issue. > > The target for the SRV/MX TLSAs is for the server to have a single name > and a single matching cert; this issue will not occur in that case and I > expect that and a desire to minimise code paths are why the draft has > that language. > > But even so, a type 3 shouldn't require any verification beyond checking > that the TLSA matches as it specifies. Especially with selector 1. I don't think that selector "1" vs. "0" ought to substantively influence the semantics of the certificate, even we intuit that the domain owner is fervently trying the world of CAs behind him. However, I do believe that the same (subject name checking) policy should apply for both certificate usage "3" and "1". > [I had more to write; but have to cut this short and run.... -JimC] Looking forward to additional comments. In particular, is 6698 sufficiently clear, and was merely misconstrued by the dane-srv draft? Or does 6698 itself need clarification in section 4 to avoid similar confusion in implementations and future related standards? -- Viktor. From ilari.liusvaara@elisanet.fi Sat Mar 2 00:53:47 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDDC21F90E2 for ; Sat, 2 Mar 2013 00:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=-3.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8d8c7AWSMPUr for ; Sat, 2 Mar 2013 00:53:47 -0800 (PST) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3264F21F90D7 for ; Sat, 2 Mar 2013 00:53:41 -0800 (PST) Received: from saunalahti-vams (vs3-12.mail.saunalahti.fi [62.142.5.96]) by emh01.mail.saunalahti.fi (Postfix) with SMTP id D15A69002E for ; Sat, 2 Mar 2013 10:53:39 +0200 (EET) Received: from emh01.mail.saunalahti.fi ([62.142.5.107]) by vs3-12.mail.saunalahti.fi ([62.142.5.96]) with SMTP (gateway) id A05659B8089; Sat, 02 Mar 2013 10:53:39 +0200 Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id C16F59002E for ; Sat, 2 Mar 2013 10:53:39 +0200 (EET) Date: Sat, 2 Mar 2013 10:53:39 +0200 From: Ilari Liusvaara To: dane@ietf.org Message-ID: <20130302085339.GA22421@LK-Perkele-VII> References: <20110323230013.GA16687@np305c2n2.ms.com> <18983715-1690-4916-BBB8-F7EDA8968370@vpnc.org> <20130301165900.GB29992@mournblade.imrryr.org> <20130302040122.GE29992@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130302040122.GE29992@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara X-Antivirus: VAMS Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 08:53:47 -0000 On Sat, Mar 02, 2013 at 04:01:22AM +0000, Viktor Dukhovni wrote: > On Fri, Mar 01, 2013 at 06:28:05PM -0500, James Cloos wrote: > > However, I do believe that the same (subject name checking) policy > should apply for both certificate usage "3" and "1". I think you are mixing up usages 1 and 2 or something. My reading of RFC 6698: Usage 0: Validate up but excluding RP trust anchor[1]. Usage 1: Validate up but excluding RP trust anchor[1]. Usage 2: Validate up but excluding DANE trust anchor. Usage 3: Validate none.[2] [1] If DANE pinned certificate is below RP trust anchor, DANE checks can't pass (can't happen for usage 1 anyway, since nothing is below EE). [2] This is actually a special case of validate up but excluding DANE trust anchor. -Ilari From viktor1dane@dukhovni.org Sat Mar 2 10:20:42 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E96021F84D5 for ; Sat, 2 Mar 2013 10:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpH6BkAMFAtn for ; Sat, 2 Mar 2013 10:20:41 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 9132321F84D3 for ; Sat, 2 Mar 2013 10:20:41 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EBF002AB6E1; Sat, 2 Mar 2013 18:20:39 +0000 (UTC) Date: Sat, 2 Mar 2013 18:20:39 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130302182039.GF29992@mournblade.imrryr.org> References: <20110323230013.GA16687@np305c2n2.ms.com> <18983715-1690-4916-BBB8-F7EDA8968370@vpnc.org> <20130301165900.GB29992@mournblade.imrryr.org> <20130302040122.GE29992@mournblade.imrryr.org> <20130302085339.GA22421@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130302085339.GA22421@LK-Perkele-VII> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 18:20:42 -0000 On Sat, Mar 02, 2013 at 10:53:39AM +0200, Ilari Liusvaara wrote: > > However, I do believe that the same (subject name checking) policy > > should apply for both certificate usage "3" and "1". > > I think you are mixing up usages 1 and 2 or something. I am quite sure I am not. In both usage 3 and usage 1 the TLSA RR specify the end-entity (leaf) certificate deployed on the server. Once a particular certificate is explicitly bound to the server via a TLSA RR, there is no point in comparing the server name with the content of the certificate, we already have a binding and name checks can only fail with no security gain (snatch defeat from jaws of victory). One simple design rule I try to adhere to is: "don't fail when success is an option". I read the DANE certificate usage numbers as falling into a 2x2 feature matrix: TYPE: TA | EE PKIX:/-----------\ YES | 0 | 1 | -----|-----------| NO | 2 | 3 | -----\-----------/ The TA usages specify a trust anchor while the EE usages specify an end-entity certificate. The PKIX "YES" usages request trust-chain validation to an existing CA root, while the "NO" usages do not. If we encode the certificate usage as a 2-bit number, the least significant bit is the EE bit, and the most significant bit is the "CAs? We don't need no stinkin' CAs!" bit (where by CAs one means the usual panoply of public root CAs found in browser cert bundles, and not privately label trust-anchors is in usage 2). Bottom line, the type of trust path validation is completely irrelevant when deciding whether the client should check the SAN (or fallback CN) name binding of the server certificate, given a DANE binding to an EE certificate, whether we check the trust path or not, we're done with the name binding. Therefore, 1 and 3 should I believe be treated identically with respect to the semantics of the certificate content (as distinct from its trust path). -- Viktor. From ilari.liusvaara@elisanet.fi Sat Mar 2 12:06:01 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890CA21F85A0 for ; Sat, 2 Mar 2013 12:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=-2.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaTOQxSSswpq for ; Sat, 2 Mar 2013 12:06:00 -0800 (PST) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) by ietfa.amsl.com (Postfix) with ESMTP id EB1A221F857E for ; Sat, 2 Mar 2013 12:05:59 -0800 (PST) Received: from saunalahti-vams (vs3-12.mail.saunalahti.fi [62.142.5.96]) by emh02.mail.saunalahti.fi (Postfix) with SMTP id D21158180C for ; Sat, 2 Mar 2013 22:05:57 +0200 (EET) Received: from emh03.mail.saunalahti.fi ([62.142.5.109]) by vs3-12.mail.saunalahti.fi ([62.142.5.96]) with SMTP (gateway) id A0342FBE4B7; Sat, 02 Mar 2013 22:05:57 +0200 Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id BF1E418877A for ; Sat, 2 Mar 2013 22:05:57 +0200 (EET) Date: Sat, 2 Mar 2013 22:05:57 +0200 From: Ilari Liusvaara To: dane@ietf.org Message-ID: <20130302200557.GA20083@LK-Perkele-VII> References: <20110323230013.GA16687@np305c2n2.ms.com> <18983715-1690-4916-BBB8-F7EDA8968370@vpnc.org> <20130301165900.GB29992@mournblade.imrryr.org> <20130302040122.GE29992@mournblade.imrryr.org> <20130302085339.GA22421@LK-Perkele-VII> <20130302182039.GF29992@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130302182039.GF29992@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara X-Antivirus: VAMS Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 20:06:01 -0000 On Sat, Mar 02, 2013 at 06:20:39PM +0000, Viktor Dukhovni wrote: > On Sat, Mar 02, 2013 at 10:53:39AM +0200, Ilari Liusvaara wrote: > > > > However, I do believe that the same (subject name checking) policy > > > should apply for both certificate usage "3" and "1". > > > > I think you are mixing up usages 1 and 2 or something. > > I am quite sure I am not. > > In both usage 3 and usage 1 the TLSA RR specify the end-entity > (leaf) certificate deployed on the server. Once a particular > certificate is explicitly bound to the server via a TLSA RR, there > is no point in comparing the server name with the content of the > certificate, we already have a binding and name checks can only > fail with no security gain (snatch defeat from jaws of victory). > One simple design rule I try to adhere to is: "don't fail when > success is an option". Ah, if one has universal RP trust anchor[1], then the path validation rules simplify to: -Usages 0/2: Validate up to DANE pin / trust anchor. -Usages 1/3: Validate nothing. [1] Eseentially meaning any certificate (or any CA certificate) is treated as trust anchor. -Ilari From viktor1dane@dukhovni.org Sat Mar 2 12:21:31 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DDF21F856F for ; Sat, 2 Mar 2013 12:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VAHnlkPJlsT for ; Sat, 2 Mar 2013 12:21:30 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB2A21F8540 for ; Sat, 2 Mar 2013 12:21:30 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3E08C2AB6E1; Sat, 2 Mar 2013 20:21:26 +0000 (UTC) Date: Sat, 2 Mar 2013 20:21:26 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130302202125.GG29992@mournblade.imrryr.org> References: <20110323230013.GA16687@np305c2n2.ms.com> <18983715-1690-4916-BBB8-F7EDA8968370@vpnc.org> <20130301165900.GB29992@mournblade.imrryr.org> <20130302040122.GE29992@mournblade.imrryr.org> <20130302085339.GA22421@LK-Perkele-VII> <20130302182039.GF29992@mournblade.imrryr.org> <20130302200557.GA20083@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130302200557.GA20083@LK-Perkele-VII> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 20:21:31 -0000 On Sat, Mar 02, 2013 at 10:05:57PM +0200, Ilari Liusvaara wrote: > On Sat, Mar 02, 2013 at 06:20:39PM +0000, Viktor Dukhovni wrote: > > > On Sat, Mar 02, 2013 at 10:53:39AM +0200, Ilari Liusvaara wrote: > > > > > I think you are mixing up usages 1 and 2 or something. > > > > I am quite sure I am not. > > > > In both usage 3 and usage 1 the TLSA RR specify the end-entity > > (leaf) certificate deployed on the server. Once a particular > > certificate is explicitly bound to the server via a TLSA RR, there > > is no point in comparing the server name with the content of the > > certificate, we already have a binding and name checks can only > > fail with no security gain (snatch defeat from jaws of victory). > > One simple design rule I try to adhere to is: "don't fail when > > success is an option". > > Ah, if one has universal RP trust anchor[1], then the path validation > rules simplify to: > > -Usages 0/2: Validate up to DANE pin / trust anchor. > -Usages 1/3: Validate nothing. I honestly have no idea what you mean, but it sure seems that you are talking about trust chain validation, where-as the question in this thread is about the necessity (or lack there-of) of checking the certificate name (subjectAltName or CN). The certificate is in this context already presumed trusted by some means (whether DANE EE or TA, trust assertion or constraint), the question that remains to be settled is whether the server certificate is the *right* certificate or an unrelated trusted certificate. I posit that with certificate usage 1/3 this question is moot, the DANE EE data is sufficient to bind the certificate to the service, and no name checks should be required. The text in 6698 is perhaps ambiguous on this point, and the text in draft-srv seems to suggest a contrary interpretation that I believe needs to be corrected. -- Viktor. From christian.becker@tu-harburg.de Sun Mar 3 02:19:01 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F059D21F8652 for ; Sun, 3 Mar 2013 02:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JU59LhLze8AQ for ; Sun, 3 Mar 2013 02:18:57 -0800 (PST) Received: from smtp3.rz.tu-harburg.de (smtp3.rz.tu-harburg.de [134.28.202.138]) by ietfa.amsl.com (Postfix) with ESMTP id D0DA221F8650 for ; Sun, 3 Mar 2013 02:18:55 -0800 (PST) Received: from mail.tu-harburg.de (mail.tu-harburg.de [134.28.202.179]) by smtp3.rz.tu-harburg.de (8.13.8/8.13.8) with ESMTP id r23AIrPr019868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 3 Mar 2013 11:18:54 +0100 Received: from [0.0.0.0] (torua.la.net.ua [77.87.36.179]) (user=secb0840 mech=PLAIN bits=0) by mail.tu-harburg.de (8.13.8/8.13.8) with ESMTP id r23AIaf6024040 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 3 Mar 2013 11:18:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tu-harburg.de; s=x2013-09; t=1362305933; bh=XelpV/wDa24y9cfKCf2B+oe8RIkRT6y2G9o+ZEUBbqs=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=LfLfd+cMpSqU5wtsfbKxyvRGBXWbpS4Zm30X51mXMl8VjWjo59eK6cGoZwzZUZdqo 44LiSnE12fjw1P6fBySx+KxW3RbXBYIGc5drIXkI6PpoyR5XTqBTiIEIkp7pwN6x8v YdWFgJnn6zdnQG3DRWPB55Ag7tTVjvhmyyW4djDo= Message-ID: <513322EC.6040803@tu-harburg.de> Date: Sun, 03 Mar 2013 11:16:12 +0100 From: Christian Becker User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121215 Icedove/3.0.11 MIME-Version: 1.0 To: dane@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.138 X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.179 Subject: [dane] revocation of keys or certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 10:19:01 -0000 Comparing PKIX and DANE I regularly get asked about the certificate revocation in DANE. To me revocation is straight forward: you change keys in the TLSA record. BUT what if the key was propagated with a large TTL to the caches of the worlds DNS servers. In that case the revocation process can only be considered done when the TTL has elapsed. Is that the right perception and are there any solution for that, except of a recommendation to keep the TTL small? Thanks, Christian From ynir@checkpoint.com Sun Mar 3 03:33:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF7821F869F for ; Sun, 3 Mar 2013 03:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiC7UYSqTWwV for ; Sun, 3 Mar 2013 03:33:15 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4403521F8698 for ; Sun, 3 Mar 2013 03:33:14 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r23BX3mM020454; Sun, 3 Mar 2013 13:33:04 +0200 X-CheckPoint: {513334B6-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.95]) with mapi id 14.02.0342.003; Sun, 3 Mar 2013 13:33:03 +0200 From: Yoav Nir To: Christian Becker , "dane@ietf.org" Thread-Topic: [dane] revocation of keys or certificates Thread-Index: AQHOF/iPCJXDfflFfkaUcsOpfsUujZiT1G+A Date: Sun, 3 Mar 2013 11:33:02 +0000 Message-ID: <4613980CFC78314ABFD7F85CC3027721119DA3E5@IL-EX10.ad.checkpoint.com> References: <513322EC.6040803@tu-harburg.de> In-Reply-To: <513322EC.6040803@tu-harburg.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.81] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dane] revocation of keys or certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 11:33:16 -0000 Hi Christian There may be ways in some environments to push updates, but it's neither un= iversal nor reliable. So the perception is correct. It's not much different= from waiting for the NextUpdate time of the CRL. And the solution is also the same: short TTLs, frequent CRL updates, short = response validity interval. With either technology it's a trade-off betwee= n timely revocation and load on the issuer. Yoav -----Original Message----- From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of Chr= istian Becker Sent: Sunday, March 03, 2013 12:16 PM To: dane@ietf.org Subject: [dane] revocation of keys or certificates Comparing PKIX and DANE I regularly get asked about the certificate revocat= ion in DANE. To me revocation is straight forward: you change keys in the T= LSA record. BUT what if the key was propagated with a large TTL to the cach= es of the worlds DNS servers. In that case the revocation process can only = be considered done when the TTL has elapsed. Is that the right perception and are there any solution for that, except of= a recommendation to keep the TTL small? Thanks, Christian From rlb@ipv.sx Sun Mar 3 07:46:27 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5244A21F86D6 for ; Sun, 3 Mar 2013 07:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR0xF22VaYPm for ; Sun, 3 Mar 2013 07:46:14 -0800 (PST) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 55E3221F86CE for ; Sun, 3 Mar 2013 07:44:48 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id k14so7829996oag.25 for ; Sun, 03 Mar 2013 07:44:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=fGSfP7zblcUEKgfhBs6Tse88L02eqrxqs5mifcfgtw0=; b=PC890FxTfvHhDf9NZsltCYhhQAcVpLneYU5Jh1vE88GRfu1RD+C+u7GJZcIErCWUcw UB5ILFxYAy7Voh/zVnAjt7jjOv5qiyoyH368YJ/dMnIe5fW71hzHv47LM1Xv+Y3fehnW mLiZug3/g7wobxnvGHRUsbIEqg1Kl9juuHCrw+ZOO8ltx6udrY9YsE+MoFWzMfXYWiIq xTX3iMbQwPWOjuTD0GIgt8MNSee8VgIuKOy7F7qBoiFnrg0aym16VPXFEFIagS82VJ4O /Pqvcwc96mxVjMlOY2GiE/IM33gA8eFt6oTWtavs8GoDNB8qVqI3+6SMuyrdF0lC76Ar 9C/g== MIME-Version: 1.0 X-Received: by 10.182.157.104 with SMTP id wl8mr13683527obb.79.1362325467961; Sun, 03 Mar 2013 07:44:27 -0800 (PST) Received: by 10.60.10.101 with HTTP; Sun, 3 Mar 2013 07:44:27 -0800 (PST) X-Originating-IP: [108.18.40.68] In-Reply-To: <4613980CFC78314ABFD7F85CC3027721119DA3E5@IL-EX10.ad.checkpoint.com> References: <513322EC.6040803@tu-harburg.de> <4613980CFC78314ABFD7F85CC3027721119DA3E5@IL-EX10.ad.checkpoint.com> Date: Sun, 3 Mar 2013 10:44:27 -0500 Message-ID: From: Richard Barnes To: Yoav Nir Content-Type: multipart/alternative; boundary=f46d044281a096430704d7071d84 X-Gm-Message-State: ALoCoQngDdTeTc/hdlt4kPoFa3x0uafp5RAsMJp0FZChixS4jY9JvjwgvUe87TZLOhFpWXvLepj7 Cc: "dane@ietf.org" Subject: Re: [dane] revocation of keys or certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 15:46:27 -0000 --f46d044281a096430704d7071d84 Content-Type: text/plain; charset=ISO-8859-1 Just to be clear, CRLs only help here as an analogy. As I read the DANE specs, a relying party would not be required to do CRL checking on a cert with a Type 3 TLSA assertion, because that assertion says that the public key in the cert is to be used as a trust anchor. (And TAs are by definition exempt from further validation. Your initial instinct was right. TLSA associations are secured with DNSSEC, so the follow the same models for revocation, rollover, etc. So short TTLs are the only tool you have. --Richard On Sunday, March 3, 2013, Yoav Nir wrote: > Hi Christian > > There may be ways in some environments to push updates, but it's neither > universal nor reliable. So the perception is correct. It's not much > different from waiting for the NextUpdate time of the CRL. > > And the solution is also the same: short TTLs, frequent CRL updates, short > response validity interval. With either technology it's a trade-off > between timely revocation and load on the issuer. > > Yoav > > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] > On Behalf Of Christian Becker > Sent: Sunday, March 03, 2013 12:16 PM > To: dane@ietf.org > Subject: [dane] revocation of keys or certificates > > Comparing PKIX and DANE I regularly get asked about the certificate > revocation in DANE. To me revocation is straight forward: you change keys > in the TLSA record. BUT what if the key was propagated with a large TTL to > the caches of the worlds DNS servers. In that case the revocation process > can only be considered done when the TTL has elapsed. > > Is that the right perception and are there any solution for that, except > of a recommendation to keep the TTL small? > > Thanks, > Christian > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --f46d044281a096430704d7071d84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just to be clear, CRLs only help here as an analogy. =A0As I read the DANE = specs, a relying party would not be required to do CRL checking on a cert w= ith a Type 3 TLSA assertion, because that assertion says that the public ke= y in the cert is to be used as a trust anchor. =A0(And TAs are by definitio= n exempt from further validation. =A0

Your initial instinct was right. =A0TLSA associations are se= cured with DNSSEC, so the follow the same models for revocation, rollover, = etc. =A0So short TTLs are the only tool you have.=A0

--Richard=A0

On Sunday, March 3, 2013, Yoav Nir wrote:=
Hi Christian

There may be ways in some environments to push updates, but it's neithe= r universal nor reliable. So the perception is correct. It's not much d= ifferent from waiting for the NextUpdate time of the CRL.

And the solution is also the same: short TTLs, frequent CRL updates, short = response validity interval. =A0With either technology it's a trade-off = between timely revocation and load on the issuer.

Yoav

-----Original Message-----
From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of Christian Becker
Sent: Sunday, March 03, 2013 12:16 PM
To: dane@ietf.org
Subject: [dane] revocation of keys or certificates

Comparing PKIX and DANE I regularly get asked about the certificate revocat= ion in DANE. To me revocation is straight forward: you change keys in the T= LSA record. BUT what if the key was propagated with a large TTL to the cach= es of the worlds DNS servers. In that case the revocation process can only = be considered done when the TTL has elapsed.

Is that the right perception and are there any solution for that, except of= a recommendation to keep the TTL small?

Thanks,
Christian

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane
--f46d044281a096430704d7071d84-- From cloos@jhcloos.com Sun Mar 3 14:26:25 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E75721F887D for ; Sun, 3 Mar 2013 14:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.163 X-Spam-Level: X-Spam-Status: No, score=-4.163 tagged_above=-999 required=5 tests=[AWL=-1.564, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlFJDzGPtaVM for ; Sun, 3 Mar 2013 14:26:20 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id D6E9521F886E for ; Sun, 3 Mar 2013 14:26:17 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id A135840273; Sun, 3 Mar 2013 22:25:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1362349574; bh=F8lEa0WkJgXayttx7a+1PlcEmhnhZ5eEldfyR+esDDA=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=dMCHqGJjYiPeXImdEMWCY+nPb8lT9EgBINBB6C7Td+/Fs2M/xTrMLwttTmm/8GvAx UqIQd80+e8UulidKW7UWeWfOwfZ/ZCfGaiEkxHIN94XlXg51eq85wI+EwNYZI/+oKj tAQslxzBY8p9OVL/KfMqexC3Aex8TC6+3qa4YtCA= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 6E68A6001F; Sun, 3 Mar 2013 22:20:49 +0000 (UTC) From: James Cloos To: In-Reply-To: (Richard Barnes's message of "Sun, 3 Mar 2013 10:44:27 -0500") References: <513322EC.6040803@tu-harburg.de> <4613980CFC78314ABFD7F85CC3027721119DA3E5@IL-EX10.ad.checkpoint.com> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sun, 03 Mar 2013 17:20:49 -0500 Message-ID: Lines: 22 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130303:dane@ietf.org::bPosFuy2yf4AEVYu:000uQtTt Subject: Re: [dane] revocation of keys or certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 22:26:25 -0000 >>>>> "RB" == Richard Barnes writes: RB> So short TTLs are the only tool you have. And that really ought to be sufficient. It is not at all uncommon to have TTLs as low as an hour or even a minute for some RRs without any significant impact on the dns servers. And even if it is for a TLS server which gets so much traffic that a short DNS TTL would have a noticeable impact on the hardware or net pipes, that still will be *dwarfed* by the TLS load and traffic. Some sites, typically those with very small or expensive pipes, may (try to) force their caching resolvers to recheck less often than the TTLs. But even they tend to cache for no more than a day or two. And there is the option to use a type 2 with one's own CA, CRL, ocsp et al if that is more comfortable. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From huitema@huitema.net Sun Mar 3 18:13:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9949A21F8788 for ; Sun, 3 Mar 2013 18:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEcuzg12Plvc for ; Sun, 3 Mar 2013 18:13:16 -0800 (PST) Received: from xsmtp11.mail2web.com (xsmtp31.mail2web.com [168.144.250.234]) by ietfa.amsl.com (Postfix) with ESMTP id 07E4D21F877A for ; Sun, 3 Mar 2013 18:13:16 -0800 (PST) Received: from [10.5.2.11] (helo=xmail01.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1UCKtt-0004qG-FS for dane@ietf.org; Sun, 03 Mar 2013 21:13:15 -0500 Received: (qmail 15662 invoked from network); 4 Mar 2013 02:13:08 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[24.18.205.153]) (envelope-sender ) by xmail01.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 4 Mar 2013 02:13:07 -0000 From: "Christian Huitema" To: "'James Cloos'" , References: <513322EC.6040803@tu-harburg.de> <4613980CFC78314ABFD7F85CC3027721119DA3E5@IL-EX10.ad.checkpoint.com> In-Reply-To: Date: Sun, 3 Mar 2013 18:13:06 -0800 Message-ID: <001201ce187d$d0290190$707b04b0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQI6IA7scFQ3CeYTpXvyUjQz3p4b8QNFfgWKAisaDs0CXeyJ85d+RXbw Content-Language: en-us Subject: Re: [dane] revocation of keys or certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 02:13:16 -0000 >>>>>> "RB" == Richard Barnes writes: > > RB> So short TTLs are the only tool you have. > > And that really ought to be sufficient. It is not at all uncommon to have TTLs as low as an hour or even a minute for some RRs without any significant impact on the dns servers. It also has the advantage of being really simple, and thus less easy to fall prey to some weird bug. If the TTL expires often, then the management procedures are there to republish it often. If a certificate has a very long life time, then renewals happen rarely, the procedures are not well tested, and we do see silly mistakes happen. > And even if it is for a TLS server which gets so much traffic that a short DNS TTL would have a noticeable impact on the hardware or net pipes, that still will be *dwarfed* by the TLS load and traffic. The name server records are still cached, which cuts most of the impact on the DNS infrastructure. -- Christian Huitema From paul@cypherpunks.ca Sun Mar 3 22:37:38 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E72E21F85D6 for ; Sun, 3 Mar 2013 22:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.551 X-Spam-Level: * X-Spam-Status: No, score=1.551 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CASVWYKits8 for ; Sun, 3 Mar 2013 22:37:37 -0800 (PST) Received: from mx.nohats.ca (unknown [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id DE8B721F85CB for ; Sun, 3 Mar 2013 22:37:35 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZKBP63HrTz76W; Mon, 4 Mar 2013 01:37:30 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id vr02tBI0nqjJ; Mon, 4 Mar 2013 01:37:25 -0500 (EST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 4 Mar 2013 01:37:24 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id E7801805BB; Mon, 4 Mar 2013 01:37:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D3E14805AD; Mon, 4 Mar 2013 01:37:24 -0500 (EST) Date: Mon, 4 Mar 2013 01:37:24 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: James Cloos In-Reply-To: Message-ID: References: <513322EC.6040803@tu-harburg.de> <4613980CFC78314ABFD7F85CC3027721119DA3E5@IL-EX10.ad.checkpoint.com> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane WG list Subject: Re: [dane] revocation of keys or certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 06:37:38 -0000 On Sun, 3 Mar 2013, James Cloos wrote: >>>>>> "RB" == Richard Barnes writes: > > RB> So short TTLs are the only tool you have. > > And that really ought to be sufficient. Just to clarify, it is the short RRSIGs that give you the "revocation" of removing the record from the zone, not the short TTL. If your RRSIG is set for 60 days, a short TTL does not prevent anyone from spoofing your old key. Paul From christian.becker@tu-harburg.de Mon Mar 4 03:33:34 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262A421F8AA8 for ; Mon, 4 Mar 2013 03:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5L7MANZxec5y for ; Mon, 4 Mar 2013 03:33:33 -0800 (PST) Received: from smtp3.rz.tu-harburg.de (smtp3.rz.tu-harburg.de [134.28.202.138]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3E421F8A93 for ; Mon, 4 Mar 2013 03:33:32 -0800 (PST) Received: from mail.tu-harburg.de (mail.tu-harburg.de [134.28.202.179]) by smtp3.rz.tu-harburg.de (8.13.8/8.13.8) with ESMTP id r24BXRgF003671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Mar 2013 12:33:27 +0100 Received: from [0.0.0.0] (exit2.ipredator.se [93.182.129.84] (may be forged)) (user=secb0840 mech=PLAIN bits=0) by mail.tu-harburg.de (8.13.8/8.13.8) with ESMTP id r24BXISA024669 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 4 Mar 2013 12:33:25 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tu-harburg.de; s=x2013-10; t=1362396807; bh=8YYEsD1PJ4TLI1ZpmzG28Q0/KuYvBTXvdecLCNSpNis=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=V4sZm0Atbdy2su7P5Yyt10c+C+kyDK+nbmmy1+sziKkG3gbGOwk0EdQwkt5cxDX4O ztHehTPHkDyBijyRo+jtDc7dxAbgkh33GNfyNqDAGRXxov5QtM1xzOqBlVuZ4UagPV LQPUAjQ5mEJ9Wt6DeG5dVgolPhkhw1a40fXpp7Cc= Message-ID: <513485EC.5090309@tu-harburg.de> Date: Mon, 04 Mar 2013 12:30:52 +0100 From: Christian Becker User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121215 Icedove/3.0.11 MIME-Version: 1.0 To: Paul Wouters , dane@ietf.org References: <513322EC.6040803@tu-harburg.de> <4613980CFC78314ABFD7F85CC3027721119DA3E5@IL-EX10.ad.checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.138 X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.179 Subject: Re: [dane] revocation of keys or certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 11:33:34 -0000 Am 04.03.2013 07:37, schrieb Paul Wouters: > On Sun, 3 Mar 2013, James Cloos wrote: > >>>>>>> "RB" == Richard Barnes writes: >> >> RB> So short TTLs are the only tool you have. >> >> And that really ought to be sufficient. > > Just to clarify, it is the short RRSIGs that give you the "revocation" > of removing the record from the zone, not the short TTL. If your RRSIG > is set for 60 days, a short TTL does not prevent anyone from spoofing > your old key. Wouldn't an elapsed TTL of RRSIG as well as an elapsed TTL of TLSA trigger a question to the authoritative NS? And aren't both versions prone to replay attacks, because there is no absolute time involved? I could just record the TLSA and RRSIG records and replay them after the key is "revoked" until the signature in RRSIG is expired or the ZSK has changed. Thanks again. Christian From mrex@sap.com Mon Mar 4 16:05:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0912921F8650 for ; Mon, 4 Mar 2013 16:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUEc1MU3CtMX for ; Mon, 4 Mar 2013 16:05:15 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4255121F8630 for ; Mon, 4 Mar 2013 16:05:15 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r2505Enj014764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Mar 2013 01:05:14 +0100 (MET) In-Reply-To: <513322EC.6040803@tu-harburg.de> To: Christian Becker Date: Tue, 5 Mar 2013 01:05:14 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130305000514.19DC81A5F4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] revocation of keys or certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 00:05:16 -0000 Christian Becker wrote: > Comparing PKIX and DANE I regularly get asked about the certificate > revocation in DANE. There is no revocation in DANE. There is only expiration through RRSIG Signature Expiriation and invalidation through zone key roll-over. > > In that case the revocation process can only be considered > done when the TTL has elapsed. TTL is meaningless here. TTL's purpose is a mere guidance for caching, TTL does not provide any security. It is an unsigned(!!) DNS record attribute that an intermediary can make up at will. -Martin From mrex@sap.com Mon Mar 4 16:20:15 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA32821F8757 for ; Mon, 4 Mar 2013 16:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoGzRXSUWjDp for ; Mon, 4 Mar 2013 16:20:15 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id DE87D21F8706 for ; Mon, 4 Mar 2013 16:20:14 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r250KAPU026600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Mar 2013 01:20:10 +0100 (MET) In-Reply-To: <20130301165900.GB29992@mournblade.imrryr.org> To: Viktor Dukhovni Date: Tue, 5 Mar 2013 01:20:10 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 00:20:15 -0000 Viktor Dukhovni wrote: > > Having read RFC 6698 multiple times recently, I would like to ask > for clarification of the semantics of Certificate usage "3", aka > "Domain-issued certificate". > > https://tools.ietf.org/html/rfc6698#section-2.1.1 > > Given an explicit binding in the DNS for a specified service end-point > to a unique certificate (in full or by subject-publickey-info), it would > seem rather unnatural to apply subject name checks to the certificate so > bound. The binding in the DNS should ideally obviate any need for similar > (potentially conflicting) bindings inside the certificate. > > Thus my reading of 6698 is that usage 3 (and 1) obviate any > requirement for name validation, which should only apply with > certificate usage 2 and 0. I would actually very dislike such an interpretation, and require the name validation for *ALL* variants of X.509 certificates. For usage DNS usage (1) it would actively subvert the name binding that the public CA (from the Web Browser X.509 PKI) placed into the certificate. What about other cert attributes in DANE usage (1) (such as BasicConstraints, KeyUsage, ExtendedKeyUsage, NameConstraints, Certificate Policies, PolicyConstraints and Validity)? The end users, some of which sometimes actually look at the attributes of X.509 certs, would get totally confused by such weird rules. For Usage (3) it should be trivial for the server admin to provide a correct server cert where the name matching succeeds, without confusing any users that may occasionally look at the server cert. -Martin From ietf@augustcellars.com Mon Mar 4 17:25:33 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6B021F87AF for ; Mon, 4 Mar 2013 17:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSq2EiDjFj7L for ; Mon, 4 Mar 2013 17:25:33 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5799921F87FF for ; Mon, 4 Mar 2013 17:25:33 -0800 (PST) Received: from Philemon (dhcp63-140-207-211.hil-tpanohx.orl.wayport.net [63.140.207.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id E16F72CA29 for ; Mon, 4 Mar 2013 17:25:32 -0800 (PST) From: "Jim Schaad" To: References: <20110323230013.GA16687@np305c2n2.ms.com> <18983715-1690-4916-BBB8-F7EDA8968370@vpnc.org> <20130301165900.GB29992@mournblade.imrryr.org> <20130302040122.GE29992@mournblade.imrryr.org> <20130302085339.GA22421@LK-Perkele-VII> <20130302182039.GF29992@mournblade.imrryr.org> In-Reply-To: <20130302182039.GF29992@mournblade.imrryr.org> Date: Mon, 4 Mar 2013 20:25:00 -0500 Message-ID: <008e01ce1940$42030aa0$c6091fe0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEpkg2iHviydEu22dUualAiSqVzDgIsgmgmAat01akBmEeTXAHExUF5AyP8siUA8Q7O05mFC4Uw Content-Language: en-us Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 01:25:33 -0000 That is completely antithetical to my understanding. For types 0, 1 and 2 - the DANE check is in addition to ALL existing PKI checks. For type 3 - I would agree that no PKI checks are to be done. That would include the name matching check. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Viktor Dukhovni > Sent: Saturday, March 02, 2013 1:21 PM > To: dane@ietf.org > Subject: Re: [dane] Certificate usages 1/3 and subject name checks > > On Sat, Mar 02, 2013 at 10:53:39AM +0200, Ilari Liusvaara wrote: > > > > However, I do believe that the same (subject name checking) policy > > > should apply for both certificate usage "3" and "1". > > > > I think you are mixing up usages 1 and 2 or something. > > I am quite sure I am not. > > In both usage 3 and usage 1 the TLSA RR specify the end-entity > (leaf) certificate deployed on the server. Once a particular certificate is > explicitly bound to the server via a TLSA RR, there is no point in comparing > the server name with the content of the certificate, we already have a > binding and name checks can only fail with no security gain (snatch defeat > from jaws of victory). > One simple design rule I try to adhere to is: "don't fail when success is an > option". > > I read the DANE certificate usage numbers as falling into a 2x2 feature matrix: > > TYPE: TA | EE > PKIX:/-----------\ > YES | 0 | 1 | > -----|-----------| > NO | 2 | 3 | > -----\-----------/ > > The TA usages specify a trust anchor while the EE usages specify an end- > entity certificate. The PKIX "YES" usages request trust-chain validation to an > existing CA root, while the "NO" usages do not. > > If we encode the certificate usage as a 2-bit number, the least significant bit > is the EE bit, and the most significant bit is the "CAs? We don't need no > stinkin' CAs!" bit (where by CAs one means the usual panoply of public root > CAs found in browser cert bundles, and not privately label trust-anchors is in > usage 2). > > Bottom line, the type of trust path validation is completely irrelevant when > deciding whether the client should check the SAN (or fallback CN) name > binding of the server certificate, given a DANE binding to an EE certificate, > whether we check the trust path or not, we're done with the name binding. > > Therefore, 1 and 3 should I believe be treated identically with respect to the > semantics of the certificate content (as distinct from its trust path). > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From viktor1dane@dukhovni.org Mon Mar 4 18:00:20 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DD321F85F3 for ; Mon, 4 Mar 2013 18:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKTi62uaGNrP for ; Mon, 4 Mar 2013 18:00:18 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id AE72F21F8628 for ; Mon, 4 Mar 2013 18:00:18 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B17A02AB646; Tue, 5 Mar 2013 02:00:17 +0000 (UTC) Date: Tue, 5 Mar 2013 02:00:17 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130305020017.GM29992@mournblade.imrryr.org> References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 02:00:20 -0000 On Tue, Mar 05, 2013 at 01:20:10AM +0100, Martin Rex wrote: > > Thus my reading of 6698 is that usage 3 (and 1) obviate any > > requirement for name validation, which should only apply with > > certificate usage 2 and 0. > > I would actually very dislike such an interpretation, and require the > name validation for *ALL* variants of X.509 certificates. This dislike translates into an important lost feature, no support for direct binding of a service end-point to a public-key sans all the baggage of the legacy public CA PKI. The additional name check is, as I pointed out upthread, simply an opportunity to fail with no security gain. Why should we force the client to fail when it has all the information required to succeed? This, I think, makes little sense. Yes, we can suggest to server operators that their certs SHOULD carry a name that may be acceptable to legacy public CA PKI clients, (if they are indeed signed by such legacy public CAs, for example, today most SMTP certs are self-signed and one only gets protection from passive eavesdroppers). Telling clients that they MUST reject certs that don't have a corresponding CA-blessed name, even though they have an authoritative DANE binding to the EE cert would be a real shame. My (not outlandish) view is that the legacy public CA X.509 PKI is a sinking ship. There is little reason to entrench its semantics into new protocols except as an optional transition aid. > For usage DNS usage (1) it would actively subvert the name binding > that the public CA (from the Web Browser X.509 PKI) placed into the > certificate. Hallelujah! I thought that the whole point of DANE was to actively subvert the public CA model (be it over time). I place as little faith as possible in the name bindings provided by public CAs and hope to some day be entirely unencumbered by such faith. When the service operator publishes a DNSSEC public key binding (binds the service end-point to an EE certificate), that binding should suffice. > What about other cert attributes in DANE usage (1) > (such as BasicConstraints, KeyUsage, ExtendedKeyUsage, NameConstraints, > Certificate Policies, PolicyConstraints and Validity)? If a client application performs PKIX trust path validation for certificate usage 1, it will check everything relevant for that. > The end users, some of which sometimes actually look at the attributes > of X.509 certs, would get totally confused by such weird rules. With DANE, and EE certificate bindings any UI should simply indicate that the certificate is bound to the end-entity (service host/port) via secure DNS. The content of the certificate is irrelevant it is just an ephemeral public key that could be rotated daily! Smaller certificates use less bandwidth. This is the sort of lean and mean certificate (303 bytes of DER) I plan to deploy on MX host MTAs (bare minimum extensions to support TLS key usage). $ openssl x509 -in cert.pem -text Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: ecdsa-with-SHA256 Issuer: Validity Not Before: Mar 5 01:33:43 2013 GMT Not After : Mar 5 01:33:43 2014 GMT Subject: Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: ... ASN1 OID: prime256v1 X509v3 extensions: X509v3 Basic Constraints: CA:TRUE X509v3 Key Usage: Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication Signature Algorithm: ecdsa-with-SHA256 ... -----BEGIN CERTIFICATE----- MIIBKzCB0aADAgECAgEBMAoGCCqGSM49BAMCMAAwHhcNMTMwMzA1MDEzMzQzWhcN MTQwMzA1MDEzMzQzWjAAMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE7a1YF62n 6XjcPzMGZGjsxSzlJPyq7B5J/q8FNdkS3LG2RrjmlxgjnzIkuzOCHP2AK8z2sKkF 36XRiiVI8X+NeaM8MDowDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAoGCCqGSM49BAMCA0kAMEYCIQDRTRJU qwUrkoju65eONV2WcijOh5vxFX6K0AA2cy0oOQIhAK7bv88ee71coa9chdB/YIOD +9FvyHx3wLebt4clSEzr -----END CERTIFICATE----- > For Usage (3) it should be trivial for the server admin to provide > a correct server cert where the name matching succeeds, without confusing > any users that may occasionally look at the server cert. Not when the same key-pair is fielded on a cluster of hosts, and one wants to avoid minting new certs each time a host joins or leaves the cluster. Administration is much simpler when all one needs to do is point another CNAME to the same TLSA record: $ dig +noall +ans -t tlsa _25._tcp.open.nlnetlabs.nl _25._tcp.open.nlnetlabs.nl. 10190 IN CNAME 3.1.1._dane.nlnetlabs.nl. 3.1.1._dane.nlnetlabs.nl. 10190 IN TLSA 3 1 1 0D1FCBD71686199607A... $ dig +noall +ans -t tlsa _587._tcp.open.nlnetlabs.nl _587._tcp.open.nlnetlabs.nl. 10200 IN CNAME 3.1.1._dane.nlnetlabs.nl. 3.1.1._dane.nlnetlabs.nl. 10182 IN TLSA 3 1 1 0D1FCBD71686199607A... I have started the implementation of DANE TLSA support for Postfix 2.11, the plan is to map 1/3 to the "fingerprint" security level (trust a specified EE cert) and 0/2 to the "verify" security level (trust a specified set of CAs). With 0/2, naturally the certificate peer name binding asserted by the CA will be checked against the DNSSEC validated MX hostname. With 1/3 it will not, there is no reason to fail when success is an option. -- Viktor. From viktor1dane@dukhovni.org Mon Mar 4 18:25:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7C021F8600 for ; Mon, 4 Mar 2013 18:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78UeTuFsSm0I for ; Mon, 4 Mar 2013 18:25:15 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id D2F5621F85E0 for ; Mon, 4 Mar 2013 18:25:15 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 838CB2AB646; Tue, 5 Mar 2013 02:25:15 +0000 (UTC) Date: Tue, 5 Mar 2013 02:25:15 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130305022515.GN29992@mournblade.imrryr.org> References: <20110323230013.GA16687@np305c2n2.ms.com> <18983715-1690-4916-BBB8-F7EDA8968370@vpnc.org> <20130301165900.GB29992@mournblade.imrryr.org> <20130302040122.GE29992@mournblade.imrryr.org> <20130302085339.GA22421@LK-Perkele-VII> <20130302182039.GF29992@mournblade.imrryr.org> <008e01ce1940$42030aa0$c6091fe0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008e01ce1940$42030aa0$c6091fe0$@augustcellars.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 02:25:16 -0000 On Mon, Mar 04, 2013 at 08:25:00PM -0500, Jim Schaad wrote: > For types 0, 1 and 2 - the DANE check is in addition to ALL existing PKI > checks. So the client validates two separate cryptographically signed name bindings (DNSSEC and EE cert contents), just to maximize the odds of failure? Why? What is gained by such checks? Does the group believe that in practice most TLS applications do CRL and/or OCSP checks and it is operationally easier to publish a timely revocation via a public CA than to maintain sensibly short RRSIG time limits and update one's own DNS when a key is lost? If this is not the case, then why doubt the DANE binding? [ One data point if you like: though Postfix has supported TLS for a decade, it doesn't and won't have CRL or OCSP support, but it will soon have DANE support. ] > For type 3 - I would agree that no PKI checks are to be done. That would > include the name matching check. Thanks, I hope this is the consensus view of the working group. -- Viktor. From paul.hoffman@vpnc.org Mon Mar 4 19:04:53 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E0821F8862 for ; Mon, 4 Mar 2013 19:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkd5zgj+vCtq for ; Mon, 4 Mar 2013 19:04:52 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C281D21F883E for ; Mon, 4 Mar 2013 19:04:52 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r2534p8X061802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 4 Mar 2013 20:04:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <20130305022515.GN29992@mournblade.imrryr.org> Date: Mon, 4 Mar 2013 19:04:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <43ABB2C5-0B0E-44A1-88BF-9E9714A0369F@vpnc.org> References: <20110323230013.GA16687@np305c2n2.ms.com> <18983715-1690-4916-BBB8-F7EDA8968370@vpnc.org> <20130301165900.GB29992@mournblade.imrryr.org> <20130302040122.GE29992@mournblade.imrryr.org> <20130302085339.GA22421@LK-Perkele-VII> <20130302182039.GF29992@mournblade.imrryr.org> <008e01ce1940$42030aa0$c6091fe0$@augustcellars.com> <20130305022515.GN29992@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1499) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 03:04:53 -0000 On Mar 4, 2013, at 6:25 PM, Viktor Dukhovni = wrote: > On Mon, Mar 04, 2013 at 08:25:00PM -0500, Jim Schaad wrote: >=20 >> For types 0, 1 and 2 - the DANE check is in addition to ALL existing = PKI >> checks. >=20 > So the client validates two separate cryptographically signed name > bindings (DNSSEC and EE cert contents), just to maximize the odds > of failure? Why? What is gained by such checks? The asserting party doesn't have to worry about a rogue CA. BTW: you probably misunderstood Jim's shorthand for type 2: there are no = PKI checks because it is a trust anchor. > Does the group believe that in practice most TLS applications do > CRL and/or OCSP checks and it is operationally easier to publish > a timely revocation via a public CA than to maintain sensibly short > RRSIG time limits and update one's own DNS when a key is lost? >=20 > If this is not the case, then why doubt the DANE binding? I'm not sure anyone suggested trusting the DANE binding. > [ One data point if you like: though Postfix has supported TLS for > a decade, it doesn't and won't have CRL or OCSP support, but it > will soon have DANE support. ] >=20 >> For type 3 - I would agree that no PKI checks are to be done. That = would >> include the name matching check. >=20 > Thanks, I hope this is the consensus view of the working group. Nothing in the RFC indicates that the relying party would do name = binding for type 3, I hope. --Paul Hoffman= From ietf@augustcellars.com Mon Mar 4 19:07:07 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E4421F8868 for ; Mon, 4 Mar 2013 19:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rqiaz19R-wIP for ; Mon, 4 Mar 2013 19:07:06 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id B098E21F883C for ; Mon, 4 Mar 2013 19:07:06 -0800 (PST) Received: from Philemon (dhcp63-140-207-211.hil-tpanohx.orl.wayport.net [63.140.207.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 7D7232CA12 for ; Mon, 4 Mar 2013 19:07:06 -0800 (PST) From: "Jim Schaad" To: References: <20110323230013.GA16687@np305c2n2.ms.com> <18983715-1690-4916-BBB8-F7EDA8968370@vpnc.org> <20130301165900.GB29992@mournblade.imrryr.org> <20130302040122.GE29992@mournblade.imrryr.org> <20130302085339.GA22421@LK-Perkele-VII> <20130302182039.GF29992@mournblade.imrryr.org> <008e01ce1940$42030aa0$c6091fe0$@augustcellars.com> <20130305022515.GN29992@mournblade.imrryr.org> In-Reply-To: <20130305022515.GN29992@mournblade.imrryr.org> Date: Mon, 4 Mar 2013 22:06:33 -0500 Message-ID: <00b001ce194e$71f57be0$55e073a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEpkg2iHviydEu22dUualAiSqVzDgIsgmgmAat01akBmEeTXAHExUF5AyP8siUA8Q7O0wJfuLEtAbZtqAiZZHbjIA== Content-Language: en-us Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 03:07:07 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Viktor Dukhovni > Sent: Monday, March 04, 2013 9:25 PM > To: dane@ietf.org > Subject: Re: [dane] Certificate usages 1/3 and subject name checks > > On Mon, Mar 04, 2013 at 08:25:00PM -0500, Jim Schaad wrote: > > > For types 0, 1 and 2 - the DANE check is in addition to ALL existing > > PKI checks. > > So the client validates two separate cryptographically signed name bindings > (DNSSEC and EE cert contents), just to maximize the odds of failure? Why? > What is gained by such checks? Yes - we want to maximize the security checks that are done. In this case the DANE checks are additional checks. If you don't like it - don't use these values. > > Does the group believe that in practice most TLS applications do CRL and/or > OCSP checks and it is operationally easier to publish a timely revocation via a > public CA than to maintain sensibly short RRSIG time limits and update one's > own DNS when a key is lost? > > If this is not the case, then why doubt the DANE binding? > > [ One data point if you like: though Postfix has supported TLS for > a decade, it doesn't and won't have CRL or OCSP support, but it > will soon have DANE support. ] > > > For type 3 - I would agree that no PKI checks are to be done. That > > would include the name matching check. > > Thanks, I hope this is the consensus view of the working group. > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From marka@isc.org Mon Mar 4 19:12:14 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189CB21F88D8 for ; Mon, 4 Mar 2013 19:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkKpiobPVZ8b for ; Mon, 4 Mar 2013 19:12:12 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id BEA7421F88C1 for ; Mon, 4 Mar 2013 19:12:12 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 62EF45F9887; Tue, 5 Mar 2013 03:11:47 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1362453116; bh=6hUfR+XYHrc47FJ03/dN4erMfzvJHkiayENXpesxXG0=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=h/hezn8dqdCZNOYZN2/gtIQJPCvdzB+sjMQuaXQx+a64XfjMHZmMDVaoiWkFJ88SJ 4+fvmZS8UL6tk2IeBOCjIoWTZGAyJvlCQT2pnhcV4yxqSDqp5P+MIX71LiOpumqd9p hetHE8JRM2w/Mbzs974zPORCDNvcBJhaHl/K3PmM= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B2748216C3B; Tue, 5 Mar 2013 03:11:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 9BACC30602C1; Tue, 5 Mar 2013 14:11:39 +1100 (EST) To: mrex@sap.com From: Mark Andrews References: <20130305000514.19DC81A5F4@ld9781.wdf.sap.corp> In-reply-to: Your message of "Tue, 05 Mar 2013 01:05:14 BST." <20130305000514.19DC81A5F4@ld9781.wdf.sap.corp> Date: Tue, 05 Mar 2013 14:11:39 +1100 Message-Id: <20130305031139.9BACC30602C1@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] revocation of keys or certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 03:12:14 -0000 In message <20130305000514.19DC81A5F4@ld9781.wdf.sap.corp>, Martin Rex writes: > Christian Becker wrote: > > Comparing PKIX and DANE I regularly get asked about the certificate > > revocation in DANE. > > There is no revocation in DANE. > > There is only expiration through RRSIG Signature Expiriation > and invalidation through zone key roll-over. > > > > > > In that case the revocation process can only be considered > > done when the TTL has elapsed. > > TTL is meaningless here. TTL's purpose is a mere guidance for caching, > TTL does not provide any security. It is an unsigned(!!) DNS record attribut > e > that an intermediary can make up at will. TTL is a signed field but instead being a single value it is a range. A intermediary can change it but the receiver knows what the range is supposed to be and can fix any attempt to set it to a value that is out of range. > -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mrex@sap.com Mon Mar 4 20:03:21 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F19921F87EE for ; Mon, 4 Mar 2013 20:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.762 X-Spam-Level: X-Spam-Status: No, score=-9.762 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik74FI4oJu1g for ; Mon, 4 Mar 2013 20:03:20 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 32E8C21F8542 for ; Mon, 4 Mar 2013 20:03:20 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r2543IAB015483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Mar 2013 05:03:18 +0100 (MET) In-Reply-To: <20130305031139.9BACC30602C1@drugs.dv.isc.org> To: Mark Andrews Date: Tue, 5 Mar 2013 05:03:18 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130305040318.AA59A1A5F4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] revocation of keys or certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 04:03:21 -0000 Mark Andrews wrote: > > Martin Rex writes: > > Christian Becker wrote: > > > Comparing PKIX and DANE I regularly get asked about the certificate > > > revocation in DANE. > > > > There is no revocation in DANE. > > > > There is only expiration through RRSIG Signature Expiriation > > and invalidation through zone key roll-over. > > > > > > > > > > In that case the revocation process can only be considered > > > done when the TTL has elapsed. > > > > TTL is meaningless here. TTL's purpose is a mere guidance for caching, > > TTL does not provide any security. It is an unsigned(!!) DNS record > > attribute that an intermediary can make up at will. > > TTL is a signed field but instead being a single value it is a > range. A intermediary can change it but the receiver knows what > the range is supposed to be and can fix any attempt to set it to a > value that is out of range. TTL is *NOT* signed. While there is an original TTL field that is signed: http://tools.ietf.org/html/rfc4034#section-3.1.4 this will not prevent any intermediary (attacker) to produce new DNS responses with TTLs less than or equal ot the original TTL field whenever necessary within the remaing RRSIG lifetime. -Martin From mrex@sap.com Mon Mar 4 20:14:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3E521F8881 for ; Mon, 4 Mar 2013 20:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.859 X-Spam-Level: X-Spam-Status: No, score=-9.859 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA+2wHhVHsuu for ; Mon, 4 Mar 2013 20:14:39 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5D59621F886C for ; Mon, 4 Mar 2013 20:14:34 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r254EWPO027377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Mar 2013 05:14:32 +0100 (MET) In-Reply-To: <43ABB2C5-0B0E-44A1-88BF-9E9714A0369F@vpnc.org> To: Paul Hoffman Date: Tue, 5 Mar 2013 05:14:32 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130305041432.C17A91A5F4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 04:14:40 -0000 Paul Hoffman wrote: > Viktor Dukhovni wrote: > > > On Mon, Mar 04, 2013 at 08:25:00PM -0500, Jim Schaad wrote: > > > >> For types 0, 1 and 2 - the DANE check is in addition to ALL existing PKI > >> checks. > > > > So the client validates two separate cryptographically signed name > > bindings (DNSSEC and EE cert contents), just to maximize the odds > > of failure? Why? What is gained by such checks? > > The asserting party doesn't have to worry about a rogue CA. > > BTW: you probably misunderstood Jim's shorthand for type 2: there are no PKI checks because it is a trust anchor. > > > Does the group believe that in practice most TLS applications do > > CRL and/or OCSP checks and it is operationally easier to publish > > a timely revocation via a public CA than to maintain sensibly short > > RRSIG time limits and update one's own DNS when a key is lost? > > > > If this is not the case, then why doubt the DANE binding? > > I'm not sure anyone suggested trusting the DANE binding. > > > [ One data point if you like: though Postfix has supported TLS for > > a decade, it doesn't and won't have CRL or OCSP support, but it > > will soon have DANE support. ] > > > >> For type 3 - I would agree that no PKI checks are to be done. That would > >> include the name matching check. > > > > Thanks, I hope this is the consensus view of the working group. > > Nothing in the RFC indicates that the relying party would > do name binding for type 3, I hope. I have a very very very bad feeling about this. Making a server cert for a server in DNS zone example.org succeed a name check for DANE usage type "3" might be as simple as creating such a cert with a "CN=*.example.org". Sending out the message that there are conditions when the name should be entirely ignored by TLS clients will cause creation of more new problems (and less of the existing problems getting fixed) in the long run. e.g. https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html It will also make it much harder to go from DANE usage 3 to DANE usage 2. And it might cause users to ignore names and other cert attributes, because most users will not understand the difference for name validation between DANE usage 0,1,2 and DANE usage 3. -Martin From marka@isc.org Mon Mar 4 20:33:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFF11F0D11 for ; Mon, 4 Mar 2013 20:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wg3fZ4ObczcQ for ; Mon, 4 Mar 2013 20:33:39 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 633811F0D0E for ; Mon, 4 Mar 2013 20:33:39 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 4F1CD5F9887; Tue, 5 Mar 2013 04:33:29 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1362458018; bh=O56i+eoZk/Ck+psbkpGLOGvCsU9NYeUUPjPzZ95AqSc=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=TwvT/+GGInmMtYjz1x3mfIVkwEcv17JkXoozysCwRmoyY/efVOyf2napTRjqm0JJn 3NinTueMCEKF3kPbiLJ3UA30gfs/veKtEwWMY8mvaFsWj3qB0SWQTz+nVQ7RLPSWIs fhQFGeM0Y5hgIySjLjAoDgV8ql6ul7y7Ro/6SP/w= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 36E57216C3B; Tue, 5 Mar 2013 04:33:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5E11F30640BD; Tue, 5 Mar 2013 15:33:25 +1100 (EST) To: mrex@sap.com From: Mark Andrews References: <20130305040318.AA59A1A5F4@ld9781.wdf.sap.corp> In-reply-to: Your message of "Tue, 05 Mar 2013 05:03:18 BST." <20130305040318.AA59A1A5F4@ld9781.wdf.sap.corp> Date: Tue, 05 Mar 2013 15:33:25 +1100 Message-Id: <20130305043325.5E11F30640BD@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] revocation of keys or certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 04:33:40 -0000 In message <20130305040318.AA59A1A5F4@ld9781.wdf.sap.corp>, Martin Rex writes: > Mark Andrews wrote: > > > > Martin Rex writes: > > > Christian Becker wrote: > > > > Comparing PKIX and DANE I regularly get asked about the certificate > > > > revocation in DANE. > > > > > > There is no revocation in DANE. > > > > > > There is only expiration through RRSIG Signature Expiriation > > > and invalidation through zone key roll-over. > > > > > > > > > > > > > > In that case the revocation process can only be considered > > > > done when the TTL has elapsed. > > > > > > TTL is meaningless here. TTL's purpose is a mere guidance for caching, > > > TTL does not provide any security. It is an unsigned(!!) DNS record > > > attribute that an intermediary can make up at will. > > > > TTL is a signed field but instead being a single value it is a > > range. A intermediary can change it but the receiver knows what > > the range is supposed to be and can fix any attempt to set it to a > > value that is out of range. > > TTL is *NOT* signed. > > While there is an original TTL field that is signed: > http://tools.ietf.org/html/rfc4034#section-3.1.4 > > this will not prevent any intermediary (attacker) to produce > new DNS responses with TTLs less than or equal ot the original > TTL field whenever necessary within the remaing RRSIG lifetime. > > -Martin And the sematic difference is what? When you produce a RRSIG you are saying to the world "all these TTL values are valid". It's just short hand for generating TTL+1 RRSIG covering each possible value. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From paul@cypherpunks.ca Mon Mar 4 20:34:33 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EF421F867D for ; Mon, 4 Mar 2013 20:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hwzJ0lWT5bZ for ; Mon, 4 Mar 2013 20:34:33 -0800 (PST) Received: from mx.nohats.ca (unknown [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id E95B721F8673 for ; Mon, 4 Mar 2013 20:34:31 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZKlch2BfYzB50 for ; Mon, 4 Mar 2013 23:34:28 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id R-3jmY6soBap for ; Mon, 4 Mar 2013 23:34:27 -0500 (EST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP for ; Mon, 4 Mar 2013 23:34:27 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id ADF5180D39; Mon, 4 Mar 2013 23:34:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A0AEE8043D for ; Mon, 4 Mar 2013 23:34:27 -0500 (EST) Date: Mon, 4 Mar 2013 23:34:27 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list In-Reply-To: <20130305020017.GM29992@mournblade.imrryr.org> Message-ID: References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 04:34:33 -0000 On Tue, 5 Mar 2013, Viktor Dukhovni wrote: >> I would actually very dislike such an interpretation, and require the >> name validation for *ALL* variants of X.509 certificates. > > This dislike translates into an important lost feature, no support > for direct binding of a service end-point to a public-key sans all > the baggage of the legacy public CA PKI. While I also dislike the name check, which should not be required or looked at for non-CA use, it is not hard to generate a wildcard certificate. > Yes, we can suggest to server operators that their certs SHOULD > carry a name that may be acceptable to legacy public CA PKI clients, > (if they are indeed signed by such legacy public CAs, for example, > today most SMTP certs are self-signed and one only gets protection > from passive eavesdroppers). Telling clients that they MUST reject > certs that don't have a corresponding CA-blessed name, even though > they have an authoritative DANE binding to the EE cert would be a > real shame. > > My (not outlandish) view is that the legacy public CA X.509 PKI is > a sinking ship. There is little reason to entrench its semantics > into new protocols except as an optional transition aid. While I agree here, it is kinda strange to put in a selfsigned generated cert in DNS. If you go through the effort of putting in a TLSA, you can also generate a proper cert for the mailserver? > When the service operator publishes a DNSSEC public key binding > (binds the service end-point to an EE certificate), that binding > should suffice. local policy :) > Smaller certificates use less bandwidth. This is the sort of lean > and mean certificate (303 bytes of DER) I plan to deploy on MX host > MTAs (bare minimum extensions to support TLS key usage). Loking forward to bare public key support in gnutls :) Then there is no name binding, so everyone is happy! Paul From mrex@sap.com Mon Mar 4 20:45:18 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C6621F86F4 for ; Mon, 4 Mar 2013 20:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.924 X-Spam-Level: X-Spam-Status: No, score=-9.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGDMWRxsLvjP for ; Mon, 4 Mar 2013 20:45:18 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8D321F86F7 for ; Mon, 4 Mar 2013 20:45:17 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r254jGMg019867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Mar 2013 05:45:16 +0100 (MET) In-Reply-To: <20130305043325.5E11F30640BD@drugs.dv.isc.org> To: Mark Andrews Date: Tue, 5 Mar 2013 05:45:16 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130305044516.156641A5F4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] revocation of keys or certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 04:45:18 -0000 Mark Andrews wrote: > > > > > TTL is *NOT* signed. > > > > While there is an original TTL field that is signed: > > http://tools.ietf.org/html/rfc4034#section-3.1.4 > > > > this will not prevent any intermediary (attacker) to produce > > new DNS responses with TTLs less than or equal ot the original > > TTL field whenever necessary within the remaing RRSIG lifetime. > > > > -Martin > > And the sematic difference is what? When you produce a RRSIG you > are saying to the world "all these TTL values are valid". It's > just short hand for generating TTL+1 RRSIG covering each possible > value. The original question was whether TTL provides revocation. No, TTL can not possibly provide revocation (for DNSSEC protected DNS records), because it can be made up at will by an intermediary attacker. Only the RRSIG lifetime and rolling the zone key are reliable in getting rid of DNSSEC protected data that is no longer to be seen as valid. It is like that "limited to one withdrawel per day" limit on ATM cards that is implemented by an unprotected counter that is stored on the ATM card itself. The crooks with a card reader/writer can simply reset that counter on the magnetic strip after withdrawal and perform multiple withdrawels (usually on ATMs of different banks) on the same day. -Martin From viktor1dane@dukhovni.org Mon Mar 4 21:59:44 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7B321F8464 for ; Mon, 4 Mar 2013 21:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbIDRvMTovAh for ; Mon, 4 Mar 2013 21:59:43 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6A821F842A for ; Mon, 4 Mar 2013 21:59:41 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BD0E52AB647; Tue, 5 Mar 2013 05:59:35 +0000 (UTC) Date: Tue, 5 Mar 2013 05:59:35 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130305055935.GO29992@mournblade.imrryr.org> References: <43ABB2C5-0B0E-44A1-88BF-9E9714A0369F@vpnc.org> <20130305041432.C17A91A5F4@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130305041432.C17A91A5F4@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 05:59:44 -0000 On Tue, Mar 05, 2013 at 05:14:32AM +0100, Martin Rex wrote: > Paul Hoffman wrote: > > Viktor Dukhovni wrote: > > > > > On Mon, Mar 04, 2013 at 08:25:00PM -0500, Jim Schaad wrote: > > > > > >> For types 0, 1 and 2 - the DANE check is in addition to ALL existing PKI > > >> checks. > > > > > > So the client validates two separate cryptographically signed name > > > bindings (DNSSEC and EE cert contents), just to maximize the odds > > > of failure? Why? What is gained by such checks? > > > > The asserting party doesn't have to worry about a rogue CA. Yes, of course, with 0/2. With 1, the asserting party told the client *exactly* which certificate to expect. That's it game over. With the EE certificate pinned-down, who cares about the name asserted by the CA. What concrete threat does the name check avert? It is not enough to "feel more secure" with the extra check in place, that looks like security theatre, there must actually be a real use-case in which the client avoids an attack by checking the CA asserted name. What is that use-case and attack? The only plausible use-case I see is that the PKIX CA checks facilitate revocation support, if one believes that revocation via public CAs is easier than removing records from DNS in a timely manner. Revocation checks are just as effective without the name check being performed. > > Nothing in the RFC indicates that the relying party would > > do name binding for type 3, I hope. > > I have a very very very bad feeling about this. Scars from the beatings of X.509? My response "doctor it hurts when I do that" is the usual one. > Making a server cert for a server in DNS zone example.org succeed a > name check for DANE usage type "3" might be as simple as creating > such a cert with a "CN=*.example.org". How many domains will have domain names in certs that will be raw UTF-8 rather than encoded as Punicode IDNs? How many will have multiple conflicting CNs? How many client applications won't support "*" wildcards or will vary in whether "*" means arbitrarily deeply nested hosts or just hosts in the immediate domain? > Sending out the message that there are conditions when the name should > be entirely ignored by TLS clients will cause creation of more new problems > (and less of the existing problems getting fixed) in the long run. In the long run, good riddance to the existing public CA PKI. > e.g. https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html bugs due to complexity we have the opportunity to reduce. > It will also make it much harder to go from DANE usage 3 to DANE usage 2. This claim deserves evidence. Self-signed certs will need to be replaced to switch from 3 to 2 whether or not the self-signed cert bears a name. > And it might cause users to ignore names and other cert attributes, > because most users will not understand the difference for name validation > between DANE usage 0,1,2 and DANE usage 3. Users should not be burdened with understanding certificates at all. With DANE, the application simply makes a secure connection, or fails. Users won't be revalidating DNSSEC RRSIGS in their heads, computing SHA256 checksums, ... DANE will make TLS security scale, and asking users to trust certificates signed by "Honest Achmed's Used Cars and Certificates" will fade into distant memory. https://bugzilla.mozilla.org/show_bug.cgi?id=647959 Does anyone have a real example in which a validator that ignores the CA signed name with certificate usage 1 (but not revocation, ...) faces a new tangible risk they don't face if they perform the name check? If there are no such examples, no RFC should compell the TLS client to check the (inside the cert) name bindings from the issuing CA in cert usage 1. [ FWIW, I'm still planning to ignore names with 1/3 in Postfix, as the suggested checks seem to have only negative value (they may fail) without redeeming features (they may avert a real threat). ]. -- Viktor. From viktor1dane@dukhovni.org Mon Mar 4 22:11:53 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66AB21F871D for ; Mon, 4 Mar 2013 22:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kH-N99cUrcyX for ; Mon, 4 Mar 2013 22:11:51 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 751AB21F8621 for ; Mon, 4 Mar 2013 22:11:50 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7A3782AB647; Tue, 5 Mar 2013 06:11:46 +0000 (UTC) Date: Tue, 5 Mar 2013 06:11:46 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130305061146.GP29992@mournblade.imrryr.org> References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 06:11:53 -0000 On Mon, Mar 04, 2013 at 11:34:27PM -0500, Paul Wouters wrote: > While I also dislike the name check, which should not be required or > looked at for non-CA use, it is not hard to generate a wildcard > certificate. Not all applications understand wildcard certificates, or even correctly parse certificate content. When the Moxie Marlinspike embedded NUL attack on CA name bindings was published, Postfix was one the few applications not impacted, since I already anticipated this problem and Postfix already had checks for embedded NULs in ASN.1 strings. The moral of this anecdote is not that the Postfix developers go the extra mile, but rather that X.509 is a very complex standard with many pitfalls, and anything that makes the application's job easier is a big win. The easiest way to check that you have the right certificate is to not parse it at all, or parse it just enough to extract the public key (this is generally directly supported by the SSL toolkit), and then just compare that or a digest of it to the value bound by DANE. The simplicity of the DANE binding leaves PKIX with its horde of trust anchors, local versions of intermediate certs, servers that fail to present all intermediate certs, depth limits, expiration date arithmetic, name constraints, multitudes of name types, critical extensions, ... in the dust. It is almost a miracle anyone ever gets X.509 validation right. >From the X.509 mess we get as many opportunities for insecurity as opportunities for enhanced security. > >My (not outlandish) view is that the legacy public CA X.509 PKI is > >a sinking ship. There is little reason to entrench its semantics > >into new protocols except as an optional transition aid. > > While I agree here, it is kinda strange to put in a selfsigned > generated cert in DNS. If you go through the effort of putting in > a TLSA, you can also generate a proper cert for the mailserver? It is a historical accident (naive MIT senior thesis in the early 80's IIRC) that we're using publica CA PKI at all. We might have had keys in DNS a lot sooner if X.509 were not an expedient crutch for a while. IMHO DANE provides a mechanism to bind service end points to public keys disguised as EE certificates only because we need to work with the current installed base, not because there is inherently something compelling about the existing "PKI". > >Smaller certificates use less bandwidth. This is the sort of lean > >and mean certificate (303 bytes of DER) I plan to deploy on MX host > >MTAs (bare minimum extensions to support TLS key usage). > > Loking forward to bare public key support in gnutls :) > > Then there is no name binding, so everyone is happy! Hooray, there is no name binding *inside the X.509 certificate*, but the real name binding (DNSSEC TLSA record) remains. ----- Speaking of name bindings, it would perhaps be useful to have DANE support for SMTP clients that are MTAs (not people using MUAs) to use client certificates to authenticate their EHLO names to servers. Since clients are not a _port._tcp. endpoint, we'd need some fixed prefix (_smtpc for smtp client?) that would allow the receiving MTA to check the DNS for: _smtpc._tcp. IN TLSA and verify the client's identity. This would enable scalable TLS-based client authentication without public CAs. This supports various outsourcing arrangements in which content provider or email hosting service relays mail through a client's gateway for DKIM signing, compliance archiving, ... But this is a different thread, for another day. -- Viktor. From ogud@ogud.com Tue Mar 5 04:19:18 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8D221F84DC for ; Tue, 5 Mar 2013 04:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyvKZ7+8I6Yl for ; Tue, 5 Mar 2013 04:19:17 -0800 (PST) Received: from smtp116.ord1c.emailsrvr.com (smtp116.ord1c.emailsrvr.com [108.166.43.116]) by ietfa.amsl.com (Postfix) with ESMTP id BDF7321F84D1 for ; Tue, 5 Mar 2013 04:19:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 377741B80CB; Tue, 5 Mar 2013 07:19:17 -0500 (EST) X-Virus-Scanned: OK Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 199A91B80DD; Tue, 5 Mar 2013 07:19:15 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Olafur Gudmundsson In-Reply-To: <20130305044516.156641A5F4@ld9781.wdf.sap.corp> Date: Tue, 5 Mar 2013 07:19:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3EDBF3AF-E1E0-410E-A63A-E2709BF54862@ogud.com> References: <20130305044516.156641A5F4@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1499) Cc: dane@ietf.org Subject: Re: [dane] revocation of keys or certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 12:19:18 -0000 On Mar 4, 2013, at 11:45 PM, Martin Rex wrote: > Mark Andrews wrote: >>=20 >>>=20 >>> TTL is *NOT* signed. >>>=20 >>> While there is an original TTL field that is signed: >>> http://tools.ietf.org/html/rfc4034#section-3.1.4 >>>=20 >>> this will not prevent any intermediary (attacker) to produce >>> new DNS responses with TTLs less than or equal ot the original >>> TTL field whenever necessary within the remaing RRSIG lifetime. >>>=20 >>> -Martin >>=20 >> And the sematic difference is what? When you produce a RRSIG you >> are saying to the world "all these TTL values are valid". It's >> just short hand for generating TTL+1 RRSIG covering each possible >> value. >=20 > The original question was whether TTL provides revocation. > No, TTL can not possibly provide revocation (for DNSSEC protected > DNS records), because it can be made up at will by an intermediary > attacker. Only the RRSIG lifetime and rolling the zone key are > reliable in getting rid of DNSSEC protected data that is no longer > to be seen as valid. >=20 > It is like that "limited to one withdrawel per day" limit on > ATM cards that is implemented by an unprotected counter that > is stored on the ATM card itself. The crooks with a > card reader/writer can simply reset that counter on the magnetic > strip after withdrawal and perform multiple withdrawels > (usually on ATMs of different banks) on the same day. >=20 Martin and Mark,=20 You are both right and neither fully wrong :-)=20 For most practical cases we can think of DNS time based "revocation" as = two different revocation times.=20 old RRset TTL =3D=3D is when an publisher of the record can assume that = MOST resolvers will have purged the old record from their caches. This = timer starts when the new RRset is distributed to the LAST authoritative = server for the zone.=20 Signature Expiration time =3D=3D Absolute time upto which an ON-PATH = adversary can reuse the old RRset and have it accepted by a targeted = victim.=20 The difference is the scope of the revocation, MOST vs Targeted, also if = the adversary is ON-PATH then it=20 can do lots of other things to the victim. There are differences in "how much" ON-PATH the adversary is, in some = cases they are listening to the query traffic on the write in other = cases they have succeeded in redirecting DNS traffic to resolvers under = their control.=20 From tom@ritter.vg Tue Mar 5 08:08:57 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD9C21F8648 for ; Tue, 5 Mar 2013 08:08:57 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocQVdXvTTkFk for ; Tue, 5 Mar 2013 08:08:51 -0800 (PST) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id B77D221F89A6 for ; Tue, 5 Mar 2013 08:08:51 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id ox1so5870730veb.41 for ; Tue, 05 Mar 2013 08:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=ZX4FUrCkbkB6loeCD8gl1SGusxgyKUr6hEqfmQmyWD0=; b=ScRQXAjfwTeaDyhIXh1q64whwRNNdgfRi0c0sS9H/9cTE9pVl/sk/VY8SssIh2UcWV HzG7tEPWlnXTUQlmaeAhGzEwwpgsmdjBwY/mGsdQKlqIdUYFGnO1L0JcdHQDY0KrvpRa owZ4FBFHfJr9o//QucXRERtSGNiSZAUHLv3AU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=ZX4FUrCkbkB6loeCD8gl1SGusxgyKUr6hEqfmQmyWD0=; b=UR8zuwTuqkwcAKTU/XWJ/fNX+FJkZHI1SvIrYoFUmgL8ePMiTMj+x7Wj9JAIlDTAYF pfk40blOXb4EM6jnXr4WUTp1IMqErDIgWn34yg3BbvyVgymL2vlA5mWI8jihC0nce+nC 8exDiufPYAHNJ7uMng0uwkTlk/KD/CoYUeMTmGlTMVUq5OOoVlrO5kwWtvT/0z6WjAwI 2AwEtJi7P3UhUgGpFy02QcMbakNYU5G6WIphZXw0+rfyqyYqhC9UCCIHog/UlnGFdmuj FTPjtMir9+vlTWp6H1WVQAj/tjq+YQXPVY0iK9kNVm7+SEcTeJBsBfgorXGxVCwyN+S1 Z6NQ== X-Received: by 10.221.11.135 with SMTP id pe7mr9764882vcb.41.1362499731063; Tue, 05 Mar 2013 08:08:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.182.169 with HTTP; Tue, 5 Mar 2013 08:08:29 -0800 (PST) In-Reply-To: <20130305061146.GP29992@mournblade.imrryr.org> References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> From: Tom Ritter Date: Tue, 5 Mar 2013 11:08:29 -0500 Message-ID: To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlGuYUzOxmYAqWN+xzI4nuglbvvvcIINWxp5ak8G6JUTuDXoLvUsRJpTQI4yZ5f/P+LKO6T Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 16:08:57 -0000 I think that name checks MUST be performed when validating certificates marked with usage 1. (And 0 & 2 obviously) Whatever your feelings on CAs are, DANE includes options to use them, and to assert that a certificate is valid within the CA system. Making name checking optional for Usages 1 means that a certificate *may not be valid* through the CA system but is still accepted. Thus I feel it violates the intention of the RFC with regards to Usage 1: To assert validity through BOTH DNSSEC and the CA system. > Does anyone have a real example in which a validator that ignores > the CA signed name with certificate usage 1 (but not revocation, ...) > faces a new tangible risk they don't face if they perform the name > check? If there are no such examples, no RFC should compell the > TLS client to check the (inside the cert) name bindings from the > issuing CA in cert usage 1. Stated simply: No, not today. (Because if you can change the record you could change it to Usage Mode 3) But I don't think that DANE in isolation is the only thing to consider. I think you should also consider how it can interact with other policy mechanisms. DANE, HSTS, Public Key Pinning, Content Security Policy - these are all mechanisms to assert that a site desires a certain security policy and asking the client to enforce it. Usage Modes 0 & 1 state "In addition to my policy here, you should follow this other (admittedly nebulous) policy." Ignoring name checking in 1 breaks that statement. Consider a situation where a domain asserts, through a new policy mechanism[0], that it ONLY wishes to use Usages 0 or 1 with the intention of requiring a validity assertion through both systems. It's a simple fact: it's harder to hack two unrelated systems than it is to hack one. So if I recieve a DANE Usage mode of 2 or 3 - I ignore it, because that's invalid, someone must have hacked my DNS. Ignoring name checking in 1 breaks that new policy mechanism. > In the long run, good riddance to the existing public CA PKI. Lots of people expressed that opinion, but the rough consensus model showed us that there was support for both supporting the CA model in Usages 0 and 1 and doing without it in Usages 2 & 3. Disabling name checking in Usage 1 feels like trying to give that rough consensus a run-around and invalidate what was decided with regards to Usage Mode 1. -tom [0] As an example: https://domainpolicy.org/ From viktor1dane@dukhovni.org Tue Mar 5 10:29:28 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F7F21F8654 for ; Tue, 5 Mar 2013 10:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koo2OYKXRCO8 for ; Tue, 5 Mar 2013 10:29:27 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6F821F8609 for ; Tue, 5 Mar 2013 10:29:27 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4DDFC2AB64D; Tue, 5 Mar 2013 18:29:26 +0000 (UTC) Date: Tue, 5 Mar 2013 18:29:26 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130305182925.GQ29992@mournblade.imrryr.org> References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 18:29:28 -0000 On Tue, Mar 05, 2013 at 11:08:29AM -0500, Tom Ritter wrote: > I think that name checks MUST be performed when validating > certificates marked with usage 1. (And 0 & 2 obviously) Thanks Tom, I think you give a clear explanation for the position that 1 means name checking. So I'll try to state my final objection in-line, and leave it at that... > I feel it violates the intention of the RFC with regards to Usage 1: > To assert validity through BOTH DNSSEC and the CA system. I agree only to the extent that the intension has a rational basis in added security. If we compel the client (via MUST name check) to reject some certificate, there must be a real reason for this, otherwise we're just breaking valid connections because it feels more PKI compliant. I have a proof that no such rational basis is possible, see below. It seems we're mistaking a server SHOULD (have a certificate with a matching name) for a client MUST (check for such a name), which limits flexibility and likely offers no additional security. This is I think the result of an incomplete threat model analysis. > > Does anyone have a real example in which a validator that ignores > > the CA signed name with certificate usage 1 (but not revocation, ...) > > faces a new tangible risk they don't face if they perform the name > > check? If there are no such examples, no RFC should compell the > > TLS client to check the (inside the cert) name bindings from the > > issuing CA in cert usage 1. > > Stated simply: No, not today. (Because if you can change the record > you could change it to Usage Mode 3) Lemma. If the attacker has compomised the DNS to the extent that he can sign new RRsets that the domain owner never signed, he wins, whether the client checks names or not. Proof 1: The attacker publishes a 3 1 1 usage for a new certificate of his choice, and even puts in the right name, though name checks in usage 3 are not needed. Proof 2: The attacker publishes a 2 1 1 usage for a new issuing CA of his choice, which signs a new certificate of his choice which bears the right name. Note 1: Such an attacker can subvert all other DNSSEC validated policy, so if there is anything in DNS published by the compromised domain that asserts that the domain never issues valid 2/3 TLSA records and always uses 0/1, this too can be subverted by the attacker, so it is not clear how say DPF would mattter. Note 2: How many potentially overlapping policy sources do we expect a DANE-aware client to consult? MUST a DANE-aware MTA also implement the future DPF, and then later yet another policy source? Surely complying with the semantics of TLSA records should not be a game of RFC whack-a-mole! Must I hold-off implementing DANE in Postfix until DPF is published, what else must I wait for? Corollary. Any justification for name checks must assume the attacker is not able to generate fraudulent TLSA records for the target domain. Therefore, in any attack thwarted by name checks the client acts on authentic (possibly stale, but not yet expired) TLSA records for the target domain. Proof: Since we're considering whether client name checks in usage 1 thwart active attacks, we focus on an authentic usage 1 RR signed by the target domain. When such an authentic record was issued, it legitimately bound the end-entity certificate to the service. Therefore, the certificate in question was the right one at that time. It was at that time properly signed by some public CA, and bound by the domain owner to the service in question. If the binding was once valid for the given service, and is not yet expired nor is the TLSA RR expired, to make it invalid one must revoke the certificate. PKIX trust chain validation gives us revocation checks and expiration checks. Therefore, there is nothing to be gained from name checks, as the name in the certificate is immutable. Q.E.D. Comment: The name check only serves to bind the hands of the domain owner. If name checks are mandatory on the client, the client must reject the EE certificate even though it was authentically bound to the service by the domain owner via DANE. This limits the domain owner to deploy said certificate only on the hosts originally anticipated when the certificate was obtained. Example: Consider an expensive 2-year certificate for mail.example.com, for a then small business which hosts POP, IMAP and inbound MX on a single host. The business has a good year and grows to the point that it makes sense to separate the MX host from the POP/IMAP service. The POP/IMAP MUAs predominantly do traditional PKI, so the mail.example.com name and certificate stay with the new mailbox host. Most MTAs on the other hand do opportunistic TLS at best, but some business partners already have explicit SMTP TLS security policy to connect to and verify mail.example.com. The business wants to improve mail security and use DANE to allow more partners to deliver email securely. So it makes sense to publish a 1/1/1 TLSA record binding mx.example.com to the existing certificate which still has 1 year of validity. This is thwarted by Tom's reading of the consensus interpretation. :-( I don't see any reason for DANE to prevent the domain owner from binding the still valid mail.example.com certificate to the new mx.example.com (split-off host) via a 1/1/1 TLSA record. Gut feeling is sometimes just indigestion. :-) What rational basis do we have to exclude this and other related use-cases? -- Viktor. From ajs@anvilwalrusden.com Tue Mar 5 10:45:56 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03E711E80F5 for ; Tue, 5 Mar 2013 10:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1q8VOqk2mbE for ; Tue, 5 Mar 2013 10:45:55 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id CA43A21F85A0 for ; Tue, 5 Mar 2013 10:45:51 -0800 (PST) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 1C8558A031 for ; Tue, 5 Mar 2013 18:45:51 +0000 (UTC) Date: Tue, 5 Mar 2013 13:45:49 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20130305184549.GQ17663@mx1.yitter.info> References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130305182925.GQ29992@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130305182925.GQ29992@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 18:45:56 -0000 On Tue, Mar 05, 2013 at 06:29:26PM +0000, Viktor Dukhovni wrote: > Lemma. If the attacker has compomised the DNS to the extent that > he can sign new RRsets that the domain owner never signed, he wins, > whether the client checks names or not. If the attacker actually has control of the domain, all bets are off. I fail to see how this is an interesting case. A -- Andrew Sullivan ajs@anvilwalrusden.com From cloos@jhcloos.com Tue Mar 5 10:50:26 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EAD11E8111 for ; Tue, 5 Mar 2013 10:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pk4ewN6+-6d for ; Tue, 5 Mar 2013 10:50:26 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2604:8800:100:81ca::53]) by ietfa.amsl.com (Postfix) with ESMTP id 0444C11E8110 for ; Tue, 5 Mar 2013 10:50:26 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id A8C2940273; Tue, 5 Mar 2013 18:49:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1362509423; bh=2rlhma3Qt3EiZdHXoruYbtNG74jiSkwZ097mp5XFuog=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=H4lCASyGPsfEMjHgEgYEIGtoqJZFbcz3eimzL71rw4j/eDshFpph0rIgxuu+qDkkw wKNTxhShagQGcaarpGq0+IR0oTDEMmsP3Ppdb3/ru+sStz2xwG2GYuj5KwRr8dumFA aY4ZwrbI4ZvPGl1P7AGOEDVCdBxIVtvGS178cxMk= Received: by carbon.jhcloos.org (Postfix, from userid 500) id BB296644B4; Tue, 5 Mar 2013 18:47:11 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <513485EC.5090309@tu-harburg.de> (Christian Becker's message of "Mon, 04 Mar 2013 12:30:52 +0100") References: <513322EC.6040803@tu-harburg.de> <4613980CFC78314ABFD7F85CC3027721119DA3E5@IL-EX10.ad.checkpoint.com> <513485EC.5090309@tu-harburg.de> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 05 Mar 2013 13:47:11 -0500 Message-ID: Lines: 9 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130305:dane@ietf.org::S8nsBXL3bi/mmtEy:00024FMF Subject: Re: [dane] revocation of keys or certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 18:50:26 -0000 It looks like a let offline distractions get the better of me with my previous post on this topic. What I wanted to write is that, given that dns servers cope well with very short RR TTLs, they also should cope well with short-duration RRSIGs. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From viktor1dane@dukhovni.org Tue Mar 5 11:09:21 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC7621F84F3 for ; Tue, 5 Mar 2013 11:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM8lNTnJWKF4 for ; Tue, 5 Mar 2013 11:09:20 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBA521F853C for ; Tue, 5 Mar 2013 11:09:17 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F20E62AB64D; Tue, 5 Mar 2013 19:09:14 +0000 (UTC) Date: Tue, 5 Mar 2013 19:09:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130305190914.GR29992@mournblade.imrryr.org> References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130305182925.GQ29992@mournblade.imrryr.org> <20130305184549.GQ17663@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130305184549.GQ17663@mx1.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 19:09:21 -0000 On Tue, Mar 05, 2013 at 01:45:49PM -0500, Andrew Sullivan wrote: > On Tue, Mar 05, 2013 at 06:29:26PM +0000, Viktor Dukhovni wrote: > > Lemma. If the attacker has compomised the DNS to the extent that > > he can sign new RRsets that the domain owner never signed, he wins, > > whether the client checks names or not. > > If the attacker actually has control of the domain, all bets are off. > I fail to see how this is an interesting case. It is not, we agree, I am ruling it out for the record. My argument boils down to: - If the domain owner never generates TLSA 1 records for end-entity certs whose name does not match the in: _port._proto. IN TLSA 1 ... the the client check never fails and is therefore redundant (for those domains). - If the domain owner does generate an authentically signed a TLSA 1 record: _port._proto. IN TLSA 1 ... with nowhere to be found in the cert, we should take the the domain owner at his word. There's no attacker here, just a domain owner who wants to bind an existing end-entity certificate to a new host, he chooses 1 rather than 3, as he believes that the CA he paid money adds some value via e.g. OCSP support allowing the certificate to be revoked. (As noted in a parallel thread there is no revocation for TLSA). The choice should be up to the server owner, and there is no reason for the client (really clients collectively by enforcing name checks in sufficient numbers) to take away this choice. The domain owner can still make the choice by never binding mismatched names. I claim that's where the choice ought to be made. -- Viktor. From ajs@anvilwalrusden.com Tue Mar 5 11:21:09 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3FD21F87E7 for ; Tue, 5 Mar 2013 11:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhgKkpyADRTf for ; Tue, 5 Mar 2013 11:21:08 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id E82B521F85C9 for ; Tue, 5 Mar 2013 11:21:06 -0800 (PST) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 363768A031 for ; Tue, 5 Mar 2013 19:21:02 +0000 (UTC) Date: Tue, 5 Mar 2013 14:21:00 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20130305192100.GR17663@mx1.yitter.info> References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130305182925.GQ29992@mournblade.imrryr.org> <20130305184549.GQ17663@mx1.yitter.info> <20130305190914.GR29992@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130305190914.GR29992@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 19:21:09 -0000 On Tue, Mar 05, 2013 at 07:09:14PM +0000, Viktor Dukhovni wrote: > > The choice should be up to the server owner, and there is no reason > for the client (really clients collectively by enforcing name checks > in sufficient numbers) to take away this choice. I think this boils down to the usual philosophical issue about whether the party whose interests are to be most protected is the client or the server. My own view is that it is entirely legitimate for the client to be in control here, because it is never possible for a server to assert anything that a client must do. A -- Andrew Sullivan ajs@anvilwalrusden.com From viktor1dane@dukhovni.org Tue Mar 5 12:00:27 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AD911E8148 for ; Tue, 5 Mar 2013 12:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51ZtFH8bwnT9 for ; Tue, 5 Mar 2013 12:00:22 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9D511E812F for ; Tue, 5 Mar 2013 12:00:10 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2F8682AB647; Tue, 5 Mar 2013 20:00:08 +0000 (UTC) Date: Tue, 5 Mar 2013 20:00:08 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130305200007.GS29992@mournblade.imrryr.org> References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130305182925.GQ29992@mournblade.imrryr.org> <20130305184549.GQ17663@mx1.yitter.info> <20130305190914.GR29992@mournblade.imrryr.org> <20130305192100.GR17663@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130305192100.GR17663@mx1.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 20:00:27 -0000 On Tue, Mar 05, 2013 at 02:21:00PM -0500, Andrew Sullivan wrote: > On Tue, Mar 05, 2013 at 07:09:14PM +0000, Viktor Dukhovni wrote: > > > > The choice should be up to the server owner, and there is no reason > > for the client (really clients collectively by enforcing name checks > > in sufficient numbers) to take away this choice. > > I think this boils down to the usual philosophical issue about whether > the party whose interests are to be most protected is the client or > the server. My own view is that it is entirely legitimate for the > client to be in control here, because it is never possible for a > server to assert anything that a client must do. This is a flippant response. Sure, the client can chooose to not implement DANE, or choose to misimplement it by adding 1 mod 4 to each cert usage and to take the bitwise complement of each digest value. Or any other number of crazy things. This thread is about the semantics of the TLSA "1 x y" RR (and the hopefully settled "3 x y" RR), and whether such records are potentially valid when the DNSSEC fqdn after _port._proto is not listed as a SAN or CN in the certificate. The semantic validity of such RRs is moot if client implementations (guided or perhaps misguided by RFCs) reject the target EE certificate. If such RRs, when intentionally created by domain owners, are to be given the chance to be useful, then clients that do choose to implement DANE must not enforce name checks on 1/3 EE certs. Name checks are only unavoidable when there is no explicit EE cert at hand, and all we have is an issuing CA and so are forced to check that we have the *right* EE cert by comparing names. When an EE cert is given a priori, trust chain validation boils down to making use of a revocation service for said EE certificate. This is the difference between 1 and 3 that follows from a security analysis. We can attempt to more completely mimmic legacy public CA PKI certificate validation and remove the choice I advocate, but that would be unfortunate, since it would needlessly only serve to limit the choices available to domain owners. There is nothing in the legacy public CA model that looks like usage "1" with an a priori given EE certificate, therefore it is not an axion that certificate validation (which always had two parts: trust chain checks often in SSL libraries, and name checks often at the application level) should look the same in this new case. Is it reasonable to continue to advocate my interpretation based on logic and consideration of security models? Or is it the group's view that structural similarity to existing legacy CA PKI practices trumps logical analysis? [ Cargo-cult security at the IETF? I hope not! ] Or is "the die cast" and it is simply too late to clarify the ambiguity in section 4 of 6698. At the very least, I hope updated dane-srv and dane-smtp drafts and final RFCs will not mandate name checks for "TLSA 3 x y", so this thread won't be entirely hot air. I also hope that the group will consider clarification the 0/2 1/3 feature matrix: High bit: PKIX trust chain validation Low bit: EE certificate, hence no name checks if nothing else this is a more orthogonal feature matrix. As I tried to show it supports reasonable additional use cases and opens no new attack vectors. -- Viktor. From cloos@jhcloos.com Tue Mar 5 12:00:28 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD77011E814D for ; Tue, 5 Mar 2013 12:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1u9EGBm6IHZ for ; Tue, 5 Mar 2013 12:00:22 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id D52E311E810F for ; Tue, 5 Mar 2013 12:00:22 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 2099D40273; Tue, 5 Mar 2013 19:59:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1362513613; bh=MJ91jhoV34k5o8xmeMATx4x65c3GdyP/Uvv/LgKYD9g=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Zp8/2soBTPPgrZRwLmHXcuGnTo/ZDdUnZcOeZNK4vL8YcTo33yEJfmmYyYv57S7vg ORFvHNf6jkvV/AUVATkP3eiMuVjdRFOMaa4dGUlPgQ76prKSthNwjITLOeDYWg0xuJ SQfAdq0Q6XKC14xkdVzTCWLbjQymzx40JnvLUTdc= Received: by carbon.jhcloos.org (Postfix, from userid 500) id AE07464AE4; Tue, 5 Mar 2013 19:57:31 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20130305182925.GQ29992@mournblade.imrryr.org> (Viktor Dukhovni's message of "Tue, 5 Mar 2013 18:29:26 +0000") References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130305182925.GQ29992@mournblade.imrryr.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 05 Mar 2013 14:57:31 -0500 Message-ID: Lines: 24 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130305:viktor1dane@dukhovni.org::xGbWH4F0NNq8hvHM:000000000000000000000000000000000000BmEq6 X-Hashcash: 1:30:130305:dane@ietf.org::n34DeYxS7y+1JvAN:000fFXaN Cc: dane@ietf.org Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 20:00:28 -0000 Types 0 and 1 were included because some expressed interest in continuing to rely on the existing PKI, but with extra confirmation from DANE. They very much wanted to have the TLSA only as an added check, hence the language in the rfc and many of the replies in this thread. Which is why, when I agreed that ignoring the CN and subjectAltName certainly makes sense for type 3, I didn't comment on type 1. I think that the type 0 and 1 supporters feel that keeping the tlsa as only an extra validation is more important than any other consideration. Skipping the name checks with type 1 doesn't bother me, and will not stop me from continuing to use pf or from enabling the tlsa lookups (if it is to be configurable). But I can understand the positions and motives of those who want complete adherence to the legacy pki model when using tlsa type 1. Even though I strongly prefer the type2/type3 model. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From viktor1dane@dukhovni.org Tue Mar 5 12:23:35 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F4111E8124 for ; Tue, 5 Mar 2013 12:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3Ho8onmP36v for ; Tue, 5 Mar 2013 12:23:34 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id A2DD611E8112 for ; Tue, 5 Mar 2013 12:23:34 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B48AB2AB647; Tue, 5 Mar 2013 20:23:33 +0000 (UTC) Date: Tue, 5 Mar 2013 20:23:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130305202333.GT29992@mournblade.imrryr.org> References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130305182925.GQ29992@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 20:23:35 -0000 On Tue, Mar 05, 2013 at 02:57:31PM -0500, James Cloos wrote: > I think that the type 0 and 1 supporters feel that keeping the > tlsa as only an extra validation is more important than any other > consideration. And yet logic leads us to observe that since the choice of certificate usage type is made by the domain owner and not the client, the domain owner gets exactly the desired semantics by never generating TLSA "1 x y" RRs where the name inside the cert is not the host fqdn. The client name check is then always redundant, since the certificate always matches. We can create additinal space for domain owners that want to choose 1, but don't want to consume the full legacy PKI banquet, they just want the revocation support main-course. They should be able to do so by generating non-matching (different name inside the cert) TLSA "1 x y" records. This way everyone is happy. Why should the domain owner's choice to be constrained by clients given that the domain owner, who defines TLSA records can equally publish 0, 2, 3 or other future certificate usages at their pleasure? I would like to suggest that the substance of TLSA being an additional check in 0/1 is completely retained when name checks are optimized out with 1 (as with compiler optimization of constant expressions), since the name checks would always succeed if made for domains that want this. To quote the Mikado: It's like this: When your Majesty says, "Let a thing be done," it's as good as done---practically, it is done---because your Majesty's will is law. Your Majesty says, "Kill a gentleman," a gentleman is told off to be killed. Consequently, that gentleman is as good as dead---practically, he is dead---and if he is dead, why not say so? No name checks need to happen, because they automatically match for the domains that want name matches, and never match for those that don't. -- Viktor. From viktor1dane@dukhovni.org Tue Mar 5 13:23:38 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E883311E80D3 for ; Tue, 5 Mar 2013 13:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irv8Z-5JQ9fu for ; Tue, 5 Mar 2013 13:23:38 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5E62D11E80B8 for ; Tue, 5 Mar 2013 13:23:38 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BEB172AB647; Tue, 5 Mar 2013 21:23:37 +0000 (UTC) Date: Tue, 5 Mar 2013 21:23:37 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130305212337.GU29992@mournblade.imrryr.org> References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130305182925.GQ29992@mournblade.imrryr.org> <20130305202333.GT29992@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130305202333.GT29992@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] Static name checks: (was: Certificate usages 1/3 and subject name checks) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 21:23:39 -0000 On Tue, Mar 05, 2013 at 08:23:33PM +0000, Viktor Dukhovni wrote: > I would like to suggest that the substance of TLSA being an additional > check in 0/1 is completely retained when name checks are optimized > out with 1 (as with compiler optimization of constant expressions), > since the name checks would always succeed if made for domains > that want this. I think the above the best and final argument. The domain owner can perform all 1/3 name checks *statically* at the time at which the TLSA record is generated. This frees the client from performing the name checks *dynamically* since RRs whose FQDN is not compatible (in the domain owner's eyes) with the EE certificate will never be generated. By specifying *static* (the domain owner does these when the TLSA record is generated) rather than *dynamic* name checks the DANE WG can enable new use-cases where the domain owner is free to associate an EE certificate with a new FQDN not originally included among the signed names in that certificate. I can help draft suitable revised language for section 4 of 6698 and/or an accompanying rationale, example use-cases, ... The only thing I can't do unfortunately is travel to IETF meetings, for lack of free time and sponsorship funds. -- Viktor. From marka@isc.org Tue Mar 5 14:08:37 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F88311E8116 for ; Tue, 5 Mar 2013 14:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbQJKnTs+-TK for ; Tue, 5 Mar 2013 14:08:37 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB4A11E8106 for ; Tue, 5 Mar 2013 14:08:35 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 87EC55F9887; Tue, 5 Mar 2013 22:08:17 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1362521306; bh=aGe5trOFsIzb4adhOHAvLmOgXc2sYG5wbLGVgL4PUqE=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=boRSReNnY1ia/62nTOGF5n12EARebj6eXVUjmoNrnqbpmyzC2H1TkalnOU03unenz DUe5OT207WKLNhq6k6HuKseYds3+mpcVjFXJtSM6keA/afyESg8Wp9ErTvWXQ4ojoQ zausWw+8G4AID820G7Jh0mTR0q7aCP9RjSgcdNkc= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:14dd:329:c316:c4f3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C857E216C3B; Tue, 5 Mar 2013 22:08:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 52C08306CEDA; Wed, 6 Mar 2013 09:08:12 +1100 (EST) To: James Cloos From: Mark Andrews References: <513322EC.6040803@tu-harburg.de> <4613980CFC78314ABFD7F85CC3027721119DA3E5@IL-EX10.ad.checkpoint.com> <513485EC.5090309@tu-harburg.de> In-reply-to: Your message of "Tue, 05 Mar 2013 13:47:11 CDT." Date: Wed, 06 Mar 2013 09:08:11 +1100 Message-Id: <20130305220812.52C08306CEDA@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] revocation of keys or certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 22:08:37 -0000 In message , James Cloos writes: > It looks like a let offline distractions get the better of me with my > previous post on this topic. > > What I wanted to write is that, given that dns servers cope well with > very short RR TTLs, they also should cope well with short-duration RRSIGs. Actually they don't. TTL are relative times. RRSIGs contain absolute time. TTLs say delete this in X seconds. RRSIGs say stop believing this a YYYYMMSSHHMMSS. If your clock is a day fast (a very real failure senario) it has NO impact on how the TTL is interpreted. It has a big impact on how the RRSIG values are interpreted. > -JimC > -- > James Cloos OpenPGP: 1024D/ED7DAEA6 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@anvilwalrusden.com Tue Mar 5 14:29:29 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9DC11E80BF for ; Tue, 5 Mar 2013 14:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmrobpjRryy4 for ; Tue, 5 Mar 2013 14:29:29 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBB911E809C for ; Tue, 5 Mar 2013 14:29:21 -0800 (PST) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 58ED38A031 for ; Tue, 5 Mar 2013 22:29:20 +0000 (UTC) Date: Tue, 5 Mar 2013 17:29:18 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20130305222918.GB18073@mx1.yitter.info> References: <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130305182925.GQ29992@mournblade.imrryr.org> <20130305184549.GQ17663@mx1.yitter.info> <20130305190914.GR29992@mournblade.imrryr.org> <20130305192100.GR17663@mx1.yitter.info> <20130305200007.GS29992@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130305200007.GS29992@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 22:29:30 -0000 On Tue, Mar 05, 2013 at 08:00:08PM +0000, Viktor Dukhovni wrote: > > This is a flippant response. I don't. > Sure, the client can chooose to not > implement DANE, or choose to misimplement it by adding 1 mod 4 to > each cert usage and to take the bitwise complement of each digest > value. Or any other number of crazy things. That's not my point. My point is rather that you seem to want the server to be the boss here, and I don't think that's reasonable. > The semantic validity of such RRs is moot if client implementations > (guided or perhaps misguided by RFCs) reject the target EE certificate. I don't think it's misguided. The point of this feature in the specification is for the server operator to be able to declare, "Oh, and by the way, the certificate I offer you in the DNS is the one you ought to be validating according to the traditional CA certificate chain, not other ones." At that point, the client gets either to use traditional CA validation without TLSA, or to use TLSA to perform additional validation beyond what would be done with the traditional CA chain. > If such RRs, when intentionally created by domain owners, are to > be given the chance to be useful For the use case, they're not useful. If you want this additional use case, why not create a new type? > We can attempt to more completely mimmic legacy public CA PKI > certificate validation and remove the choice I advocate, but that > would be unfortunate, since it would needlessly only serve to limit > the choices available to domain owners. It's not needless. It's part of the design of this feature. > Is it reasonable to continue to advocate my interpretation based > on logic and consideration of security models? Or is it the group's > view that structural similarity to existing legacy CA PKI practices > trumps logical analysis? I think it's wonderful when people present false dichotomies in their arguments in the form of rhetorical questions, but it doesn't make the position any more reasonable, no. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From tom@ritter.vg Tue Mar 5 15:40:58 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747D511E80BF for ; Tue, 5 Mar 2013 15:40:58 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01JXSP1wEn82 for ; Tue, 5 Mar 2013 15:40:57 -0800 (PST) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCA121F8611 for ; Tue, 5 Mar 2013 15:40:57 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id k1so4412931vck.24 for ; Tue, 05 Mar 2013 15:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=ba5MZyu0Ey/Wu0yApbvJu0OadMLTks7afxDSciOH24E=; b=P08m52A80D10R8EJ2UYMU0fMW1wtuLoWvPvkuylPg8+GnTotiGPvS9ZRumETNfivS8 5NTKfDJy90PqWn8cSKkaPSckKEtq1pBdwtcLEhg58WN39VTEUE7k0YGwro7xDJ2ehAS/ OQLG9SUy6q60eXQNfbFA32C+x9VLzHNzTRrlE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=ba5MZyu0Ey/Wu0yApbvJu0OadMLTks7afxDSciOH24E=; b=FON435WyGWELAP48EAM25L+ZWsCOh807K5nnbg6gFaar7ZiGiodK4J85j5ReMiFMwH B8enzMscH0Xg3TpIzeQV/2gq0Z+lYMf7MRg2IcAuzDd6/m7N6EhINhWuz84qJErWFrP5 mGs5lCYJNKhizJJhBrXY30sTCp4YLv360qAlCZ5Nu+nRAYWgbypovZY0vf4BovAnmepm 5v0tW/GF43FvFsjtvzf9sjcwTvSwdzdB7U5ZahjCNS2sU5NdoERHrd0r9quZTH2weVP2 A24O5Iaayx+ir1vABTeeCWpjQn80DJaAtXp+RHEFA+saReFoF2APxPx72QdxPL8WURUy wmmQ== X-Received: by 10.52.93.20 with SMTP id cq20mr9140989vdb.38.1362526856614; Tue, 05 Mar 2013 15:40:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.182.169 with HTTP; Tue, 5 Mar 2013 15:40:36 -0800 (PST) In-Reply-To: <20130305222918.GB18073@mx1.yitter.info> References: <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130305182925.GQ29992@mournblade.imrryr.org> <20130305184549.GQ17663@mx1.yitter.info> <20130305190914.GR29992@mournblade.imrryr.org> <20130305192100.GR17663@mx1.yitter.info> <20130305200007.GS29992@mournblade.imrryr.org> <20130305222918.GB18073@mx1.yitter.info> From: Tom Ritter Date: Tue, 5 Mar 2013 18:40:36 -0500 Message-ID: To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnRnBKvUXIGzfaiE+Jwn3j7qgn0P5cc0LVePpAJFM92K/HgafhI8j47dDYk3Y4hICxrB8ME Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 23:40:58 -0000 On 5 March 2013 13:29, Viktor Dukhovni wrote: > Note 1: Such an attacker can subvert all other DNSSEC validated > policy, so if there is anything in DNS published by the compromised > domain that asserts that the domain never issues valid 2/3 TLSA > records and always uses 0/1, this too can be subverted by the > attacker, so it is not clear how say DPF would mattter. DPF was an example for me, not a lynchpin of my argument, but I'll say that a component of DPF was allowing a policy on a root tld (e.g. .secure) like "only allow Usages 0 and 1, and require TLS 1.1 or above" and a domain in .secure (whether a legitimate or a hacked one) could not override the policy. > Note 2: How many potentially overlapping policy sources do we expect > a DANE-aware client to consult? MUST a DANE-aware MTA also implement > the future DPF, and then later yet another policy source? Surely > complying with the semantics of TLSA records should not be a game > of RFC whack-a-mole! Must I hold-off implementing DANE in Postfix > until DPF is published, what else must I wait for? Of course not. Any security mechanism: DPF, DANE, or TLS is an optional thing for anyone to implement. RFC whack-a-mole is a reality we must live with. TLS, TLS1.1, TLS1.2, AES-GCM, AES-CCM, DANE, HSTS, HPKP, so on and soforth. Caring about security, I'd like everyone to implement all the relevant mechanisms as soon as possible, but it's always been the prerogative for implementers to ignore or alter standards in their implementations. The goal is for you to see value in a standard and want to implement it. If you don't see value, we've failed as standards-creators or as evangelists. DPF could complement DANE by removing components of it that people feel nervous about, just as it could complement TLS by removing components people feel nervous about (requiring strict revocation checking, requiring TLS >1.1, etc). But I would never imply that it is a MUST-implement for a DANE (or anything-else) compliant implementation. I don't think formal proofs work well in things aside from math, because we'll wind up arguing over what is a valid assumption and what is not. > Corollary. Any justification for name checks must assume the attacker > is not able to generate fraudulent TLSA records for the target > domain. Therefore, in any attack thwarted by name checks the client > acts on authentic (possibly stale, but not yet expired) TLSA records > for the target domain. I do not assume that, I assume the attacker CAN generate fraudulent TLSA records, but is constrained by a higher-level Domain Policy that disallows usages 2 & 3. He can repoint the A record, he can make a new TLSA record, and he can create a Usage 2 & 3 but those won't be accepted. The attacker is not able to compromise a CA. With name checking the attack is thwarted, without it is not. Q.E.D. (Or something.) > I don't see any reason for DANE to prevent the domain owner from > binding the still valid mail.example.com certificate to the new > mx.example.com (split-off host) via a 1/1/1 TLSA record. > > Gut feeling is sometimes just indigestion. :-) What rational basis > do we have to exclude this and other related use-cases? My rational basis is that a certificate for mail.example.com is not a valid, CA signed certificate for mx.example.com. It may be a valid CERTIFICATE for the domain, but it is not a valid CA-signed certificate. To claim it is would be to state something untrue, just as if I were to say that my certificate for ritter.vg is a valid CA signed certificate for https://fuckyoulookatthiskitten.com[0]. There are a multitude of ways to allow those machines to interoperate with the businesses that violate standards or best practice - such as disabling certificate validation entirely. I think this is another example. [0] pardon the expletive, I just wanted to use a domain I actually control On 2 March 2013 13:20, Viktor Dukhovni wrote: > In both usage 3 and usage 1 the TLSA RR specify the end-entity > (leaf) certificate deployed on the server. Once a particular > certificate is explicitly bound to the server via a TLSA RR, there > is no point in comparing the server name with the content of the > certificate, we already have a binding and name checks We have ONE binding (DNSSEC) we do not have ALL the bindings for option 1: the valid Certificate Authority check. Checking the name is a required part of being "valid according to CAs rules". > One simple design rule I try to adhere to is: "don't fail when > success is an option". I try to adhere to the opposite when regarding network protocols: assume malice and untrustworthiness until proven otherwise. On 5 March 2013 15:00, Viktor Dukhovni wrote: > Is it reasonable to continue to advocate my interpretation based > on logic and consideration of security models? Or is it the group's > view that structural similarity to existing legacy CA PKI practices > trumps logical analysis? We disagree, but I resent being told my arguments are not logical. Your arguments make excellent sense, I just think you're dismissing something I care about. > At the very least, I hope updated dane-srv and dane-smtp drafts > and final RFCs will not mandate name checks for "TLSA 3 x y", so > this thread won't be entirely hot air. I agree, they should not. I'll try to state my point succinctly, and leave it at that... Although DANE mechanisms 2 & 3 allow bypassing CA checks, an alternate security policy may disallow usages 2 & 3 and require 0 or 1. Eliminating name checking for usage 1 nullifies the point of usage 1, because it is trivial to get a valid CA-signed cert for *some* domain - it is equivalent to usage 3 at that point. I see no reason to require name checking for usage 3. -tom From viktor1dane@dukhovni.org Tue Mar 5 16:09:53 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F5611E809C for ; Tue, 5 Mar 2013 16:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+TCMfpSLfvu for ; Tue, 5 Mar 2013 16:09:53 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 1069F21F8704 for ; Tue, 5 Mar 2013 16:09:53 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 59EEB2AB647; Wed, 6 Mar 2013 00:09:52 +0000 (UTC) Date: Wed, 6 Mar 2013 00:09:52 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130306000952.GW29992@mournblade.imrryr.org> References: <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130305182925.GQ29992@mournblade.imrryr.org> <20130305184549.GQ17663@mx1.yitter.info> <20130305190914.GR29992@mournblade.imrryr.org> <20130305192100.GR17663@mx1.yitter.info> <20130305200007.GS29992@mournblade.imrryr.org> <20130305222918.GB18073@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130305222918.GB18073@mx1.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 00:09:53 -0000 On Tue, Mar 05, 2013 at 05:29:18PM -0500, Andrew Sullivan wrote: > > We can attempt to more completely mimmic legacy public CA PKI > > certificate validation and remove the choice I advocate, but that > > would be unfortunate, since it would needlessly only serve to limit > > the choices available to domain owners. > > It's not needless. It's part of the design of this feature. If the meaning of the design is not crystal clear in the RFC (e.g. the dane-srv draft misread 6698 at least in part), and I am challenging the rationale used to justify a putative interpretation, telling me that is so by design merely begs the question. The feature (certificate usage "1") gives the domain owner a mechanism to express a policy preference for PKIX validation constrained to a given EE certificate. The name check part of this policy can and should be carried out by the domain owner statically before the TLSA RR is signed (if that's what the domain owner intends). Why delegate this (ostensibly important to the domain owner) policy check to the client, if it can be performed exactly once when the TLSA RR is about to be generated? A substantive answer would explain why static name checks by the domain owner are insufficient and why it is better to defer the static checks in favour of dynamic checks by clients. Such a subtantive answer should take into account evidence to the effect that static-only checks support use-cases not supported by dynamic checks with no detriment to the use-cases in which static and dynamic checks are functionally equivalent (provided clients never fail to carry out the dynamic checks). I think that section 4 of 6698 should be clarified to explain where name checks are appropriate and *who* should carry them out. I further posit that for 1/3 usage the *who* in question is the domain owner alone. If the working group does not agree with this analysis on logical grounds, please tell me why. If you concede my point, but the standard is set in stone and sufficiently clear on this point, and it is too late to clarify or amend, fine there are other imperfect standards. The only reason I'm tilting at this windmill is that it seems that the standard is not yet clear, and it could be clarified in a more fruitful direction. In addition the implementation of the standard in Postfix would be more natural if all a priori given EE certificates were treated identically with regard to name checks. Check that we have the right cert because either we knew which one to expect (1/3), or because the CA provided a name binding (0/2). The interpretation presented by Andrew and others asks for a hybrid model, which I am loathe to implement. It does not pass: - Don't fail when you can succeed. - Don't do dynamically what can be cheaply+reliably done statically. If there is still any opportunity to reconsider the issue, please examine my suggested interpretation on its merit. -- Viktor. From viktor1dane@dukhovni.org Tue Mar 5 17:27:38 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF4C11E80A5 for ; Tue, 5 Mar 2013 17:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.726 X-Spam-Level: X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_00=-2.599, FUZZY_AMBIEN=1.026, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qG2QqxCALzy for ; Tue, 5 Mar 2013 17:27:37 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 0531D11E80A3 for ; Tue, 5 Mar 2013 17:27:36 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 73AAD2AB647; Wed, 6 Mar 2013 01:27:36 +0000 (UTC) Date: Wed, 6 Mar 2013 01:27:36 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130306012736.GY29992@mournblade.imrryr.org> References: <20130305061146.GP29992@mournblade.imrryr.org> <20130305182925.GQ29992@mournblade.imrryr.org> <20130305184549.GQ17663@mx1.yitter.info> <20130305190914.GR29992@mournblade.imrryr.org> <20130305192100.GR17663@mx1.yitter.info> <20130305200007.GS29992@mournblade.imrryr.org> <20130305222918.GB18073@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 01:27:38 -0000 On Tue, Mar 05, 2013 at 06:40:36PM -0500, Tom Ritter wrote: > > Corollary. Any justification for name checks must assume the attacker > > is not able to generate fraudulent TLSA records for the target > > domain. Therefore, in any attack thwarted by name checks the client > > acts on authentic (possibly stale, but not yet expired) TLSA records > > for the target domain. > > I do not assume that, I assume the attacker CAN generate fraudulent > TLSA records, but is constrained by a higher-level Domain Policy that > disallows usages 2 & 3. He can repoint the A record, he can make a > new TLSA record, and he can create a Usage 2 & 3 but those won't be > accepted. If that's a real concern, and what we're getting from "1" is verification of the endpoint in the face of a compromised DNSSEC, when we can somehow securely obtain policy records that prohibit 2/3, then OK, this is a rationale for name checks in 1. Is this essentially the actual rationale, or a retroactively plausible one? We should consider what the above implies in the context of dane-srv and dane-smtp. Given that the DNSSEC controlling attacker can freely change the name that is going to be verified, that is the name of the MX host or SRV host: example.secure. IN MX 0 example.evil. example.evil. IN TLSA 1 1 1 the name the client is going to look for in the CA-issued certificate (example.evil) is now under the control of the attacker. Can we statically optimize out name checks in this case? > The attacker is not able to compromise a CA. With name checking the > attack is thwarted, without it is not. Q.E.D. (Or something.) With say, HTTP where the user entered the https://example.secure/ URL directly and something like the DPF policy you describe exists, and ideally also constrains or specifies the trust anchors for the gTLD. > > I don't see any reason for DANE to prevent the domain owner from > > binding the still valid mail.example.com certificate to the new > > mx.example.com (split-off host) via a 1/1/1 TLSA record. > > My rational basis is that a certificate for mail.example.com is not a > valid, CA signed certificate for mx.example.com. It may be a valid > CERTIFICATE for the domain, but it is not a valid CA-signed > certificate. If we believe that the purpose of "1" is to thwart DNSSEC compromise when the client is armed with additional policy that rejects 2/3 DANE certificate usages for the destination domain, OK, in that case name checks for "1" make some sense, provided there are no pesky MX or SRV records. > To claim it is would be to state something untrue, just > as if I were to say that my certificate for ritter.vg is a valid CA > signed certificate for https://fuckyoulookatthiskitten.com[0]. In my threat model, game over when DNSSEC is compromised, so the certificate was signed by you at some point, and if that's the CA certificate you want to use at https://FULATK.COM you're free to do so. You paid the cert and get the benefits of the CA's certificate revocation services. It should not be DANE's job to protect the CA's revenue stream by ensuring that a certificate for server X is never deployed in server Y. Is the model you present in fact expected to gain some traction? Do we expect browsers to consult DPF? How will DPF interact with SRV and MX records? Will ".secure" gTLD domains be constrained to never generate SRV or MX records that point outside the sandbox? > > Is it reasonable to continue to advocate my interpretation based > > on logic and consideration of security models? Or is it the group's > > view that structural similarity to existing legacy CA PKI practices > > trumps logical analysis? > > We disagree, but I resent being told my arguments are not logical. > Your arguments make excellent sense, I just think you're dismissing > something I care about. You just gave a logical argument. Thanks. I don't recall seeing anything as specific upthread. If I missed it, apologies to the poster. > Although DANE mechanisms 2 & 3 allow bypassing CA checks, an alternate > security policy may disallow usages 2 & 3 and require 0 or 1. > Eliminating name checking for usage 1 nullifies the point of usage 1, > because it is trivial to get a valid CA-signed cert for *some* domain > - it is equivalent to usage 3 at that point. I see no reason to > require name checking for usage 3. If this is protecting against DNSEC subversion in the presence of policy that partly overrides DANE, I agree. If this is protecting against compromised server private keys, ... then the value of the CA is just revocation support, in which case the name check is redundant and can be performed statically by the domain owner. So for Postfix (MTA to MTA SMTP), since we don't yet have DPF (and may not in any case benefit from it given MX record indirection), and don't have or plan to offer revocation checks or OCSP, the plan is to simply ignore the CA bit and to treat each of 0/2 and 1/3 as equivalent sources of either a trust anchor or an end-point certificate. This will substantially improve the security of email delivery without substantially increasing the risk of email disruption because the receiving domain's issuing CA is not locally trusted, or some name check failed when the EE cert is available, ... If it were up to me, I'd go further and in dane-smtp recommend that administrators publish "TLSA 3 1 1" records (as in the case of netlabs.nl) as the most likely to improve security without causing delays from some senders due to verification glitches. In some cases the "3 1 1" cert may in fact be CA-issued, and some senders will validate them via legacy PKI policy rather than DANE. Since I'm sensing little support from this group for dropping name checks in the "TLSA 1 1 1" use-case, email administrators will not be able to leverage "TLSA 1 1 1" for revocation services, but this is not a big loss, since few if any MTAs do revocation checks or OSCP (most don't even offer correctly implemented name checks). Thanks for your attention. -- Viktor. From tom@ritter.vg Tue Mar 5 19:41:18 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08F311E80EE for ; Tue, 5 Mar 2013 19:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=-1.407, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_74=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiXio4cuXypL for ; Tue, 5 Mar 2013 19:41:18 -0800 (PST) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id D2FC811E80EA for ; Tue, 5 Mar 2013 19:41:15 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id pb11so6415190veb.33 for ; Tue, 05 Mar 2013 19:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=UEgUMhsYGGTzyGMloWS5lJ2/ENWK4XaVZXvYhhysaNs=; b=cF0ga8rF4UNPe4lXWmGeXPkjn7+oQuW5NiwU7+raGB0tP9/9CzPVoOHu4bX5OEjxgL DucuRHPCu3KA6AW5Kbc6EA3+Ar1l5ldej1OAWsiSobq3pia2AgFCdujh7vC6t4rdTDv4 t3wh2r754RpjPAdYv93dKGo1WeflBnGayVmTw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=UEgUMhsYGGTzyGMloWS5lJ2/ENWK4XaVZXvYhhysaNs=; b=PjIFdqiD6yRwr3Z8HCKovGwAWOE911d3mQdImsKMFfOE2EEYRNtdu88IvQWcYQUJT/ Vt9TheLqm6V+DL0Caz+fCye7HHkuOFuNqQIHEAbadp8D84eAceQ2n1L9AMYkR8PqYU5w WY9oc9Ay/FdRO8/xv5WnRh+op9xAhSx14E/kcUqf8BFIErQoClDh6I/9KJkllPiq5oWT vdv69f5FGpeB3MjhptQ61biX8sEUQpiEZ3S/9Cm6MmfPYQZOqWFDkOSIW1mYVILNSLsO j+vN//ULyk+oLHUB2+/WRcJaP3xS9ofk8+jgn4KyGSYsRO8XooH16XBOVzWwxkD1H/KZ 0e1A== X-Received: by 10.52.93.235 with SMTP id cx11mr9091921vdb.51.1362541275061; Tue, 05 Mar 2013 19:41:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.182.169 with HTTP; Tue, 5 Mar 2013 19:40:54 -0800 (PST) In-Reply-To: <20130306012736.GY29992@mournblade.imrryr.org> References: <20130305061146.GP29992@mournblade.imrryr.org> <20130305182925.GQ29992@mournblade.imrryr.org> <20130305184549.GQ17663@mx1.yitter.info> <20130305190914.GR29992@mournblade.imrryr.org> <20130305192100.GR17663@mx1.yitter.info> <20130305200007.GS29992@mournblade.imrryr.org> <20130305222918.GB18073@mx1.yitter.info> <20130306012736.GY29992@mournblade.imrryr.org> From: Tom Ritter Date: Tue, 5 Mar 2013 22:40:54 -0500 Message-ID: To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnpyZFSc4vV+ASy9EtTNd4kGRFRPxfa2gjFAcemUF/majKbOXq6I7pcXMHZQmhhsDVvIoAA Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 03:41:19 -0000 On 5 March 2013 20:27, Viktor Dukhovni wrote: > Is this > essentially the actual rationale, or a retroactively plausible one? Not retroactive, I am really concerned about situations where another security policy (DPF, or organisationally local) trim what is 'acceptable' for DANE to 0&1. Furthermore, I'll say specifically that I have argued because my interpretation has been while you obviously are interested in the mailserver side of things, that the argument applied to all DANE checks... > We should consider what the above implies in the context of dane-srv > and dane-smtp. Given that the DNSSEC controlling attacker can > freely change the name that is going to be verified, that is the > name of the MX host or SRV host: > > example.secure. IN MX 0 example.evil. > example.evil. IN TLSA 1 1 1 > > the name the client is going to look for in the CA-issued certificate > (example.evil) is now under the control of the attacker. Can we > statically optimize out name checks in this case? I will be the first to admit I'm not an expert in mail systems, and will also add that you definitely know more about them than me. In this case, from what you're describing and from what I know (which is limited) - it makes sense. I obviously don't have to give you permission in any case - I much prefer to say "Now that we're talking specifically about mailservers, I don't know enough about it to give an informed opinion in this matter." > Is the model you present in fact expected to gain some traction? > Do we expect browsers to consult DPF? DPF is fledgling. I *hope* DPF will be created and I *hope* browsers will consult it. I am also friends with the guy who's pushing DPF and another venture (.secure). They integrate well together, and while I suspect you and a lot of folks won't like .secure (you can ping me off list if you'd like to debate the merits) - I think DPF is cool, and I am for it. > How will DPF interact with SRV and MX records? Will ".secure" gTLD > domains be constrained to never generate SRV or MX records that > point outside the sandbox? I have *no idea*. I couldn't even conjecture intelligently. Sorry. When that stage is reached, we'd love to get input on it. >> Although DANE mechanisms 2 & 3 allow bypassing CA checks, an alternate >> security policy may disallow usages 2 & 3 and require 0 or 1. >> Eliminating name checking for usage 1 nullifies the point of usage 1, >> because it is trivial to get a valid CA-signed cert for *some* domain >> - it is equivalent to usage 3 at that point. I see no reason to >> require name checking for usage 3. > > If this is protecting against DNSEC subversion in the presence of > policy that partly overrides DANE, I agree. That's all I was arguing. Whoo-hoo! Common ground! > So for Postfix (MTA to MTA SMTP), since we don't yet have DPF (and > may not in any case benefit from it given MX record indirection), > and don't have or plan to offer revocation checks or OCSP, the plan > is to simply ignore the CA bit and to treat each of 0/2 and 1/3 as > equivalent sources of either a trust anchor or an end-point > certificate. This will substantially improve the security of email > delivery without substantially increasing the risk of email disruption > because the receiving domain's issuing CA is not locally trusted, > or some name check failed when the EE cert is available, ... I am all for opportunistic encryption of SMTP, and I think any DANE entry (1 or 3) goes a very, very long way towards securing it.[0] Thank you for working on it. -tom [0] http://ritter.vg/blog-no_email_security.html From viktor1dane@dukhovni.org Tue Mar 5 22:54:52 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B67021F854F for ; Tue, 5 Mar 2013 22:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyhaO7EXFqeU for ; Tue, 5 Mar 2013 22:54:51 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id C63D421F845A for ; Tue, 5 Mar 2013 22:54:51 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A622C2AB646; Wed, 6 Mar 2013 06:54:50 +0000 (UTC) Date: Wed, 6 Mar 2013 06:54:50 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130306065450.GC29992@mournblade.imrryr.org> References: <20130305182925.GQ29992@mournblade.imrryr.org> <20130305184549.GQ17663@mx1.yitter.info> <20130305190914.GR29992@mournblade.imrryr.org> <20130305192100.GR17663@mx1.yitter.info> <20130305200007.GS29992@mournblade.imrryr.org> <20130305222918.GB18073@mx1.yitter.info> <20130306012736.GY29992@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 06:54:52 -0000 On Tue, Mar 05, 2013 at 10:40:54PM -0500, Tom Ritter wrote: > > Is the model you present in fact expected to gain some traction? > > Do we expect browsers to consult DPF? > > DPF is fledgling. I *hope* DPF will be created and I *hope* browsers > will consult it. I am also friends with the guy who's pushing DPF and > another venture (.secure). They integrate well together, and while I > suspect you and a lot of folks won't like .secure (you can ping me off > list if you'd like to debate the merits) - I think DPF is cool, and I > am for it. > > [...] > > > If this is protecting against DNSEC subversion in the presence of > > policy that partly overrides DANE, I agree. > > That's all I was arguing. Whoo-hoo! Common ground! Yes, some common ground, which is good. Though I must admit that with the logical bases for our positions established, and a judgement call required to assess the pros/cons of the implied trade-offs, I see the DPF rationale as a somewhat nebulous corner-case that could apply to a small set of domains that migrate into a walled-garden gTLD. For the bulk of .com and .net domains, no protections against DNSSEC compromise will be available in the form of constraints on DANE 2/3 from a parent domain. If this is the strongest reason to impose a MUST name check on clients, and as a result one can no longer extend the utility of an existing CA certificate when ones needs change in early in the certificate's lifetime, where I at the WG meeting, I'd try to hold my ground if there was some hope of getting support. I'm not sensing much support here for my "static check" argument, so I guess I'm done. Thanks letting me air my views, I hope the WG will use whatever useful insigths I may have provided for some good. > I am all for opportunistic encryption of SMTP, and I think any DANE > entry (1 or 3) goes a very, very long way towards securing it.[0] > Thank you for working on it. Thanks, I hope to have working code by June and a Postfix snapshot release some time after Wietse's had a chance to adopt it. As for SMTP and SRV records, given the observations about unavoidable reliance on DNSSEC security in choosing which names to check against the certificate, I still contend that in protocols that choose their peer indirectly, there is no reason to check names in 1/3, and so https://tools.ietf.org/html/draft-ietf-dane-srv-02#section-7.3 should be revised to no only require name checks for 0/2 and to suggest that clients accept the implied name binding via DNSSEC TLSA for 1/3 without second-guessing it with certificate content checks. The fallback position which is less controversial is to at least exempt 3. Thanks again to Tony Finch for bringing the drafts to my attention, I hope he is not sorry he did so (i.e. feel free to blame him for my rants :-). If Tony or anyone else wishes to discuss the specific use case of SMTP+DANE or more generally SRV+DANE, I won't object to off-list email. I am happy to comment on proposed draft language, since I have a stake in the outcome. -- Viktor. From ondrej.sury@nic.cz Wed Mar 6 05:08:51 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A16B21F8938 for ; Wed, 6 Mar 2013 05:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owD7NquW4yDj for ; Wed, 6 Mar 2013 05:08:50 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC4E21F8936 for ; Wed, 6 Mar 2013 05:08:50 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:c4e8:4667:96d2:eff6] (unknown [IPv6:2001:1488:ac14:1400:c4e8:4667:96d2:eff6]) by mail.nic.cz (Postfix) with ESMTPSA id E74F613F94B for ; Wed, 6 Mar 2013 14:08:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1362575328; bh=ilt84h9GK7VNHrPgUeqPjSHOIma8P5eNY+82ivslAz0=; h=From:Content-Type:Message-Id:Mime-Version:Subject:Date:References: To:In-Reply-To; b=ro6t9F9xNEYLQV9Qp6wAUmRRUfZ1PCzu5dTptaMfHn6n2sP6aTF+oQdtfjJ1hjX9p IUpMd0l1piIdvUVVcfy1d66s7Z3XPT4usm0K8xgWZWtvOkGTUolD4JY/ha3/mjQOnT sl4kHsbcvskW9BvIiiKDWlW+Ajwi5pipkheij4ks= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: multipart/signed; boundary="Apple-Mail=_72C8A045-B0ED-4C19-8F14-D1DE1D5AC20F"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <54ABCDF9-52E3-41C8-A1C5-6D387DFB5746@nic.cz> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Wed, 6 Mar 2013 14:08:48 +0100 References: <43ABB2C5-0B0E-44A1-88BF-9E9714A0369F@vpnc.org> <20130305041432.C17A91A5F4@ld9781.wdf.sap.corp> <20130305055935.GO29992@mournblade.imrryr.org> To: dane@ietf.org In-Reply-To: <20130305055935.GO29992@mournblade.imrryr.org> X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 13:08:51 -0000 --Apple-Mail=_72C8A045-B0ED-4C19-8F14-D1DE1D5AC20F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 5. 3. 2013, at 6:59, Viktor Dukhovni = wrote: > On Tue, Mar 05, 2013 at 05:14:32AM +0100, Martin Rex wrote: >=20 >> Paul Hoffman wrote: >>> Viktor Dukhovni wrote: >>>=20 >>>> On Mon, Mar 04, 2013 at 08:25:00PM -0500, Jim Schaad wrote: >>>>=20 >>>>> For types 0, 1 and 2 - the DANE check is in addition to ALL = existing PKI >>>>> checks. >>>>=20 >>>> So the client validates two separate cryptographically signed name >>>> bindings (DNSSEC and EE cert contents), just to maximize the odds >>>> of failure? Why? What is gained by such checks? >>>=20 >>> The asserting party doesn't have to worry about a rogue CA. >=20 > Yes, of course, with 0/2. With 1, the asserting party told the > client *exactly* which certificate to expect. That's it game over. > With the EE certificate pinned-down, who cares about the name > asserted by the CA. What concrete threat does the name check avert? The '1' was deliberately designed, so it _is_ compatible with existing = CA model and existing applications (DANE-aware and non-DANE-aware). If = you don't like that just use type 3. (Or type when bare TLS = certificates are out.) If you want to be compatible with DANE, I would suggest to implement the = protocol as is, pretty please. (On the other hand, the existing MTA = implementations don't give a damn about existing standards, so it will = be status quo anyway.) O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- --Apple-Mail=_72C8A045-B0ED-4C19-8F14-D1DE1D5AC20F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMKTCCBgYw ggTuoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwga8xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVz dGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMzAx BgNVBAMTKlRydXN0ZWQgSW50cm9kdWNlciAoVEkpIFRvcGxldmVsIENBIC0gRzAwMTEnMCUGCSqG SIb3DQEJARYYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMB4XDTA0MTIwNzEwMzYxN1oXDTMwMTIw NjAwMDAwMFowga0xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJ KTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50 cm9kdWNlciAoVEkpIENsaWVudCBDQSAtIEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQt aW50cm9kdWNlci5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOKQxMR3KDUpfJBz AhY2BPCByKo9SMp/V0RIboLBD6vO0miSYO9FmP3Q07OKPYR5WdlQyrpKqB1zl0SRz2cDjnYkzvDF vK5kvMvlTYeQlHypQlvhkTsYWD4ZZxxEhAYBb1s7cYaIahLw6H/RZz+kyWTOc9TncPBvBWIQ1Ypo S+uQqpopH8s5ebtB/17SbUty5yXiHoaPh/ScdMKqxbyJiL0YRM6SU4YX4HVZ5YGS9aWuiUSiA0YF 8dCR56nErx67wgq8O1GtsSKKOf/ueUxSmrqwgQNlfM9Or5O8kb61s1O2iACHtixoV3ENanylBafU mRYpNo5tSZsElGfntMoGBy8CAwEAAaOCAiswggInMB0GA1UdDgQWBBSeX93lU8ExaSlN1ZaXxfOP h2iHTjCB3AYDVR0jBIHUMIHRgBRdbehwJx/8iwlxnguJECc7MUXvoqGBtaSBsjCBrzELMAkGA1UE BhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAoVEkpMSAwHgYDVQQLExdDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTEzMDEGA1UEAxMqVHJ1c3RlZCBJbnRyb2R1Y2VyIChUSSkgVG9wbGV2 ZWwgQ0EgLSBHMDAxMScwJQYJKoZIhvcNAQkBFhhjYUB0cnVzdGVkLWludHJvZHVjZXIubmyCAQAw DwYDVR0TAQH/BAUwAwEB/zAjBgNVHRIEHDAagRhjYUB0cnVzdGVkLWludHJvZHVjZXIubmwwgasG A1UdHwSBozCBoDBOoEygSoZIaHR0cDovL2NybDEudHJ1c3RlZC1pbnRyb2R1Y2VyLm5sL2NhL3g1 MDkvZzEvZGF0YS9jcmxzL2NybC1yb290LWNhLTEuY3JsME6gTKBKhkhodHRwOi8vY3JsMi50cnVz dGVkLWludHJvZHVjZXIubmwvY2EveDUwOS9nMS9kYXRhL2NybHMvY3JsLXJvb3QtY2EtMS5jcmww IwYDVR0RBBwwGoEYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMAsGA1UdDwQEAwIBBjARBglghkgB hvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEFBQADggEBAI1sC2l8st3ElC74az6gH7tGXSiS7jicpHeI 10A3KY+7OEPT7BAJDpjMXxSvAwU1vBDFfwEAXGj42xAPB6cynOTDn0OiFpYGvi3EZV3khXYkGPLs fxZttUyDKqhXcWYy4nnI3fBxqCgLboJFw6OO/SVj5qQdXMZ7VhyFBWJMQkVOnlt6i3xFkG3O5LMI BDmdL5bZPEe8b6bJkMr+rUYEvorPJmV+CkiewYMaruCbdhwRkpkhXB3qLwB2ppnKxSinAU4f9Rcp p73h8iDVQ9389iliUKomVQqj9NJv2G6SyJdDQdN2vrldLszNpw6t+zIzCjpgQ//kem5BJ1k4YG3L CpAwggYbMIIFA6ADAgECAgIGSDANBgkqhkiG9w0BAQUFADCBrTELMAkGA1UEBhMCTkwxIDAeBgNV BAoTF1RydXN0ZWQgSW50cm9kdWNlciAoVEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJbnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEn MCUGCSqGSIb3DQEJARYYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMB4XDTEyMDgwMTA3NTEyNloX DTE0MDgwMTA3NTEyNlowejELMAkGA1UEBhMCTkwxGzAZBgNVBAoTElRydXN0ZWQgSW50cm9kdWNl cjEVMBMGA1UECxMMQ1ouTklDLUNTSVJUMRQwEgYDVQQDEwtPbmRyZWogU3VyeTEhMB8GCSqGSIb3 DQEJARYSb25kcmVqLnN1cnlAbmljLmN6MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA xlmN+hSg6RxWm1X6QOI3OXHSAqhRzWGb8ismR2+3LGDS640luS8x4VdWo490Ceqz+BZvMhQJwfny 9mb0IejFpx7kBOM7k2rMfOYUXa/pq07ysWEI8bXDcXRBf2ZcG0B/gajLPFA9MADlCWHSf7cNZF6S XnIHwTn5DowxpbF403NqLWFnTM08wTJkFgGB7WZAtE6KoSigztI39NrtKRsnosZoBMNZS/JG1CLt VdZPvkHVuiVQWEGYgswBEMGXoR7jtzVNhHr2F1atoBICJVGWFNA8fHvQRLAcXWJTXhKxb2uSq9Yp kKaZPZ6rrp88qtemvwVnQKE9r3/iPFeTARY7AQIDAQABo4ICdTCCAnEwDAYDVR0TAQH/BAIwADAd BgNVHQ4EFgQUgizwG0IeMZQlCSduLVeM1zDBdUEwgdwGA1UdIwSB1DCB0YAUnl/d5VPBMWkpTdWW l8Xzj4doh06hgbWkgbIwga8xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVj ZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMzAxBgNVBAMTKlRydXN0 ZWQgSW50cm9kdWNlciAoVEkpIFRvcGxldmVsIENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FA dHJ1c3RlZC1pbnRyb2R1Y2VyLm5sggECMCMGA1UdEgQcMBqBGGNhQHRydXN0ZWQtaW50cm9kdWNl ci5ubDAdBgNVHREEFjAUgRJvbmRyZWouc3VyeUBuaWMuY3owCwYDVR0PBAQDAgSwMCcGA1UdJQQg MB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwEQYJYIZIAYb4QgEBBAQDAgSwMIHVBgNV HR8Egc0wgcowY6BhoF+GXWh0dHA6Ly9jcmwxLnRydXN0ZWQtaW50cm9kdWNlci5ubC9jYS94NTA5 L2cxL2NhLXNzbC1jbGllbnQvZzEvZGF0YS9jcmxzL2NybC1jbGllbnQtY2EtMS0xLmNybDBjoGGg X4ZdaHR0cDovL2NybDIudHJ1c3RlZC1pbnRyb2R1Y2VyLm5sL2NhL3g1MDkvZzEvY2Etc3NsLWNs aWVudC9nMS9kYXRhL2NybHMvY3JsLWNsaWVudC1jYS0xLTEuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQAZP/dznHW3BWajBVQ3fTaDsx/3csUE6+jX83r1dgzYjUOmapOzXQVZ2/VTwZTzJSsD7rDgzUN6 sk6YWmUJOwqoEcPasYG9zt9e+bpwc/PURjSowb+WjEE2e4L47x3mPgL0dtlGj4guhRaj247K9N1f grvlyX0h/IL9JO4CN0I5lAuOaZ3Yfl0euHpHLlXZ9czxkc6dCbtGSZwr3RrltNmMjhp0O3D51fDd D6mG1vvOEV9Kj1JfSE2cQI5j3GpMlNleZA6noZ93drs2G9/D7WP4uVLCtJfGmG6PJsy4+qN46qXu ekJR/8WH1aNcH0Ya+JsYrwIFPwL4Cr+JXrbFqUOFMYIDzzCCA8sCAQEwgbQwga0xCzAJBgNVBAYT Ak5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBD QSAtIEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwCQYF Kw4DAhoFAKCCAe8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMw MzA2MTMwODQ5WjAjBgkqhkiG9w0BCQQxFgQUKdg9SjOgs2XvHaFpM9wEgJ8V+uYwgcUGCSsGAQQB gjcQBDGBtzCBtDCBrTELMAkGA1UEBhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAo VEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJ bnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FAdHJ1c3Rl ZC1pbnRyb2R1Y2VyLm5sAgIGSDCBxwYLKoZIhvcNAQkQAgsxgbeggbQwga0xCzAJBgNVBAYTAk5M MSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBDQSAt IEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwDQYJKoZI hvcNAQEBBQAEggEAdmUr6Sj2vh5K9973OhqPsVB0gHivp4iw+I2pacHgXfK2O/GZYPhWsIzIJthC NpkxZvEOeoO+aL2qVLjOuixVreQ+IuDpGnm0NcUd04l7nSb/DFQ3BBMS8lS1ATow0lFkcfZ2cpPA c6NVp3z4ehFCZW3G4XYMdw8MDORXlKjveFK77HNvOcmii6HP2B8E/iyVvuX8Xd5Fa/Dw11djRpe3 YAOWXgFkQMIeZMs68UzaoZnmN3WMrI+Pzun2XM1dVMl0O7xexVIGkvqKOrEEZaZWE9XGWE9IbeZ2 LHr5hFUDvDN4EFrYgM+Og2D1ITrg4vnKbZ0whrQBEyh7r6pflpculwAAAAAAAA== --Apple-Mail=_72C8A045-B0ED-4C19-8F14-D1DE1D5AC20F-- From ondrej.sury@nic.cz Wed Mar 6 05:18:59 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C17E21F84CC for ; Wed, 6 Mar 2013 05:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ai4c+n6ATsYd for ; Wed, 6 Mar 2013 05:18:59 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DB27221F84B7 for ; Wed, 6 Mar 2013 05:18:58 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:c4e8:4667:96d2:eff6] (unknown [IPv6:2001:1488:ac14:1400:c4e8:4667:96d2:eff6]) by mail.nic.cz (Postfix) with ESMTPSA id 3C25F13F66A for ; Wed, 6 Mar 2013 14:18:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1362575938; bh=sjp5ic5jEM70uqfF9Pw1kINnMm4yiMIXoGOxqStfGN4=; h=From:Content-Type:Message-Id:Mime-Version:Subject:Date:References: To:In-Reply-To; b=vPPy8LNZKIOaXUUmnk8RaB8/qIBNpfNU4vpejzHt8TQIx+cERtbZnT1WfWUM2le8/ S6yuGZcZwkKrR96sbdbRglTORNaGT5FlRCiPUcJ5YyHIoaO6LJR1z9A2Rly8MvHW+i 9IgLMXh0bH8JcfFMxuURBgMXNndBvtF4ibcJSfhQ= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: multipart/signed; boundary="Apple-Mail=_18313B9F-EA3A-4BEA-A782-370DE9D04A58"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Wed, 6 Mar 2013 14:18:57 +0100 References: <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130305182925.GQ29992@mournblade.imrryr.org> <20130305184549.GQ17663@mx1.yitter.info> <20130305190914.GR29992@mournblade.imrryr.org> <20130305192100.GR17663@mx1.yitter.info> <20130305200007.GS29992@mournblade.imrryr.org> <20130305222918.GB18073@mx1.yitter.info> <20130306000952.GW29992@mournblade.imrryr.org> To: dane@ietf.org In-Reply-To: <20130306000952.GW29992@mournblade.imrryr.org> X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 13:18:59 -0000 --Apple-Mail=_18313B9F-EA3A-4BEA-A782-370DE9D04A58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 6. 3. 2013, at 1:09, Viktor Dukhovni = wrote: > If there is still any opportunity to reconsider the issue, please > examine my suggested interpretation on its merit. I don't think there is still the opportunity to reconsider this within = existing DANE protocol. What we might do in the future: - define new types (like the one for bare SPKI) - obsolete old types But if we want to keep our sanity, we should keep to only one = interpretation of existing types. No matter how hard you push and how = many times you repeat your position (you already did too many times). Don't get me wrong, I am literally jumping from a joy that Postfix will = have DANE support. That's what we are all waiting for, but there's one = good thing the standards and their uniform interpretation is good for = =E2=80=93 the compatibility and interoperability. I cannot tell you how you should implement DANE in the Postfix and from = pure technical viewpoint your implementation ignoring names in type 1 = will make no big difference, but at least please document the = implementation differences from DANE protocol properly in the Postfix = documentation. Ondrej -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- --Apple-Mail=_18313B9F-EA3A-4BEA-A782-370DE9D04A58 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMKTCCBgYw ggTuoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwga8xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVz dGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMzAx BgNVBAMTKlRydXN0ZWQgSW50cm9kdWNlciAoVEkpIFRvcGxldmVsIENBIC0gRzAwMTEnMCUGCSqG SIb3DQEJARYYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMB4XDTA0MTIwNzEwMzYxN1oXDTMwMTIw NjAwMDAwMFowga0xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJ KTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50 cm9kdWNlciAoVEkpIENsaWVudCBDQSAtIEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQt aW50cm9kdWNlci5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOKQxMR3KDUpfJBz AhY2BPCByKo9SMp/V0RIboLBD6vO0miSYO9FmP3Q07OKPYR5WdlQyrpKqB1zl0SRz2cDjnYkzvDF vK5kvMvlTYeQlHypQlvhkTsYWD4ZZxxEhAYBb1s7cYaIahLw6H/RZz+kyWTOc9TncPBvBWIQ1Ypo S+uQqpopH8s5ebtB/17SbUty5yXiHoaPh/ScdMKqxbyJiL0YRM6SU4YX4HVZ5YGS9aWuiUSiA0YF 8dCR56nErx67wgq8O1GtsSKKOf/ueUxSmrqwgQNlfM9Or5O8kb61s1O2iACHtixoV3ENanylBafU mRYpNo5tSZsElGfntMoGBy8CAwEAAaOCAiswggInMB0GA1UdDgQWBBSeX93lU8ExaSlN1ZaXxfOP h2iHTjCB3AYDVR0jBIHUMIHRgBRdbehwJx/8iwlxnguJECc7MUXvoqGBtaSBsjCBrzELMAkGA1UE BhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAoVEkpMSAwHgYDVQQLExdDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTEzMDEGA1UEAxMqVHJ1c3RlZCBJbnRyb2R1Y2VyIChUSSkgVG9wbGV2 ZWwgQ0EgLSBHMDAxMScwJQYJKoZIhvcNAQkBFhhjYUB0cnVzdGVkLWludHJvZHVjZXIubmyCAQAw DwYDVR0TAQH/BAUwAwEB/zAjBgNVHRIEHDAagRhjYUB0cnVzdGVkLWludHJvZHVjZXIubmwwgasG A1UdHwSBozCBoDBOoEygSoZIaHR0cDovL2NybDEudHJ1c3RlZC1pbnRyb2R1Y2VyLm5sL2NhL3g1 MDkvZzEvZGF0YS9jcmxzL2NybC1yb290LWNhLTEuY3JsME6gTKBKhkhodHRwOi8vY3JsMi50cnVz dGVkLWludHJvZHVjZXIubmwvY2EveDUwOS9nMS9kYXRhL2NybHMvY3JsLXJvb3QtY2EtMS5jcmww IwYDVR0RBBwwGoEYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMAsGA1UdDwQEAwIBBjARBglghkgB hvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEFBQADggEBAI1sC2l8st3ElC74az6gH7tGXSiS7jicpHeI 10A3KY+7OEPT7BAJDpjMXxSvAwU1vBDFfwEAXGj42xAPB6cynOTDn0OiFpYGvi3EZV3khXYkGPLs fxZttUyDKqhXcWYy4nnI3fBxqCgLboJFw6OO/SVj5qQdXMZ7VhyFBWJMQkVOnlt6i3xFkG3O5LMI BDmdL5bZPEe8b6bJkMr+rUYEvorPJmV+CkiewYMaruCbdhwRkpkhXB3qLwB2ppnKxSinAU4f9Rcp p73h8iDVQ9389iliUKomVQqj9NJv2G6SyJdDQdN2vrldLszNpw6t+zIzCjpgQ//kem5BJ1k4YG3L CpAwggYbMIIFA6ADAgECAgIGSDANBgkqhkiG9w0BAQUFADCBrTELMAkGA1UEBhMCTkwxIDAeBgNV BAoTF1RydXN0ZWQgSW50cm9kdWNlciAoVEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJbnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEn MCUGCSqGSIb3DQEJARYYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMB4XDTEyMDgwMTA3NTEyNloX DTE0MDgwMTA3NTEyNlowejELMAkGA1UEBhMCTkwxGzAZBgNVBAoTElRydXN0ZWQgSW50cm9kdWNl cjEVMBMGA1UECxMMQ1ouTklDLUNTSVJUMRQwEgYDVQQDEwtPbmRyZWogU3VyeTEhMB8GCSqGSIb3 DQEJARYSb25kcmVqLnN1cnlAbmljLmN6MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA xlmN+hSg6RxWm1X6QOI3OXHSAqhRzWGb8ismR2+3LGDS640luS8x4VdWo490Ceqz+BZvMhQJwfny 9mb0IejFpx7kBOM7k2rMfOYUXa/pq07ysWEI8bXDcXRBf2ZcG0B/gajLPFA9MADlCWHSf7cNZF6S XnIHwTn5DowxpbF403NqLWFnTM08wTJkFgGB7WZAtE6KoSigztI39NrtKRsnosZoBMNZS/JG1CLt VdZPvkHVuiVQWEGYgswBEMGXoR7jtzVNhHr2F1atoBICJVGWFNA8fHvQRLAcXWJTXhKxb2uSq9Yp kKaZPZ6rrp88qtemvwVnQKE9r3/iPFeTARY7AQIDAQABo4ICdTCCAnEwDAYDVR0TAQH/BAIwADAd BgNVHQ4EFgQUgizwG0IeMZQlCSduLVeM1zDBdUEwgdwGA1UdIwSB1DCB0YAUnl/d5VPBMWkpTdWW l8Xzj4doh06hgbWkgbIwga8xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVj ZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMzAxBgNVBAMTKlRydXN0 ZWQgSW50cm9kdWNlciAoVEkpIFRvcGxldmVsIENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FA dHJ1c3RlZC1pbnRyb2R1Y2VyLm5sggECMCMGA1UdEgQcMBqBGGNhQHRydXN0ZWQtaW50cm9kdWNl ci5ubDAdBgNVHREEFjAUgRJvbmRyZWouc3VyeUBuaWMuY3owCwYDVR0PBAQDAgSwMCcGA1UdJQQg MB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwEQYJYIZIAYb4QgEBBAQDAgSwMIHVBgNV HR8Egc0wgcowY6BhoF+GXWh0dHA6Ly9jcmwxLnRydXN0ZWQtaW50cm9kdWNlci5ubC9jYS94NTA5 L2cxL2NhLXNzbC1jbGllbnQvZzEvZGF0YS9jcmxzL2NybC1jbGllbnQtY2EtMS0xLmNybDBjoGGg X4ZdaHR0cDovL2NybDIudHJ1c3RlZC1pbnRyb2R1Y2VyLm5sL2NhL3g1MDkvZzEvY2Etc3NsLWNs aWVudC9nMS9kYXRhL2NybHMvY3JsLWNsaWVudC1jYS0xLTEuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQAZP/dznHW3BWajBVQ3fTaDsx/3csUE6+jX83r1dgzYjUOmapOzXQVZ2/VTwZTzJSsD7rDgzUN6 sk6YWmUJOwqoEcPasYG9zt9e+bpwc/PURjSowb+WjEE2e4L47x3mPgL0dtlGj4guhRaj247K9N1f grvlyX0h/IL9JO4CN0I5lAuOaZ3Yfl0euHpHLlXZ9czxkc6dCbtGSZwr3RrltNmMjhp0O3D51fDd D6mG1vvOEV9Kj1JfSE2cQI5j3GpMlNleZA6noZ93drs2G9/D7WP4uVLCtJfGmG6PJsy4+qN46qXu ekJR/8WH1aNcH0Ya+JsYrwIFPwL4Cr+JXrbFqUOFMYIDzzCCA8sCAQEwgbQwga0xCzAJBgNVBAYT Ak5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBD QSAtIEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwCQYF Kw4DAhoFAKCCAe8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMw MzA2MTMxODU4WjAjBgkqhkiG9w0BCQQxFgQUrD1W6gGZKC6VFxqXLz512lWJwYEwgcUGCSsGAQQB gjcQBDGBtzCBtDCBrTELMAkGA1UEBhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAo VEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJ bnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FAdHJ1c3Rl ZC1pbnRyb2R1Y2VyLm5sAgIGSDCBxwYLKoZIhvcNAQkQAgsxgbeggbQwga0xCzAJBgNVBAYTAk5M MSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBDQSAt IEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwDQYJKoZI hvcNAQEBBQAEggEAVHcociXfWcjg02673+/eiCHgx/y64bcnwcOm3vlMXYUo9mE8IsR4qrB2GmLU cDv+q5cT3y02/XYy8rVj2WK2+lce2EJJeFArGYKq3XFd4B6LCw/K0xsgXm7eGslQ6ZMuttJvM6jF aqi7K6/ZrPdxgd3fwLWZ6NyF1gi1jyBKhbW6Ab4y9eHQLTjU+S9tVGpWFEiC7f9XMyvISqxxIsyp tsK4+WPe6Fb7N9k9nn9wOvOxsLbgEwxyuIPsM92gx4D+5qvIl793WsMkNOs35DDLB8LBAUQN3KLK Fxi6OTq/kYDmMQS8wULcED3/50iyC7UXl7s9h/l/htsWxJbCjZPZ2gAAAAAAAA== --Apple-Mail=_18313B9F-EA3A-4BEA-A782-370DE9D04A58-- From paul@cypherpunks.ca Wed Mar 6 06:49:02 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A1621F84F7 for ; Wed, 6 Mar 2013 06:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESK6u6Us8UK9 for ; Wed, 6 Mar 2013 06:49:02 -0800 (PST) Received: from mx.nohats.ca (unknown [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 41E5721F84D6 for ; Wed, 6 Mar 2013 06:49:01 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZLdCG14xTz9d6; Wed, 6 Mar 2013 09:48:58 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wX406HDOhjw3; Wed, 6 Mar 2013 09:48:56 -0500 (EST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 6 Mar 2013 09:48:56 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 7A1E780D39; Wed, 6 Mar 2013 09:48:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6F8478043D; Wed, 6 Mar 2013 09:48:57 -0500 (EST) Date: Wed, 6 Mar 2013 09:48:57 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list , Viktor Dukhovni In-Reply-To: <20130305061146.GP29992@mournblade.imrryr.org> Message-ID: References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 14:49:03 -0000 On Tue, 5 Mar 2013, Viktor Dukhovni wrote: > Not all applications understand wildcard certificates, or even > correctly parse certificate content. > > When the Moxie Marlinspike embedded NUL attack on CA name bindings > was published, Postfix was one the few applications not impacted, > since I already anticipated this problem and Postfix already had > checks for embedded NULs in ASN.1 strings. > > The moral of this anecdote is not that the Postfix developers go > the extra mile, but rather that X.509 is a very complex standard > with many pitfalls, and anything that makes the application's job > easier is a big win. > > The easiest way to check that you have the right certificate is to > not parse it at all, or parse it just enough to extract the public > key (this is generally directly supported by the SSL toolkit), and > then just compare that or a digest of it to the value bound by DANE. > > The simplicity of the DANE binding leaves PKIX with its horde of > trust anchors, local versions of intermediate certs, servers that > fail to present all intermediate certs, depth limits, expiration > date arithmetic, name constraints, multitudes of name types, > critical extensions, ... in the dust. While I agree with most, the future to do this right is to use TLS with raw public keys: http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-07 That creates a "certificate" with just the SubjectPublicKeyInfo blob. I welcome postfix to be an early adopter of that draft :) Paul From viktor1dane@dukhovni.org Wed Mar 6 09:20:05 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC0421F8732 for ; Wed, 6 Mar 2013 09:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[AWL=0.868, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBlgsRGD4fjC for ; Wed, 6 Mar 2013 09:20:04 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 4B48721F88E2 for ; Wed, 6 Mar 2013 09:20:03 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 805232AB64D; Wed, 6 Mar 2013 17:20:02 +0000 (UTC) Date: Wed, 6 Mar 2013 17:20:02 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130306172002.GD29992@mournblade.imrryr.org> References: <43ABB2C5-0B0E-44A1-88BF-9E9714A0369F@vpnc.org> <20130305041432.C17A91A5F4@ld9781.wdf.sap.corp> <20130305055935.GO29992@mournblade.imrryr.org> <54ABCDF9-52E3-41C8-A1C5-6D387DFB5746@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54ABCDF9-52E3-41C8-A1C5-6D387DFB5746@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:20:05 -0000 On Wed, Mar 06, 2013 at 02:08:48PM +0100, Ond?ej Sur? wrote: > If you want to be compatible with DANE, I would suggest to > implement the protocol as is, pretty please. The implementation will be fully *interoperable* with DANE as specified. The Postfix SMTP client will however be more liberal than the spec in its interpretation of certificate usages 0 and 1. Specifically: - 0 will be read as 2 with a "CA constraint" interpreted as a "trust anchor assertion". - 1 will be read as 3 with a "service certificate constraint" interpreted as a "domain issued certificate". - No trust-chain validation will be performed above the trust anchor in the conflated 0/2, or at all in the conflated 1/3. - MTA administrators will be strongly encouraged to publish "TLSA 3 1 1" RRs in preference to any other kind. This eliminates most opportunities for failure with no reduction in security. I would like to see this best-practice advice in draft-ietf-dane-smtp, and any final resulting RFC. The working group will I hope understand that in some application areas considerations beyond the literal text of the DANE RFC may dictate similar choices, and that as a practical matter it is important to not erect needlessly high adoption barriers when the cost of absolute RFC adherence is high, and the benefit is low or absent. The above decisions will be clearly documented, together with a detailed rationale. They will not cause any interoperability issues, and will eliminate many opportunities for mail delivery between sites failing for avoidable reasons, including: - Some over-worked and under-trained sysadmin assumes that his issuing public CA is on everyone's list of trusted public CAs. Browser users can click-through the warnings, but sending MTAs are not interactive applications and mail delivery will fail. - Some over-worked and under-trained sysadmin configures a trust chain that includes only the leaf certificate without intermediates. They specify "TLSA 1 x y" in DANE, but mail delivery fails because the sending MTA can't do the PKIX check. - Some over-worked and under-trained (Azure cloud?) sysadmin forgets to renew a certificate that is published as "TLSA 1 x y" in DANE. ... Of course some similar and related problems will remain, most notably failure to re-sign a DNSSEC zone in a timely manner and dropping off the Internet for all DNSSEC-aware recursive resolvers. Stil, on the whole DANE adoption will go much more smoothly without avoidable service disruption barriers. As you've all tired of hearing by now, in the case of MTA to MTA traffic, given indirection through DNS MX records, the security of DNSSEC is an unavoidable foundation with no opportunity for CAs to provide an additional *independent* validity assertion. The best that CAs can do is provide revocation support, but the code and operational cost of implementing this in an MTA is prohibitive. So PKIX public root CAs do not add any value beyond serving as potential trust anchors in a "TLSA 2 x y" or "TLSA 0 x y" RR. A non sado-masochist MTA developer will not subject his users to frequent avoidable outages and himself to a flood of "the MTA is broken" help requests just to adhere to the letter of an RFC when adhering only to its essential elements will not expose users to any new risk. Widespread DANE adoption would be a giant leap forward in email security, let's hope DANE is a sufficient carrot to encourage users to endure the pain of deploying DNSSEC. > (On the other hand, the existing MTA implementations don't give > a damn about existing standards, so it will be status quo anyway.) [ Note to self: don't feed the trolls. ] -- Viktor. From paul@cypherpunks.ca Wed Mar 6 09:44:45 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8EF21F8AC2 for ; Wed, 6 Mar 2013 09:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9puhA0zTY6GW for ; Wed, 6 Mar 2013 09:44:44 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 825C521F887D for ; Wed, 6 Mar 2013 09:44:41 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZLj5x5xKCz9dR; Wed, 6 Mar 2013 12:44:37 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id XH7VneVPhHgf; Wed, 6 Mar 2013 12:44:36 -0500 (EST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 6 Mar 2013 12:44:36 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 21B9E80D39; Wed, 6 Mar 2013 12:44:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 156D7804F3; Wed, 6 Mar 2013 12:44:37 -0500 (EST) Date: Wed, 6 Mar 2013 12:44:37 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= In-Reply-To: <54ABCDF9-52E3-41C8-A1C5-6D387DFB5746@nic.cz> Message-ID: References: <43ABB2C5-0B0E-44A1-88BF-9E9714A0369F@vpnc.org> <20130305041432.C17A91A5F4@ld9781.wdf.sap.corp> <20130305055935.GO29992@mournblade.imrryr.org> <54ABCDF9-52E3-41C8-A1C5-6D387DFB5746@nic.cz> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-2 Content-Transfer-Encoding: 8BIT Cc: dane WG list Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:44:45 -0000 On Wed, 6 Mar 2013, Ondøej Surý wrote: > If you want to be compatible with DANE, I would suggest to implement the protocol as is, pretty please. But since HASTLS seems dead, please interpret "TLSA record present" as "don't deliver without TLS" *ducks* Paul From viktor1dane@dukhovni.org Wed Mar 6 10:20:27 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6968F21F8A91 for ; Wed, 6 Mar 2013 10:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tlh37yjGaPqF for ; Wed, 6 Mar 2013 10:20:23 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 1C10921F8A54 for ; Wed, 6 Mar 2013 10:20:20 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DCE6B2AB64D; Wed, 6 Mar 2013 18:20:17 +0000 (UTC) Date: Wed, 6 Mar 2013 18:20:17 +0000 From: Viktor Dukhovni To: dane WG list Message-ID: <20130306182017.GE29992@mournblade.imrryr.org> References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] oob-pubkey and Postfix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 18:20:27 -0000 On Wed, Mar 06, 2013 at 09:48:57AM -0500, Paul Wouters wrote: > >The simplicity of the DANE binding leaves PKIX with its horde of > >trust anchors, local versions of intermediate certs, servers that > >fail to present all intermediate certs, depth limits, expiration > >date arithmetic, name constraints, multitudes of name types, > >critical extensions, ... in the dust. > > While I agree with most, the future to do this right is to use TLS with > raw public keys: > > http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-07 > > That creates a "certificate" with just the SubjectPublicKeyInfo blob. > > I welcome postfix to be an early adopter of that draft :) This is very unlikely to be implemented in Postfix. It is predicated on an API change in OpenSSL to allow it to return bare public keys for the peer certificate. Users will still need to generate and configure X.509 certificates, and there is very little upside for this proposal in existing applications that don't start life as public-key only TLS applications. For the forseeable future, it is much more practical to just create minimal certificates that essentially consist of just the public key. With ECDSA and SHA256 the DER cert is just 275 bytes vs. 91 bytes for the associated public key. While an extra 184 (less overhead for the new extension) bytes on the wire could be avoided it sure is a lot of new code in libraries and applications to save a small amount of extra packet payload. Example via bash(1) with its subprocess file-descriptor arguments: $ ( umask 077; tmp=$(mktemp .pem.XXXXXX); dst=cert+key.pem openssl req -new >> $tmp \ -newkey param:<(openssl ecparam -name prime256v1) \ -nodes -keyout /dev/stdout \ -x509 -sha256 -set_serial 1 -subj "/" -days 3650 -config <( printf "[req]\n%s\n%s\n[dn]\n[x509]\n%s\n" \ "distinguished_name=dn" "x509_extensions=x509" \ "extendedKeyUsage=serverAuth,clientAuth") && mv $tmp "$dst" && openssl x509 -in "$dst" -text | tee /dev/tty | openssl x509 -outform DER | wc -c && openssl pkey -in "$dst" -pubout | tee /dev/tty | openssl pkey -pubin -outform DER | wc -c ) Generating a 256 bit EC private key writing new private key to '/dev/stdout' ----- Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: ecdsa-with-SHA256 Issuer: Validity Not Before: Mar 6 18:14:15 2013 GMT Not After : Mar 4 18:14:15 2023 GMT Subject: Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:be:d4:d6:18:d0:6a:55:b2:17:1f:53:18:02:a6: 47:c1:f1:10:bb:df:a8:04:12:6b:f7:4b:b9:a7:21: 97:83:31:c4:78:84:c1:9d:be:b5:16:09:0d:b5:04: f6:92:99:92:3a:e3:1d:2d:62:48:17:08:47:c1:05: 43:ad:d2:3f:61 ASN1 OID: prime256v1 X509v3 extensions: X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication Signature Algorithm: ecdsa-with-SHA256 30:45:02:20:6c:5f:21:3c:c6:09:c6:09:7b:07:55:da:94:4d: 16:0a:f8:7b:99:20:51:54:30:c3:48:87:43:45:0c:08:e1:00: 02:21:00:d8:2d:39:9d:08:7d:5f:22:ab:db:2e:3a:d2:ff:1d: 1e:73:bc:88:45:77:58:64:24:ea:c7:9f:b0:0e:97:be:41 -----BEGIN CERTIFICATE----- MIIBDzCBtqADAgECAgEBMAoGCCqGSM49BAMCMAAwHhcNMTMwMzA2MTgxNDE1WhcN MjMwMzA0MTgxNDE1WjAAMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEvtTWGNBq VbIXH1MYAqZHwfEQu9+oBBJr90u5pyGXgzHEeITBnb61FgkNtQT2kpmSOuMdLWJI FwhHwQVDrdI/YaMhMB8wHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAoG CCqGSM49BAMCA0gAMEUCIGxfITzGCcYJewdV2pRNFgr4e5kgUVQww0iHQ0UMCOEA AiEA2C05nQh9XyKr2y460v8dHnO8iEV3WGQk6sefsA6XvkE= -----END CERTIFICATE----- 275 -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEvtTWGNBqVbIXH1MYAqZHwfEQu9+o BBJr90u5pyGXgzHEeITBnb61FgkNtQT2kpmSOuMdLWJIFwhHwQVDrdI/YQ== -----END PUBLIC KEY----- 91 -- Viktor. From viktor1dane@dukhovni.org Wed Mar 6 10:27:54 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F7221F841C for ; Wed, 6 Mar 2013 10:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1F61WqVqJ5+f for ; Wed, 6 Mar 2013 10:27:54 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id BC98721F84CE for ; Wed, 6 Mar 2013 10:27:47 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6FA982AB64D; Wed, 6 Mar 2013 18:27:47 +0000 (UTC) Date: Wed, 6 Mar 2013 18:27:47 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130306182747.GF29992@mournblade.imrryr.org> References: <43ABB2C5-0B0E-44A1-88BF-9E9714A0369F@vpnc.org> <20130305041432.C17A91A5F4@ld9781.wdf.sap.corp> <20130305055935.GO29992@mournblade.imrryr.org> <54ABCDF9-52E3-41C8-A1C5-6D387DFB5746@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] unusable TLSA records and the death of HASTLS? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 18:27:54 -0000 On Wed, Mar 06, 2013 at 12:44:37PM -0500, Paul Wouters wrote: > On Wed, 6 Mar 2013, Ond?ej Sur? wrote: > > >If you want to be compatible with DANE, I would suggest to implement > >the protocol as is, pretty please. > > But since HASTLS seems dead, please interpret "TLSA record present" as > "don't deliver without TLS" > > *ducks* No need to duck, if DNSSEC serves-up usable TLSA records, then indeed Postfix won't deliver without TLS. If *all* the records are malformed or use unsupported parameters, then my reading of DANE 6698 is that one should behave as though no TLSA records were present. This is based on 6698 #4.1: If an application receives zero usable certificate associations from a DNS request or from its cache, it processes TLS in the normal fashion without any input from the TLSA records. If an application receives one or more usable certificate associations, it attempts to match each certificate association with the TLS server's end entity certificate until a successful match is found. During the TLS handshake, if none of the certificate associations matches the certificate given by the TLS server, the TLS client MUST abort the handshake. Are you saying that an RRset consisting entirely of unusable TLSA records should force TLS (to always fail)? -- Viktor. From paul@cypherpunks.ca Wed Mar 6 11:47:06 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4483521F879D for ; Wed, 6 Mar 2013 11:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82jjB7m0NlSC for ; Wed, 6 Mar 2013 11:47:05 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCC521F84A1 for ; Wed, 6 Mar 2013 11:47:05 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZLlq960fxz9dc for ; Wed, 6 Mar 2013 14:47:01 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id cF88gcYyX3nk for ; Wed, 6 Mar 2013 14:47:00 -0500 (EST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP for ; Wed, 6 Mar 2013 14:47:00 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 3162680D39; Wed, 6 Mar 2013 14:47:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 293E1804F3 for ; Wed, 6 Mar 2013 14:47:01 -0500 (EST) Date: Wed, 6 Mar 2013 14:47:01 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list In-Reply-To: <20130306182017.GE29992@mournblade.imrryr.org> Message-ID: References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130306182017.GE29992@mournblade.imrryr.org> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [dane] oob-pubkey and Postfix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 19:47:06 -0000 On Wed, 6 Mar 2013, Viktor Dukhovni wrote: >> That creates a "certificate" with just the SubjectPublicKeyInfo blob. >> >> I welcome postfix to be an early adopter of that draft :) > > This is very unlikely to be implemented in Postfix. It is predicated > on an API change in OpenSSL to allow it to return bare public keys > for the peer certificate. Users will still need to generate and > configure X.509 certificates, and there is very little upside for > this proposal in existing applications that don't start life as > public-key only TLS applications. Why are you suddenly switching the argument? If you want a protocol that is not encumbered by obsolete X509 mappings, you're going to need some API changes. > For the forseeable future, it is much more practical to just create > minimal certificates that essentially consist of just the public > key. With ECDSA and SHA256 the DER cert is just 275 bytes vs. 91 > bytes for the associated public key. While an extra 184 (less > overhead for the new extension) bytes on the wire could be avoided > it sure is a lot of new code in libraries and applications to save > a small amount of extra packet payload. Size was not the problem you were talking about. Problem was the conflicting information between certificate content and DNS bindings to name, ttl etc. This draft enables you a valid way out of your issue. Neither one of us was talking about packet size or code size. If you don't want conflicting X509 information in DNS, then the best way out is to not have that information in the X509 certificate. Paul From paul@cypherpunks.ca Wed Mar 6 11:53:04 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E3C21F8837 for ; Wed, 6 Mar 2013 11:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XBX5BQoSBa9 for ; Wed, 6 Mar 2013 11:53:03 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCB521F8934 for ; Wed, 6 Mar 2013 11:52:37 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZLlxY2Hv3z9dc for ; Wed, 6 Mar 2013 14:52:33 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id qyWI0SJln42t for ; Wed, 6 Mar 2013 14:52:32 -0500 (EST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP for ; Wed, 6 Mar 2013 14:52:32 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 1331F80D39; Wed, 6 Mar 2013 14:52:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 06FB8804F3 for ; Wed, 6 Mar 2013 14:52:32 -0500 (EST) Date: Wed, 6 Mar 2013 14:52:31 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list In-Reply-To: <20130306182747.GF29992@mournblade.imrryr.org> Message-ID: References: <43ABB2C5-0B0E-44A1-88BF-9E9714A0369F@vpnc.org> <20130305041432.C17A91A5F4@ld9781.wdf.sap.corp> <20130305055935.GO29992@mournblade.imrryr.org> <54ABCDF9-52E3-41C8-A1C5-6D387DFB5746@nic.cz> <20130306182747.GF29992@mournblade.imrryr.org> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [dane] unusable TLSA records and the death of HASTLS? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 19:53:04 -0000 On Wed, 6 Mar 2013, Viktor Dukhovni wrote: >> But since HASTLS seems dead, please interpret "TLSA record present" as >> "don't deliver without TLS" >> >> *ducks* > > No need to duck I was ducking for other people :) > , if DNSSEC serves-up usable TLSA records, then > indeed Postfix won't deliver without TLS. And that is what the majority did not want the specification to mean. They wanted the "is TLS mandatory for this connection or not" to be signaled with a separate record, the draft had HASTLS. However, that draft hasn't moved at all in over a year, and I am personally in favour of using the presence of a TLSA record to mean "do not contact without TLS". > If *all* the records are > malformed or use unsupported parameters, then my reading of DANE > 6698 is that one should behave as though no TLSA records were > present. This is based on 6698 #4.1: > > If an application receives zero usable certificate associations from > a DNS request or from its cache, it processes TLS in the normal > fashion without any input from the TLSA records. If an application > receives one or more usable certificate associations, it attempts to > match each certificate association with the TLS server's end entity > certificate until a successful match is found. During the TLS > handshake, if none of the certificate associations matches the > certificate given by the TLS server, the TLS client MUST abort the > handshake. > > Are you saying that an RRset consisting entirely of unusable TLSA > records should force TLS (to always fail)? That section does not talk about whether or not to use non-TLS. It only talks about "if you want to do TLS and you find one or more TLSA records". It does not talk about "should we connect using TLS or without?" Paul From viktor1dane@dukhovni.org Wed Mar 6 11:58:05 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DDC21F89AA for ; Wed, 6 Mar 2013 11:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Sr-2wyUwTZK for ; Wed, 6 Mar 2013 11:58:05 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id E05FF21F84EF for ; Wed, 6 Mar 2013 11:58:04 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 198812AB64D; Wed, 6 Mar 2013 19:58:04 +0000 (UTC) Date: Wed, 6 Mar 2013 19:58:04 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130306195803.GH29992@mournblade.imrryr.org> References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130306182017.GE29992@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] oob-pubkey and Postfix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 19:58:05 -0000 On Wed, Mar 06, 2013 at 02:47:01PM -0500, Paul Wouters wrote: > >This is very unlikely to be implemented in Postfix. It is predicated > >on an API change in OpenSSL to allow it to return bare public keys > >for the peer certificate. Users will still need to generate and > >configure X.509 certificates, and there is very little upside for > >this proposal in existing applications that don't start life as > >public-key only TLS applications. > > Why are you suddenly switching the argument? If you want a protocol that > is not encumbered by obsolete X509 mappings, you're going to need > some API changes. I don't want to *depend* on complex certificate properties for security. Their presence in the certificate does not bother me. If I match a peer by the certificate or public key digest, ignoring all extensions, names, ... I don't really care whether that key was encapsulated inside an ASN.1 sequence of some additional useless information. Changing the Postfix code to depend as yet unreleased OpenSSL APIs that users won't have for a long time, and TLS extensions that may trigger interoperability problems just does not look that appealing. > >For the forseeable future, it is much more practical to just create > >minimal certificates that essentially consist of just the public > >key. With ECDSA and SHA256 the DER cert is just 275 bytes vs. 91 > >bytes for the associated public key. While an extra 184 (less > >overhead for the new extension) bytes on the wire could be avoided > >it sure is a lot of new code in libraries and applications to save > >a small amount of extra packet payload. > > Size was not the problem you were talking about. Problem was the > conflicting information between certificate content and DNS bindings > to name, ttl etc. This draft enables you a valid way out of your issue. There is no conflicting information when the content of the certificate (other than perhaps the public key) is simply ignored. All I see is a pile of bits. Sorry if this is disappointing, but for now the cost/benefit ratio for oob-pubkey is too high. -- Viktor. From viktor1dane@dukhovni.org Wed Mar 6 12:11:55 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B59511E809C for ; Wed, 6 Mar 2013 12:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMX74Sk6ZQh1 for ; Wed, 6 Mar 2013 12:11:51 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id A61B911E80DF for ; Wed, 6 Mar 2013 12:11:48 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 555072AB64D; Wed, 6 Mar 2013 20:11:48 +0000 (UTC) Date: Wed, 6 Mar 2013 20:11:48 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130306201148.GI29992@mournblade.imrryr.org> References: <43ABB2C5-0B0E-44A1-88BF-9E9714A0369F@vpnc.org> <20130305041432.C17A91A5F4@ld9781.wdf.sap.corp> <20130305055935.GO29992@mournblade.imrryr.org> <54ABCDF9-52E3-41C8-A1C5-6D387DFB5746@nic.cz> <20130306182747.GF29992@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] unusable TLSA records and the death of HASTLS? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 20:11:55 -0000 On Wed, Mar 06, 2013 at 02:52:31PM -0500, Paul Wouters wrote: > >>*ducks* > > > >No need to duck > > I was ducking for other people :) > > >, if DNSSEC serves-up usable TLSA records, then > >indeed Postfix won't deliver without TLS. > > And that is what the majority did not want the specification to mean. > They wanted the "is TLS mandatory for this connection or not" to be > signaled with a separate record, the draft had HASTLS. However, that > draft hasn't moved at all in over a year, and I am personally in favour > of using the presence of a TLSA record to mean "do not contact without > TLS". Perhaps this has changed: https://tools.ietf.org/html/draft-ietf-dane-srv-02#section-3.2 https://tools.ietf.org/html/draft-ietf-dane-smtp-01#section-3 Both say that TLS is mandatory when "secure" TLSA records are present even if unusable! Based on this, Postfix will do mandatory TLS in this case, but without PKIX validation, providing the usual (for MTAs) protection from passive eavesdropping. The legacy public CA PKI simply does not work well enough for MTAs to be broadly useful. Thanks for bringing my attention to this issue. -- Viktor. From jakob@kirei.se Wed Mar 6 13:54:25 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9287F11E817B for ; Wed, 6 Mar 2013 13:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+7M2hxtymrA for ; Wed, 6 Mar 2013 13:54:24 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 3E75511E8155 for ; Wed, 6 Mar 2013 13:54:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer; bh=lf37NkGfZy3h3JNjOoPJCS/Bxn300f8B4GRoYGdAv+c=; b=mGsCqMbMYUA6b7AgZGYdmGDQTuq9wZI+xBo5/HBCy8yY5FocDJqlMad14cKKbWKP0BxfeQtXegUCr CPZkFO4XhID9BMKLQk1ZXuE/1Kprh5VNGZv070oyxJFEbxXGG0gbtlk7r2qxFxUOQ5t5RXJinHdCbN xHWNr7K1225jctVQ= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Wed, 6 Mar 2013 22:54:21 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jakob Schlyter In-Reply-To: <20130306182017.GE29992@mournblade.imrryr.org> Date: Wed, 6 Mar 2013 22:54:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <79B11932-0508-4EEE-98AE-32417E7D2A0A@kirei.se> References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130306182017.GE29992@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1499) Subject: Re: [dane] oob-pubkey and Postfix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 21:54:25 -0000 On 6 mar 2013, at 19:20, Viktor Dukhovni = wrote: > This is very unlikely to be implemented in Postfix. It is predicated > on an API change in OpenSSL to allow it to return bare public keys > for the peer certificate. =20 FWIW, there is work going on for implementing DANE in OpenSSL. I suggest = you wait for this before moving forward. jakob From viktor1dane@dukhovni.org Wed Mar 6 15:04:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5821811E8110 for ; Wed, 6 Mar 2013 15:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnY9fS1Pi4vt for ; Wed, 6 Mar 2013 15:04:39 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1F111E80FD for ; Wed, 6 Mar 2013 15:04:36 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6BD582AB72D; Wed, 6 Mar 2013 23:04:35 +0000 (UTC) Date: Wed, 6 Mar 2013 23:04:35 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130306230435.GB29304@mournblade.imrryr.org> References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130306182017.GE29992@mournblade.imrryr.org> <79B11932-0508-4EEE-98AE-32417E7D2A0A@kirei.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79B11932-0508-4EEE-98AE-32417E7D2A0A@kirei.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] oob-pubkey and Postfix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 23:04:40 -0000 On Wed, Mar 06, 2013 at 10:54:20PM +0100, Jakob Schlyter wrote: > On 6 mar 2013, at 19:20, Viktor Dukhovni wrote: > > > This is very unlikely to be implemented in Postfix. It is predicated > > on an API change in OpenSSL to allow it to return bare public keys > > for the peer certificate. > > FWIW, there is work going on for implementing DANE in OpenSSL. Any support for DANE in OpenSSL is exceedingly unlikely to be useful to Postfix. The changes to the SSL_verify callback required to support DANE certificate usage 2 were quite easy and are already done. Postfix already has support for end-entity certificate verification. The Postfix verify callback also has to support pre-DANE administrator implemented TLS security policy (destination specific CAs, fingerprints, and matching rules). All that remains to be added is support for hybrid policies where some TLSA records provide EE cert information and other TLSA records provide TA cert information. Postfix will need a new security level which is a hybrid of "fingerprint" and "verify" matching either a set of TA certs or a set of "EE" certs. This is easy. The trickiest part will be integrating all of this with the MX resolution and connection retry logic. OpenSSL won't be of any help there. > I suggest you wait for this before moving forward. Thanks, but I'm moving ahead independently. -- Viktor. From viktor1dane@dukhovni.org Wed Mar 6 15:07:32 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D97121F8936 for ; Wed, 6 Mar 2013 15:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt7I5FGlP617 for ; Wed, 6 Mar 2013 15:07:31 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 1103411E80E0 for ; Wed, 6 Mar 2013 15:07:31 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B0FD52AB72D; Wed, 6 Mar 2013 23:07:30 +0000 (UTC) Date: Wed, 6 Mar 2013 23:07:30 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130306230730.GC29304@mournblade.imrryr.org> References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130306182017.GE29992@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] oob-pubkey and Postfix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 23:07:32 -0000 On Wed, Mar 06, 2013 at 10:55:06PM +0100, Jakob Schlyter wrote: > If you want to provide comments on the OpenSSL DANE interface, let me know. Sure just point me at the right git repo, I already have a clone of the main repo, if the code is there, all I need to know is which branch it is on. -- Viktor. From cloos@jhcloos.com Wed Mar 6 18:17:02 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB4711E80C5 for ; Wed, 6 Mar 2013 18:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exz+YR0lXV8H for ; Wed, 6 Mar 2013 18:17:01 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id 6E49B11E809C for ; Wed, 6 Mar 2013 18:17:01 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 8E8CA401FA; Thu, 7 Mar 2013 02:16:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1362622620; bh=cV3Gf4vvlNPn8KCsFTksiRKR0UOQKlM6g6pr/tMf99o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=tlo9+MpSSC8xX8YGCwfa0ufc6ggVRoGxFCDofp4Mujoatcq0R/JCbtI6CLZOWGXv6 gosbuFNCiKCY8RB0OBqJ1Co7To26MQX9OI7eGKLiwJUIm7jNtI89AHf8GstIUaAlW2 ZFEekZNEyh8+INebwSfNxXmsD0HgylUZOi/U1u6s= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 7B28E6D69B; Thu, 7 Mar 2013 02:10:44 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20130306201148.GI29992@mournblade.imrryr.org> (Viktor Dukhovni's message of "Wed, 6 Mar 2013 20:11:48 +0000") References: <43ABB2C5-0B0E-44A1-88BF-9E9714A0369F@vpnc.org> <20130305041432.C17A91A5F4@ld9781.wdf.sap.corp> <20130305055935.GO29992@mournblade.imrryr.org> <54ABCDF9-52E3-41C8-A1C5-6D387DFB5746@nic.cz> <20130306182747.GF29992@mournblade.imrryr.org> <20130306201148.GI29992@mournblade.imrryr.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 06 Mar 2013 21:10:44 -0500 Message-ID: Lines: 26 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130307:viktor1dane@dukhovni.org::zccteuAzlWik+RSs:000000000000000000000000000000000000fVOgg X-Hashcash: 1:30:130307:dane@ietf.org::6hmrGxqAKuHHKAij:000R2Kjt Cc: dane@ietf.org Subject: Re: [dane] unusable TLSA records and the death of HASTLS? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 02:17:02 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> Perhaps this has changed: VD> https://tools.ietf.org/html/draft-ietf-dane-srv-02#section-3.2 VD> https://tools.ietf.org/html/draft-ietf-dane-smtp-01#section-3 VD> Both say that TLS is mandatory when "secure" TLSA records are VD> present even if unusable! Not so much changed; the difference is that there wasn't consensus to do that for tlsa records in general, but Tony, et al propose that for those cases which use SRV or MX records. Other drafts also might propose such for their specific cases. But in the absense of such a more specific draft or rfc, 6698 on its own does not specify forcing TLS whenever a validly signed TLSA is found. Just another example where different use cases and user communities have different requirements and expectations, but still benefit from a common foundation. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From paul@cypherpunks.ca Wed Mar 6 18:56:13 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FC021F84E7 for ; Wed, 6 Mar 2013 18:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.06 X-Spam-Level: X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVT6lrNe3Rnh for ; Wed, 6 Mar 2013 18:56:13 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id DE80A21F84A2 for ; Wed, 6 Mar 2013 18:56:12 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZLxLD6t68z9jZ for ; Wed, 6 Mar 2013 21:56:04 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id cezwq4dASQlH for ; Wed, 6 Mar 2013 21:56:04 -0500 (EST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by mx.nohats.ca (Postfix) with ESMTP for ; Wed, 6 Mar 2013 21:56:03 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 9273D80D39; Wed, 6 Mar 2013 21:56:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 87C998043D for ; Wed, 6 Mar 2013 21:56:04 -0500 (EST) Date: Wed, 6 Mar 2013 21:56:04 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list In-Reply-To: <20130306195803.GH29992@mournblade.imrryr.org> Message-ID: References: <20130301165900.GB29992@mournblade.imrryr.org> <20130305002010.C321B1A5F4@ld9781.wdf.sap.corp> <20130305020017.GM29992@mournblade.imrryr.org> <20130305061146.GP29992@mournblade.imrryr.org> <20130306182017.GE29992@mournblade.imrryr.org> <20130306195803.GH29992@mournblade.imrryr.org> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [dane] oob-pubkey and Postfix X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 02:56:13 -0000 On Wed, 6 Mar 2013, Viktor Dukhovni wrote: > There is no conflicting information when the content of the > certificate (other than perhaps the public key) is simply ignored. Correct, if you ignore the conflict, then there is no conflict in your eyes. However, there is still a conflict. > Sorry if this is disappointing, but for now the cost/benefit > ratio for oob-pubkey is too high. Understood. Paul From oej@edvina.net Wed Mar 6 22:52:57 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F8421F8A6F for ; Wed, 6 Mar 2013 22:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xsLUKnuJQjU for ; Wed, 6 Mar 2013 22:52:56 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id F285D21F8904 for ; Wed, 6 Mar 2013 22:52:55 -0800 (PST) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id AC59D93DE3C; Thu, 7 Mar 2013 06:52:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 7 Mar 2013 07:52:48 +0100 Content-Transfer-Encoding: 7bit Message-Id: <4102A8D5-33E0-414F-9DD9-9C55C486B819@edvina.net> References: <43ABB2C5-0B0E-44A1-88BF-9E9714A0369F@vpnc.org> <20130305041432.C17A91A5F4@ld9781.wdf.sap.corp> <20130305055935.GO29992@mournblade.imrryr.org> <54ABCDF9-52E3-41C8-A1C5-6D387DFB5746@nic.cz> <20130306182747.GF29992@mournblade.imrryr.org> To: Paul Wouters X-Mailer: Apple Mail (2.1499) Cc: dane WG list Subject: Re: [dane] unusable TLSA records and the death of HASTLS? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 06:52:57 -0000 6 mar 2013 kl. 20:52 skrev Paul Wouters : > On Wed, 6 Mar 2013, Viktor Dukhovni wrote: > >>> But since HASTLS seems dead, please interpret "TLSA record present" as >>> "don't deliver without TLS" >>> >>> *ducks* >> >> No need to duck > > I was ducking for other people :) > >> , if DNSSEC serves-up usable TLSA records, then >> indeed Postfix won't deliver without TLS. > > And that is what the majority did not want the specification to mean. > They wanted the "is TLS mandatory for this connection or not" to be > signaled with a separate record, the draft had HASTLS. However, that > draft hasn't moved at all in over a year, and I am personally in favour > of using the presence of a TLSA record to mean "do not contact without > TLS". In SIP we use NAPTR records to indicate choice of transport to contact a specific domain name. In NAPTR, I can say "I'm only available over TLS". Just for the archive... /O > >> If *all* the records are >> malformed or use unsupported parameters, then my reading of DANE >> 6698 is that one should behave as though no TLSA records were >> present. This is based on 6698 #4.1: >> >> If an application receives zero usable certificate associations from >> a DNS request or from its cache, it processes TLS in the normal >> fashion without any input from the TLSA records. If an application >> receives one or more usable certificate associations, it attempts to >> match each certificate association with the TLS server's end entity >> certificate until a successful match is found. During the TLS >> handshake, if none of the certificate associations matches the >> certificate given by the TLS server, the TLS client MUST abort the >> handshake. >> >> Are you saying that an RRset consisting entirely of unusable TLSA >> records should force TLS (to always fail)? > > That section does not talk about whether or not to use non-TLS. It only > talks about "if you want to do TLS and you find one or more TLSA > records". It does not talk about "should we connect using TLS or > without?" > > Paul > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From fanf2@hermes.cam.ac.uk Thu Mar 7 11:06:01 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D338621F8A3E for ; Thu, 7 Mar 2013 11:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04Gy1j3YJ84J for ; Thu, 7 Mar 2013 11:05:59 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 98A4221F86C1 for ; Thu, 7 Mar 2013 11:05:55 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from [31.75.249.155] (port=57585) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1UDg8P-0000Iv-XE (Exim 4.72) (return-path ); Thu, 07 Mar 2013 19:05:50 +0000 References: <43ABB2C5-0B0E-44A1-88BF-9E9714A0369F@vpnc.org> <20130305041432.C17A91A5F4@ld9781.wdf.sap.corp> <20130305055935.GO29992@mournblade.imrryr.org> <54ABCDF9-52E3-41C8-A1C5-6D387DFB5746@nic.cz> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B144) From: Tony Finch Date: Thu, 7 Mar 2013 19:05:37 +0000 To: Paul Wouters Sender: Tony Finch Cc: dane WG list Subject: Re: [dane] Certificate usages 1/3 and subject name checks X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 19:06:01 -0000 On 6 Mar 2013, at 17:44, Paul Wouters wrote: > > But since HASTLS seems dead, please interpret "TLSA record present" as > "don't deliver without TLS" That is what my drafts require. Tony. -- f.anthony.n.finch http://dotat.at/ From viktor1dane@dukhovni.org Thu Mar 7 12:03:22 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D045B21F8C08 for ; Thu, 7 Mar 2013 12:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5JfPo7+iH1L for ; Thu, 7 Mar 2013 12:03:22 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5F62F21F8B1C for ; Thu, 7 Mar 2013 12:03:22 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 941022AB64D; Thu, 7 Mar 2013 20:03:21 +0000 (UTC) Date: Thu, 7 Mar 2013 20:03:21 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130307200321.GE29304@mournblade.imrryr.org> References: <43ABB2C5-0B0E-44A1-88BF-9E9714A0369F@vpnc.org> <20130305041432.C17A91A5F4@ld9781.wdf.sap.corp> <20130305055935.GO29992@mournblade.imrryr.org> <54ABCDF9-52E3-41C8-A1C5-6D387DFB5746@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] dane-srv draft: MUST SNI? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 20:03:22 -0000 On Thu, Mar 07, 2013 at 07:05:37PM +0000, Tony Finch wrote: > > But since HASTLS seems dead, please interpret "TLSA record present" as > > "don't deliver without TLS" > > That is what my drafts require. Speaking of the drafs, one point I'd like to see modified is the MUST SNI requirement. I think it is too restrictive for two reasons: - Some servers will have a single multi-SAN certificate, that meets the requirements of both legacy and DANE-aware clients and so don't need to support SNI. - Many (or perhaps even most) servers will publish "TLSA 3 1 1" records, and we've just agreed (after bload sweat and tears) that "TLSA 3 x y" won't need name checks. So just the legacy name in the certificate suffices. Therefore, the "MUST SNI" is I think a "SHOULD SNI", if the server does not have a multi-name certificate, and its DANE cert usage leads to some clients expecting a different name than others. Doing SNI in Postfix would be a pain, and its never been needed before, I'd like to keep it that way. -- Viktor. From hallam@gmail.com Fri Mar 8 15:41:06 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14B521F8596 for ; Fri, 8 Mar 2013 15:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4At56ed-tTZ for ; Fri, 8 Mar 2013 15:41:06 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id A06AE21F858C for ; Fri, 8 Mar 2013 15:41:05 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so51309wib.3 for ; Fri, 08 Mar 2013 15:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9OHXwxorN7ZbyXehEvVhgGjLMpIwR14hfGqyEcrITpM=; b=ID9vaMpsUvoexXY2/jU/QQMCt7jj0VmVUtAFriwgydrnxMpBnsEUMovTkpuHP+Gmz3 pAU8eJED2D88y8FsSy005+qCbvgoxjUu/svcwi4wFwci51FknzNojOKgz8Z0kOYLlUiJ zBwWtHlTfXiLTw5EEKJ91pp1DdS5CEAkEyjX5b2f9EVu7RMZVRHoNNPClv8i7jhqy5RG iJ3GYQ0aQ107ncpjiQwecI4mDGV71EWb/o8+dADzXf9TcH3XaN/bIWKRZLgsk5btc5NM E0NyK0Xcoqsqp1yFbRMJPl1vK4tZL92GFGYc4R0xN/zIWtqLnupLVHe15j+V2xcLqqzw S9hQ== MIME-Version: 1.0 X-Received: by 10.180.94.69 with SMTP id da5mr1065372wib.30.1362786064806; Fri, 08 Mar 2013 15:41:04 -0800 (PST) Received: by 10.194.11.71 with HTTP; Fri, 8 Mar 2013 15:41:04 -0800 (PST) In-Reply-To: <3EDBF3AF-E1E0-410E-A63A-E2709BF54862@ogud.com> References: <20130305044516.156641A5F4@ld9781.wdf.sap.corp> <3EDBF3AF-E1E0-410E-A63A-E2709BF54862@ogud.com> Date: Fri, 8 Mar 2013 18:41:04 -0500 Message-ID: From: Phillip Hallam-Baker To: Olafur Gudmundsson Content-Type: text/plain; charset=ISO-8859-1 Cc: dane@ietf.org Subject: Re: [dane] revocation of keys or certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 23:41:06 -0000 For security considerations, only the signature expiration time is significant. The problem is that an attacker with control of the key could in theory set the expiration time to 2099 or something stupid. But that is already a known security consideration (or was). If the attacker has only one RRSIG then it is sufficient to have a limit on the lifetime of the RRSIG. But an attacker could also generate themselves multiple RRSIGs for the whole time interval in question. So ultimately it comes down to how the keys are managed in the upstream zones and whether one of those can be rolled in the case of a major compromise. So there is a time window for attack in the case of administrator incompetence, but I have a really hard time seeing how it can be closed with a revocation system that was established through the same root of trust. On Tue, Mar 5, 2013 at 7:19 AM, Olafur Gudmundsson wrote: > > > On Mar 4, 2013, at 11:45 PM, Martin Rex wrote: > >> Mark Andrews wrote: >>> >>>> >>>> TTL is *NOT* signed. >>>> >>>> While there is an original TTL field that is signed: >>>> http://tools.ietf.org/html/rfc4034#section-3.1.4 >>>> >>>> this will not prevent any intermediary (attacker) to produce >>>> new DNS responses with TTLs less than or equal ot the original >>>> TTL field whenever necessary within the remaing RRSIG lifetime. >>>> >>>> -Martin >>> >>> And the sematic difference is what? When you produce a RRSIG you >>> are saying to the world "all these TTL values are valid". It's >>> just short hand for generating TTL+1 RRSIG covering each possible >>> value. >> >> The original question was whether TTL provides revocation. >> No, TTL can not possibly provide revocation (for DNSSEC protected >> DNS records), because it can be made up at will by an intermediary >> attacker. Only the RRSIG lifetime and rolling the zone key are >> reliable in getting rid of DNSSEC protected data that is no longer >> to be seen as valid. >> >> It is like that "limited to one withdrawel per day" limit on >> ATM cards that is implemented by an unprotected counter that >> is stored on the ATM card itself. The crooks with a >> card reader/writer can simply reset that counter on the magnetic >> strip after withdrawal and perform multiple withdrawels >> (usually on ATMs of different banks) on the same day. >> > > > Martin and Mark, > You are both right and neither fully wrong :-) > > For most practical cases we can think of DNS time based "revocation" as two different revocation times. > > old RRset TTL == is when an publisher of the record can assume that MOST resolvers will have purged the old record from their caches. This timer starts when the new RRset is distributed to the LAST authoritative server for the zone. > > Signature Expiration time == Absolute time upto which an ON-PATH adversary can reuse the old RRset and have it accepted by a targeted victim. > > The difference is the scope of the revocation, MOST vs Targeted, also if the adversary is ON-PATH then it > can do lots of other things to the victim. > There are differences in "how much" ON-PATH the adversary is, in some cases they are listening to the query traffic on the write in other cases they have succeeded in redirecting DNS traffic to resolvers under their control. > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Website: http://hallambaker.com/ From viktor1dane@dukhovni.org Wed Mar 13 16:53:12 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362BE11E80D5 for ; Wed, 13 Mar 2013 16:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWz2TNj3n4DV for ; Wed, 13 Mar 2013 16:53:11 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id D5BA311E80D3 for ; Wed, 13 Mar 2013 16:53:10 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EECD52AB6DE; Wed, 13 Mar 2013 23:53:08 +0000 (UTC) Date: Wed, 13 Mar 2013 23:53:08 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130313235308.GD29304@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] TLSA RRset and CNAME question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 23:53:12 -0000 Suppose a query a known signed zone: Q: _25._tcp.mail.example.com. IN TLSA ? and I receive a signed CNAME referral: A: _25._tcp.mail.example.com. IN CNAME 3.1.1._tlsa.example.edu. and suppose further that the example.edu zone is unsigned with FWIW an insecure (zone is not signed) TLSA record published there: 3.1.1._tlsa.example.edu. IN TLSA 3 1 1 Is this a a case of "no TLSA records" or "no usable TLSA records"? The domain owner of the secure zone thought they were publishing TLSA records, so one might think (draft-ietf-dane-srv) that one MUST use TLS for this service (be it with whatever non-DANE policy applies when one does that). On the other hand, the error is rather similar from an implementation sanity viewpoint to a failure to find validated records, as opposed to use of parameters not understood by the client, ... The simplest stub resolver logic for DNSSEC when chasing CNAMEs is to return the boolean AND of the validation status of the final answer with the status for any CNAMEs chased along the way. All this is nicely layered inside a library (so the application does not have to do the chasing itself), and now it is impossible to distinguish between the first zone being unsigned, and some intermediate CNAME being unsigned. So to retain some implementation sanity I'd like to vote for "not found" rather than "unusable", though the owner of "example.com" may be surprised by the outcome, it is IMHO his fault for CNAMEing the TLSA at a domain outside his control. We can reasonably hope such cases will be rare, and that domains once signed, will mostly tend to stay signed. -- Viktor. From viktor1dane@dukhovni.org Wed Mar 13 17:06:42 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C38211E80D3 for ; Wed, 13 Mar 2013 17:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIzUnBeMGqAS for ; Wed, 13 Mar 2013 17:06:42 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 01A5B11E80C5 for ; Wed, 13 Mar 2013 17:06:42 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5B53C2AB6DE; Thu, 14 Mar 2013 00:06:41 +0000 (UTC) Date: Thu, 14 Mar 2013 00:06:41 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130314000641.GE29304@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] TLSA RR scope question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 00:06:42 -0000 Postfix supports two mechanisms for resolving hostnames obtained via MX records. The first is naturally "dns", and this is the only one used by default, but administrators may choose to enable "native" hostname lookups so that they reach various internal hosts listed only in /etc/hosts or similar. My intention is to only impute TLSA RRset policy to hosts that that were found in DNS. If a host is found by other means there is little reason to believe that the (typically) TCP endpoint the administrator wants us to connect is the same one described in any TLSA records that happen to end with the same hostname. There seems to be some nascent effort to address this in dane-ietf-draft-smtp, but no real text yet. Is there any support for my tentative assessment of the situation? Security is nice and all that, but we don't want to break too much and give security a bad name, with everyone (perhaps rightly) too afraid to deploy it (deployment should make things better even if not perfect). So I would vote for caution, it should be enough to ensure that DANE TLS describe security on the public Internet for entities named by DNS and therefore, should not intrude on unrelated namespaces (scopes). -- Viktor. From cloos@jhcloos.com Thu Mar 14 03:17:08 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C35821F8F4E for ; Thu, 14 Mar 2013 03:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwWDnOqmjEYX for ; Thu, 14 Mar 2013 03:17:02 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2604:8800:100:81ca::53]) by ietfa.amsl.com (Postfix) with ESMTP id 66F9D21F8F50 for ; Thu, 14 Mar 2013 03:17:02 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 578B04013D; Thu, 14 Mar 2013 10:16:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1363256219; bh=0fFUCjd+I0aVs1Np2I7w3rPcqZWoAI9b+RZbiX3a/QY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=JgZbu3LDlO3Tz8d4ZdtDcV+zDsvAefTMmlEr8GslE+F0J69vJNaA5Cgjc3s1CGXzr wAOzyi0dJrpJxWzQlqFtBk3Uuk2E9gFkQeCVhVVT1KgoacfKlGBj/u5MiwOzWjGE4u 8orax0D25ErHB6j5exhn4CtvAA47gnmUDhd28+Fo= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 8F9EC60028; Thu, 14 Mar 2013 10:05:00 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20130313235308.GD29304@mournblade.imrryr.org> (Viktor Dukhovni's message of "Wed, 13 Mar 2013 23:53:08 +0000") References: <20130313235308.GD29304@mournblade.imrryr.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 14 Mar 2013 06:05:00 -0400 Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130314:viktor1dane@dukhovni.org::Smpza3+L5UVpryY7:000000000000000000000000000000000000TR9KA X-Hashcash: 1:30:130314:dane@ietf.org::z6WVGcPob7kkO9ZA:000CHgpc Cc: dane@ietf.org Subject: Re: [dane] TLSA RRset and CNAME question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 10:17:08 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> Suppose a query a known signed zone: ... and I receive a signed VD> CNAME referral: ... and suppose further that the example.edu zone VD> is unsigned with FWIW an insecure (zone is not signed) TLSA record VD> published there: My understanding of the consensus is that, if anything in the chain is unsigned (as opposed to bogus), then any tlsa records should be ignored and the connection should progress as if dane were not there at all. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From cloos@jhcloos.com Thu Mar 14 03:18:43 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FECF21F8F56 for ; Thu, 14 Mar 2013 03:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id as1bgrKqMtgY for ; Thu, 14 Mar 2013 03:18:39 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id 172D721F8F4E for ; Thu, 14 Mar 2013 03:18:39 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 7B54F4013D; Thu, 14 Mar 2013 10:18:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1363256318; bh=mIOdvDClPmQJbZVRj5/92J5/8g+oWsF4ZbO5nL8z6H0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=TvlCe9KhJAsZbpczFdLTKqKUMQEAIT8UCAe1NOBFpQdGznvvCVT+Qerk4Gcm4P0WI f4Z2goSM1LJmsOEFNXHQ6XX0B/rVVLfNdxaDIqxGHpyl23FGSWx8MVnPuiiqEMnIuz VTiFgGrc14wyoLegzDRyx60Yttht8bbmK4geToKw= Received: by carbon.jhcloos.org (Postfix, from userid 500) id A0D2460028; Thu, 14 Mar 2013 10:08:22 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20130314000641.GE29304@mournblade.imrryr.org> (Viktor Dukhovni's message of "Thu, 14 Mar 2013 00:06:41 +0000") References: <20130314000641.GE29304@mournblade.imrryr.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 14 Mar 2013 06:08:22 -0400 Message-ID: Lines: 10 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130314:viktor1dane@dukhovni.org::7kQa46yJniPnx/DK:000000000000000000000000000000000000ZLT9B X-Hashcash: 1:30:130314:dane@ietf.org::4WBgweaBkG3jUNM/:000Zu+Nu Cc: dane@ietf.org Subject: Re: [dane] TLSA RR scope question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 10:18:43 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> My intention is to only impute TLSA RRset policy to hosts that that VD> were found in DNS. That feels reasonable. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From gnu@toad.com Thu Mar 14 12:21:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1519C11E80F2 for ; Thu, 14 Mar 2013 12:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpCWMveI5o4i for ; Thu, 14 Mar 2013 12:21:15 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 92F3611E8192 for ; Thu, 14 Mar 2013 12:21:07 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id r2EJL6N5008619 for ; Thu, 14 Mar 2013 11:21:06 -0800 Message-Id: <201303141921.r2EJL6N5008619@new.toad.com> To: dane@ietf.org In-reply-to: <20130313235308.GD29304@mournblade.imrryr.org> References: <20130313235308.GD29304@mournblade.imrryr.org> Comments: In-reply-to Viktor Dukhovni message dated "Wed, 13 Mar 2013 23:53:08 +0000." Date: Thu, 14 Mar 2013 11:21:06 -0800 From: John Gilmore Subject: Re: [dane] TLSA RRset and CNAME question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:21:16 -0000 > Suppose a query a known signed zone: > > Q: _25._tcp.mail.example.com. IN TLSA ? > > and I receive a signed CNAME referral: > > A: _25._tcp.mail.example.com. IN CNAME 3.1.1._tlsa.example.edu. > Is this a a case of "no TLSA records" or "no usable TLSA records"? This is a case of "no TLSA records". That's a CNAME record, not a TLSA record. If the domain admin wanted to put a TLSA record there, they know how to do that. There is nothing magic about the _25._tcp subdomain names. Using them for a CNAME (or an A record or anything else) does not indicate a desire to use TLSA records. John From ajs@anvilwalrusden.com Thu Mar 14 12:47:26 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EAC11E824F for ; Thu, 14 Mar 2013 12:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqYias2NaeEU for ; Thu, 14 Mar 2013 12:47:26 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4D34811E822F for ; Thu, 14 Mar 2013 12:47:25 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 5A6A58A031 for ; Thu, 14 Mar 2013 19:47:08 +0000 (UTC) Date: Thu, 14 Mar 2013 15:47:06 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20130314194705.GB50106@mx1.yitter.info> References: <20130313235308.GD29304@mournblade.imrryr.org> <201303141921.r2EJL6N5008619@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201303141921.r2EJL6N5008619@new.toad.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] TLSA RRset and CNAME question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:47:26 -0000 On Thu, Mar 14, 2013 at 11:21:06AM -0800, John Gilmore wrote: > This is a case of "no TLSA records". That's a CNAME record, not a > TLSA record. If the domain admin wanted to put a TLSA record there, > they know how to do that. Not if there's a CNAME there, they don't. You can't put a TLSA record there if there's a CNAME. > There is nothing magic about the _25._tcp subdomain names. Using > them for a CNAME (or an A record or anything else) does not indicate > a desire to use TLSA records. But if there's a CNAME with a TLSA record at the target, presumably you ought to use that TLSA record. No? A -- Andrew Sullivan ajs@anvilwalrusden.com From viktor1dane@dukhovni.org Thu Mar 14 13:10:22 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0121B11E8146 for ; Thu, 14 Mar 2013 13:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEHo1MBP0Tcy for ; Thu, 14 Mar 2013 13:10:21 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 7E06E11E8103 for ; Thu, 14 Mar 2013 13:10:21 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9201A2AB743; Thu, 14 Mar 2013 20:10:20 +0000 (UTC) Date: Thu, 14 Mar 2013 20:10:20 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130314201020.GH29304@mournblade.imrryr.org> References: <20130313235308.GD29304@mournblade.imrryr.org> <201303141921.r2EJL6N5008619@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201303141921.r2EJL6N5008619@new.toad.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] TLSA RRset and CNAME question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 20:10:22 -0000 On Thu, Mar 14, 2013 at 11:21:06AM -0800, John Gilmore wrote: > > Suppose a query a known signed zone: > > > > Q: _25._tcp.mail.example.com. IN TLSA ? > > > > and I receive a signed CNAME referral: > > > > A: _25._tcp.mail.example.com. IN CNAME 3.1.1._tlsa.example.edu. > > > Is this a a case of "no TLSA records" or "no usable TLSA records"? > > This is a case of "no TLSA records". That's a CNAME record, not a > TLSA record. If the domain admin wanted to put a TLSA record there, > they know how to do that. Yes, but the domain will still be surprised, because their *intent* is to indirectly leverage a TLSA record stored elsewhere in the DNS. For example: _25._tcp.open.nlnetlabs.nl. IN CNAME 3.1.1._dane.nlnetlabs.nl. 3.1.1._dane.nlnetlabs.nl. IN TLSA 3 1 1 0D1F... This case the CNAME points to a record in the same zone, but real users will do stranger things. > There is nothing magic about the _25._tcp subdomain names. Using > them for a CNAME (or an A record or anything else) does not indicate > a desire to use TLSA records. I agree with the logic, (this is the answer I was hoping for and expecting). So domain owners will need to be cautioned about the risks of CNAMEs intended for use with TLSA records. -- Viktor. From viktor1dane@dukhovni.org Thu Mar 14 13:13:46 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A0A21F8E21 for ; Thu, 14 Mar 2013 13:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx5w0qJKbwSl for ; Thu, 14 Mar 2013 13:13:46 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3C56B21F8B2B for ; Thu, 14 Mar 2013 13:13:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E00D12AB743; Thu, 14 Mar 2013 20:13:45 +0000 (UTC) Date: Thu, 14 Mar 2013 20:13:45 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130314201345.GI29304@mournblade.imrryr.org> References: <20130313235308.GD29304@mournblade.imrryr.org> <201303141921.r2EJL6N5008619@new.toad.com> <20130314194705.GB50106@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130314194705.GB50106@mx1.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] TLSA RRset and CNAME question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 20:13:46 -0000 On Thu, Mar 14, 2013 at 03:47:06PM -0400, Andrew Sullivan wrote: > > This is a case of "no TLSA records". That's a CNAME record, not a > > TLSA record. If the domain admin wanted to put a TLSA record there, > > they know how to do that. > > Not if there's a CNAME there, they don't. You can't put a TLSA record > there if there's a CNAME. John clearly meant in place of, not in addition. > > There is nothing magic about the _25._tcp subdomain names. Using > > them for a CNAME (or an A record or anything else) does not indicate > > a desire to use TLSA records. > > But if there's a CNAME with a TLSA record at the target, presumably > you ought to use that TLSA record. No? Yes, if both are validated, but not otherwise, in particular a validated CNAME to a not validated TLSA RRset is not validated and the combination bevahes indistinguishably from "NODATA", undoubtedly some folks will keep getting surprised by this. -- Viktor. From ajs@anvilwalrusden.com Thu Mar 14 13:26:46 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9704811E80FB for ; Thu, 14 Mar 2013 13:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Nnf2cIod-9Y for ; Thu, 14 Mar 2013 13:26:43 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id DCB7611E8193 for ; Thu, 14 Mar 2013 13:26:39 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 4B8868A031 for ; Thu, 14 Mar 2013 20:26:39 +0000 (UTC) Date: Thu, 14 Mar 2013 16:26:37 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20130314202637.GJ50106@mx1.yitter.info> References: <20130313235308.GD29304@mournblade.imrryr.org> <201303141921.r2EJL6N5008619@new.toad.com> <20130314194705.GB50106@mx1.yitter.info> <20130314201345.GI29304@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130314201345.GI29304@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] TLSA RRset and CNAME question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 20:26:47 -0000 Oh, sorry, I'm dim. On Thu, Mar 14, 2013 at 08:13:45PM +0000, Viktor Dukhovni wrote: > Yes, if both are validated, but not otherwise, in particular a > validated CNAME to a not validated TLSA RRset is not validated and > the combination bevahes indistinguishably from "NODATA", undoubtedly > some folks will keep getting surprised by this. Perhaps. I'd call that a "feature", though. A -- Andrew Sullivan ajs@anvilwalrusden.com From lconroy@insensate.co.uk Thu Mar 14 15:43:00 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C6211E814D for ; Thu, 14 Mar 2013 15:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Tp3ZBUS7-YT for ; Thu, 14 Mar 2013 15:43:00 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [81.174.156.22]) by ietfa.amsl.com (Postfix) with ESMTP id DA9DB11E8133 for ; Thu, 14 Mar 2013 15:42:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 5BA9C7C80D9; Thu, 14 Mar 2013 22:42:58 +0000 (GMT) Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b96sHS0T6XYq; Thu, 14 Mar 2013 22:42:57 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTPSA id E41687C80CE; Thu, 14 Mar 2013 22:42:57 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <20130314202637.GJ50106@mx1.yitter.info> Date: Thu, 14 Mar 2013 22:42:57 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <67F43E41-C687-4BB6-8151-29CAF9BA16A9@insensate.co.uk> References: <20130313235308.GD29304@mournblade.imrryr.org> <201303141921.r2EJL6N5008619@new.toad.com> <20130314194705.GB50106@mx1.yitter.info> <20130314201345.GI29304@mournblade.imrryr.org> <20130314202637.GJ50106@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1085) Cc: dane list Subject: Re: [dane] TLSA RRset and CNAME question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 22:43:00 -0000 Hi Andrew, folks, it's a feature only if documented. This thread has been useful (certainly made me think), so please can = someone document this? Maybe a "care and feeding of ..." document for this menagerie of RRs = would be useful. We did an "Experiences" doc for ENUM to try to capture the holes various = implementors fell into, and ENUM's trivial by comparison. all the best, Lawrence On 14 Mar 2013, at 20:26, Andrew Sullivan wrote: > Oh, sorry, I'm dim. >=20 > On Thu, Mar 14, 2013 at 08:13:45PM +0000, Viktor Dukhovni wrote: >=20 >> Yes, if both are validated, but not otherwise, in particular a >> validated CNAME to a not validated TLSA RRset is not validated and >> the combination bevahes indistinguishably from "NODATA", undoubtedly >> some folks will keep getting surprised by this. >=20 > Perhaps. I'd call that a "feature", though. >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com From viktor1dane@dukhovni.org Sun Mar 17 19:26:07 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC4421F8C85 for ; Sun, 17 Mar 2013 19:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xexC-uRWYgS for ; Sun, 17 Mar 2013 19:26:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE9E21F8C84 for ; Sun, 17 Mar 2013 19:26:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 652372AB748; Mon, 18 Mar 2013 02:26:05 +0000 (UTC) Date: Mon, 18 Mar 2013 02:26:05 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130318022605.GH28046@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] Live MX hosts with DANE TLSA? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 02:26:07 -0000 My implementation of DANE TLSA support for Postfix is code complete and passes basic tests. I'd like to test more of the feature-set, but at I found listed exactly four MX hosts with DANE TLSA records for SMTP: $ for domain in jhcloos.com nlnetlabs.nl nlnet.nl do dig +short -t mx $domain | sort -n | awk '{print $NF}' | while read h do dig +noall +ans -t tlsa _25._tcp.$h done done | perl -lne 'print unless ++$dup{$_} > 1;' _25._tcp.liberty.jhcloos.com. 3361 IN TLSA 3 1 1 9D72F4AE... _25._tcp.pao.uu.jhcloos.net. 3362 IN TLSA 3 1 1 FE79C6D0... _25._tcp.open.nlnetlabs.nl. 9962 IN CNAME 3.1.1._dane.nlnetlabs.nl. 3.1.1._dane.nlnetlabs.nl. 9962 IN TLSA 3 1 1 0D1FCBD7... _25._tcp.open.nlnet.nl. 86163 IN TLSA 3 1 1 6813D634... All sensibly using 3 1 1, so we have a 100% consensus best-practice. :-) I'd like to test with more domains, if possible. Does anyone know of any more? Particularly any that publish: - Certificate usage 0 or 2 - Selector 0 - Matching Type 0 or 2 -- Viktor. From viktor1dane@dukhovni.org Sun Mar 17 20:18:22 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1022721F8A00 for ; Sun, 17 Mar 2013 20:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jATo8CNdtiiE for ; Sun, 17 Mar 2013 20:18:21 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 55C3321F89A5 for ; Sun, 17 Mar 2013 20:18:21 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CCCEE2AB748; Mon, 18 Mar 2013 03:18:20 +0000 (UTC) Date: Mon, 18 Mar 2013 03:18:20 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130318031820.GI28046@mournblade.imrryr.org> References: <20130318022605.GH28046@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130318022605.GH28046@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Live MX hosts with DANE TLSA? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 03:18:22 -0000 On Mon, Mar 18, 2013 at 02:26:05AM +0000, Viktor Dukhovni wrote: > My implementation of DANE TLSA support for Postfix is code complete > and passes basic tests. I'd like to test more of the feature-set, > but at > I found listed exactly four MX hosts with DANE TLSA records for SMTP: FWIW with verbose logging you get: Mar 17 23:09:41 amnesiac postfix/smtp[43739]: liberty.jhcloos.com[208.68.39.189]:25: end entity public-key matched=1 sha256 digest=9D:72:F4:AE:A8:83:BA:43:38:BB:C5:7C:83:97:4C:FA:62:6A:10:DC:20:E0:F8:64:BF:80:85:68:27:70:34:34 Mar 17 23:09:41 amnesiac postfix/smtp[43743]: open.nlnet.nl[213.154.224.2]:25: end entity public-key matched=1 sha256 digest=68:13:D6:34:71:97:0E:59:FD:57:3F:6B:E1:7E:0C:74:18:1E:B9:D2:14:D3:A2:60:7F:46:D6:B1:C2:B0:48:FA Mar 17 23:09:41 amnesiac postfix/smtp[43742]: open.nlnetlabs.nl[213.154.224.1]:25: end entity public-key matched=1 sha256 digest=0D:1F:CB:D7:16:86:19:96:07:A1:32:74:4A:49:18:FC:20:95:65:C9:1F:A8:E9:FF:EE:A0:AA:FD:6B:93:05:F6 If anyone wants to volunteer to test the code, drop me a note, I'll send you a pointer to the patched release (documentation in ). -- Viktor. From internet-drafts@ietf.org Tue Mar 19 10:30:29 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EB021F8DE3; Tue, 19 Mar 2013 10:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.352 X-Spam-Level: X-Spam-Status: No, score=-102.352 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImWMoHZEz4Tv; Tue, 19 Mar 2013 10:30:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8B521F8E13; Tue, 19 Mar 2013 10:30:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130319173028.9409.53559.idtracker@ietfa.amsl.com> Date: Tue, 19 Mar 2013 10:30:28 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smime-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:30:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : Using Secure DNS to Associate Certificates with Domain N= ames For S/MIME Author(s) : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-smime-01.txt Pages : 6 Date : 2013-03-19 Abstract: This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DANE (RFC 6698) does for TLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smime There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smime-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-smime-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From viktor1dane@dukhovni.org Wed Mar 20 14:37:34 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5941F11E80F4 for ; Wed, 20 Mar 2013 14:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoheBgoFMR3S for ; Wed, 20 Mar 2013 14:37:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id D8E2D11E80F2 for ; Wed, 20 Mar 2013 14:37:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E38F72AABC4; Wed, 20 Mar 2013 21:37:32 +0000 (UTC) Date: Wed, 20 Mar 2013 21:37:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130320213732.GA28046@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] TA certs at depth 0? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 21:37:34 -0000 With certificate usage 0/2, if the server certificate from the TLS handshake is in fact the trust anchor itself, rather than something else signed (perhaps indirectly) via the trust anchor, is that OK? Should a DANE client accept the chain? Should it still apply name checks? I wasn't able to divine an answer from RFC 5280 (PKIX). At the moment, I am not treating depth zero specially, so a trust achor's own certificate is accepted and in that case required to match the MX domain or validated MX hostname. -- Viktor. From i.grok@comcast.net Wed Mar 20 20:56:48 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62C711E80F1 for ; Wed, 20 Mar 2013 20:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qs4uVpyOfqcD for ; Wed, 20 Mar 2013 20:56:47 -0700 (PDT) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 4C37311E8103 for ; Wed, 20 Mar 2013 20:56:45 -0700 (PDT) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta03.emeryville.ca.mail.comcast.net with comcast id E3jv1l0071zF43QA33wkyT; Thu, 21 Mar 2013 03:56:44 +0000 Received: from odin.ulthar.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by omta24.emeryville.ca.mail.comcast.net with comcast id E3wi1l00M2Ekl488k3wkAM; Thu, 21 Mar 2013 03:56:44 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.5) with ESMTP id r2L3ufub024540 for ; Wed, 20 Mar 2013 23:56:41 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id r2L3ufkc024539 for dane@ietf.org; Wed, 20 Mar 2013 23:56:41 -0400 Date: Wed, 20 Mar 2013 23:56:41 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20130321035641.GA14868@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20130320213732.GA28046@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: <20130320213732.GA28046@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1363838204; bh=VQFUOTdnLUJD3wQ+MLBNTmOBHjBVSkgUkYRqTv19Xow=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=kucN2gMvRYms8ARgQuopl8Inlulu0qMZEqYTQ3sZI8GgYMmXt3Rt505HzRqaVdYps TPkpuGLux6hHClkLO2oHzlW8B9d5bROye5iFtKcvROG5ouuZh565PMNQ3qjujsfi0L NcDW/UwL/jfFkITIsGksNoy3is26o4js4NJ2KCYyP9+jV+42k0JByIPa0SuNyqoxU/ UJqpR6O3CjMdEEnhFPSv/cY9H1b3Obi94je/e0eIgVTCeP+fDdHbGeyM7xYvAak8u8 asJ8PqhG9MxQG6QSlPW5hbisCNTVBadR55i02zlTtjXr7RFgKzCD243bGZwKVlqWGn ZKx/ZiB1d3rNA== Subject: Re: [dane] TA certs at depth 0? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 03:56:48 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 09:37:32PM +0000, Viktor Dukhovni wrote: > With certificate usage 0/2, if the server certificate from the TLS > handshake is in fact the trust anchor itself, rather than something > else signed (perhaps indirectly) via the trust anchor, is that OK? >=20 > Should a DANE client accept the chain? Should it still apply name > checks? I wasn't able to divine an answer from RFC 5280 (PKIX). >=20 > At the moment, I am not treating depth zero specially, so a trust > achor's own certificate is accepted and in that case required to > match the MX domain or validated MX hostname. Ah yes, this issue spawned a lengthy discussion a little over a year ago. The discussion starts here: https://www.ietf.org/mail-archive/web/dane/current/msg03997.html The direct answer to your question might be this email here: https://www.ietf.org/mail-archive/web/dane/current/msg04196.html but it's hard to say if it does or not. Exactly how to handle the chain in a spec-compliant way depends on specifics of the server's certificate and the TA and your email doesn't really specify those details. Take a look at the above links, I think you'll see what I mean. In the end, client-side inconsistency on this point was one of the drivers for us defining usage 3 (while some clients would allow it, others would not, so a case that a TLSA publisher could rely on to work the way they want was needed). HTH --=20 Scott Schmit --ZPt4rx8FFjLCG7dd Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQBAYJKoZIhvcNAQcCoIIP9TCCD/ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DTUwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBvkwggXhoAMCAQICAwR4CjANBgkqhkiG 9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDcwNDEz NTc1MVoXDTEzMDcwNTA1MjcyNlowQDEbMBkGA1UEAwwSaS5ncm9rQGNvbWNhc3QubmV0MSEw HwYJKoZIhvcNAQkBFhJpLmdyb2tAY29tY2FzdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCxn+QJTgdUJ1RAOi6JbFsDfl21ZX/OPx/ttuXWQP1vWwBZybHU+4/+bRXH 5ONhjbc5ikZvz/E406iQLy2xMT5PI/hx4uIZQQYpkjxd4rCbbvLNACz5L+cFaGj4WfGwAXDv bw4nx8Mh3WjbR5yjBCWYqadiv7HWAWmhaJmuaTp/e+mO2EEOOdoNQ8b2mxMyN43TlElx6Zos t7g/eQUcLWgTB5apPhowCCGnFU6uHK053QsPmsmZ67gg8acpb5ic0+P+X1j+IgD3jcsDzjrF TPlrvU4ZuBYQJISqngbc2ua/uutx75Xs4iFXWNRlnYfZMFJy96USzrhIBRqcORrjbyGXAgMB AAGjggOtMIIDqTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcD AgYIKwYBBQUHAwQwHQYDVR0OBBYEFAxkdHPHW3mhf+gXJjezdazgoDRuMB8GA1UdIwQYMBaA FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB0GA1UdEQQWMBSBEmkuZ3Jva0Bjb21jYXN0Lm5ldDCC AiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3 YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVt ZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUg aW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9i bGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBT ZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9h aWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBACJi0f4m 0bSVq+pq4AHeC2Rj4S8rciW+Uce6LC69UlyVMijKv/pZNFM08vqRXEI9WpKQhKXacJ+rK9az DBmnxq1scqKhn7991V6Yt2t0tEY8vUX7q330GybUB/rQLNrh66GFXaEWU/S692pGzvUXeV+w zz48snMpoMHQdxkHHW5sQkpo99SF/vOA5/sqvFmJ+ai1iDRjtKcChjkmAtFmCKv/dNrXnvew 5+QnLlnE/TsW4Sdv3bcLdlthD4eavS3BdgXfX7dfj0ykel53J2Us3CikNbyuCsJpwMH+gX1j LcXZOYIDLzZXCFEOFajhgsAZ5JQrW0fFRxjGIp8Rs+rxdFwxggKXMIICkwIBATCBlDCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEeAowCQYFKw4DAhoFAKCB2DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAzMjEwMzU2NDFaMCMG CSqGSIb3DQEJBDEWBBQZSXP0jeR8ef7ME0EGFwPDAAStyTB5BgkqhkiG9w0BCQ8xbDBqMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq hkiG9w0BAQEFAASCAQCmLZYJB67Q6Xq0BLLBIRb2gqw1bZNmBT9q1sh5le+imRqJ0wEFglPc tT910O+YfOclQRBDjXqjI789oyXqH2sLIAlbj809yilt9GXyPwtA1jVZ3s5CbpWzOHCFbKMF Rn7qVOZihnlORKtnUzI47a9IgDBmonTLGlDCYKnzN2XAi6vT9dYLb/hotXa0lhexgF70seps Ub+ouE4TxWjm93LpZUz/+aW/gMkkWA+mKOE+9WJCg6QkRbpjLKwNCqhoR31oQuuLiCDWOM67 BQVOaFxeU2ZHchFbYDJGHDGpBeLyNm0Z5SSkrfkNX9dHOd0P6UK2k1MNhxkgvutWLX1BKLFq --ZPt4rx8FFjLCG7dd-- From viktor1dane@dukhovni.org Wed Mar 20 23:55:06 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D8521F8BF0 for ; Wed, 20 Mar 2013 23:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4pmOyWL7vKf for ; Wed, 20 Mar 2013 23:55:05 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0DF21F8F0B for ; Wed, 20 Mar 2013 23:55:05 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6BCAF2AAE1C; Thu, 21 Mar 2013 06:55:04 +0000 (UTC) Date: Thu, 21 Mar 2013 06:55:04 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130321065504.GB28046@mournblade.imrryr.org> References: <20130320213732.GA28046@mournblade.imrryr.org> <20130321035641.GA14868@odin.ulthar.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130321035641.GA14868@odin.ulthar.us> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] TA certs at depth 0? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 06:55:06 -0000 On Wed, Mar 20, 2013 at 11:56:41PM -0400, Scott Schmit wrote: > > At the moment, I am not treating depth zero specially, so a trust > > anchor's own certificate is accepted and in that case required to > > match the MX domain or validated MX hostname. > > Ah yes, this issue spawned a lengthy discussion a little over a year > ago. The discussion starts here: > https://www.ietf.org/mail-archive/web/dane/current/msg03997.html > > The direct answer to your question might be this email here: > https://www.ietf.org/mail-archive/web/dane/current/msg04196.html > but it's hard to say if it does or not. Exactly how to handle the chain > in a spec-compliant way depends on specifics of the server's > certificate and the TA and your email doesn't really specify those ^^^ > details. My question is I guess more specifically about a certusage 2 TA ( which is hypothetically also the server certificate, so the "and" above is a conjunction of two references to the same thing). I am more interested in doing the reasonaly sensible thing than the maximally spec-compiant thing. Do we expect any appreciable number of domain owners to publish (perhaps inadvertently) "IN TLSA 2 x y ..." rather than "IN TLSA 3 x y ..." for the same self-signed key-pair (dressed in X.509v3 finery)? If yes, should we make them suffer their mistake (if this is a mistake) by failing, or just reason that we have the public key of the TA (from the one and only certificate in play) and separately, though it be a clone, a certificate signed by that TA, and just proceed as we would for any TA->leaf chain (including expiration date checks, name checks, ...). I'm not looking to reopen old wounds, or try to propose or impose my own views, rather is there a clear consensus on the semantics of the self-signed certificate below published with a "2 x y" TLSA record, when I am connecting to "mail.example.com" which presents this self-signed certificate? What does it mean? - Must it be rejected? (Perhaps 5280 suggests this is so). - If not, do the validity dates apply? (If a trust anchor is just a public and certificates just a convenient container, arguably not, but we do seem to care about the dates in public CA certs.) [ I guess I should also ask whether the expiration dates of non-degenerate TA certificates that matter with "IN TLSA 2 x y" resource records. At the moment I don't accept expired TA certs. Should any of the DANE WG RFCs explicitly cover this ground, rather than just defer to the rather dense 5280? These finer points of PKIX are not obvious when one is obtaining TAs from a new source that has its own claim to authenticity and an independent validity interval via signed DNSSEC RRsets? ] - Does the "CN" (or subjectAltName:DNS) matter? (The server has the CA cert in hand, he can sign any name he wants.) - Does it matter whether the TLSA record is a "2 0 0" or are we in the same boat with any "2 x y" describing the same self-signed leaf CA/server. Example: $ cat example.bash #! /bin/bash openssl req -sha256 -new -noout -text 2>/dev/null \ -config <(printf "[req]\n%s\n%s\n[dn]\n[exts]\n%s\n[alts]\n%s\n" \ "distinguished_name = dn" \ "x509_extensions = exts" \ "subjectAltName=@alts" \ "DNS=$1") \ -newkey param:<(openssl ecparam -name prime256v1) \ -keyout /dev/null -nodes \ -x509 -set_serial 1 -days 365 -subj "/CN=$1" $ bash example.bash Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: ecdsa-with-SHA256 Issuer: CN=mail.example.com Validity Not Before: Mar 21 06:21:45 2013 GMT Not After : Mar 21 06:21:45 2014 GMT Subject: CN=mail.example.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:58:4a:6a:8a:42:d6:6a:d6:33:a5:27:95:3c:8b: a0:54:e1:9d:df:b7:99:70:76:63:7e:48:e8:d0:54: 1a:dd:f7:69:e4:13:1e:5e:b1:13:2e:66:c6:08:4c: 34:23:e6:84:59:e9:ec:97:fd:9b:6e:ca:e4:76:91: 37:38:8d:6e:e9 ASN1 OID: secp256k1 X509v3 extensions: X509v3 Subject Alternative Name: DNS:mail.example.com Signature Algorithm: ecdsa-with-SHA256 30:44:02:20:56:c3:44:e0:10:67:f1:97:24:fc:e5:2a:fb:55: 70:66:2c:ef:84:b6:57:7e:1d:bc:a7:1c:06:94:51:cf:7e:5c: 02:20:64:95:f8:fa:74:d8:b3:c1:f5:1e:54:71:45:2a:a4:ab: 89:23:6e:1a:f6:17:a2:22:f7:50:cd:00:bc:f5:3b:de -- Viktor. From i.grok@comcast.net Thu Mar 21 07:07:02 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A254821F90A2 for ; Thu, 21 Mar 2013 07:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6N7Mu2ogjoC for ; Thu, 21 Mar 2013 07:07:01 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD7421F90AD for ; Thu, 21 Mar 2013 07:07:01 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta13.westchester.pa.mail.comcast.net with comcast id EAt81l0031YDfWL5DE70RT; Thu, 21 Mar 2013 14:07:00 +0000 Received: from odin.ulthar.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by omta20.westchester.pa.mail.comcast.net with comcast id EE6z1l00U2Ekl483gE70jQ; Thu, 21 Mar 2013 14:07:00 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.5) with ESMTP id r2LE6vx3029734 for ; Thu, 21 Mar 2013 10:06:57 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id r2LE6vJ8029733 for dane@ietf.org; Thu, 21 Mar 2013 10:06:57 -0400 Date: Thu, 21 Mar 2013 10:06:57 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20130321140657.GB14868@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20130320213732.GA28046@mournblade.imrryr.org> <20130321035641.GA14868@odin.ulthar.us> <20130321065504.GB28046@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="uQr8t48UFsdbeI+V" Content-Disposition: inline In-Reply-To: <20130321065504.GB28046@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1363874820; bh=9SRKbSF0GdPFS21T7YoyUOErx7+Di1JvRmUAFfCvmrI=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=obdRWRwswNqOp98KXj/u3P7Mmv3RR98gDjNdT1xtlunpiWqFA0SiVqBmRqfGSbI9R KV96+7eTvlhCbdwuw3DrZUnJm6UHYh5T575Br1kfDxVFOduFvXog9xM/ftgwqFQLtp YHbNL0QHpIqKyvZirfJuGI8wM1B5SxPWI89Ev092da6yK/lnXS2DqimhyF4vBfOcRz hgIt5jlRt0uR0WAhsYl/Affxw7t0EybHv/TXpnLdxuoNEkxIeyCLKi0jyYoRHMoEqY 0jXNO30NJpTeroWYJhzZXEdNLW2gM4aXjy4J/Hhf0kThxxZ1/Cpji+EaemJL/TRohO VEXQpbcpNX69Q== Subject: Re: [dane] TA certs at depth 0? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:07:02 -0000 --uQr8t48UFsdbeI+V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 21, 2013 at 06:55:04AM +0000, Viktor Dukhovni wrote: > On Wed, Mar 20, 2013 at 11:56:41PM -0400, Scott Schmit wrote: >=20 > > > At the moment, I am not treating depth zero specially, so a trust > > > anchor's own certificate is accepted and in that case required to > > > match the MX domain or validated MX hostname. > >=20 > > Ah yes, this issue spawned a lengthy discussion a little over a year > > ago. The discussion starts here: > > https://www.ietf.org/mail-archive/web/dane/current/msg03997.html > >=20 > > The direct answer to your question might be this email here: > > https://www.ietf.org/mail-archive/web/dane/current/msg04196.html > > but it's hard to say if it does or not. Exactly how to handle the chain > > in a spec-compliant way depends on specifics of the server's > > certificate and the TA and your email doesn't really specify those > ^^^ > > details. >=20 > My question is I guess more specifically about a certusage 2 TA ( (Cutting to the chase, using the cert you provided below, I think you can defend allowing it be used with cert usage 2, read further for details.) > which is hypothetically also the server certificate, so the "and" > above is a conjunction of two references to the same thing). Right, but certificate processing/TLS code will treat different cases of that differently, depending on how they interpreted the PKIX & TLS specs. And there *is* more than one case of that: If the CA flag is set, some (most?) TLS software will reject it because it's not an EE cert. If the CA flag is not set, some PKIX software will reject it because it requires TAs to have the CA flag set. Some PKIX software will reject the certificate because the path length is 0. Others will not because they interpreted PKIX differently. In practice, it will probably work on most clients, but not all. So if you decide to accept it, you'll likely have a lot of company. That said, this widespread confusion about what the specs say will likely drive most people who aren't interested in establishing their own certificate hierarchy to usage 3 just to be sure it'll work everywhere. > I'm not looking to reopen old wounds, [...] As I recall the discussion from last time, it's more that this is a case that seems quite straightforward, but actually turns out to be a deep corner case of the various specs (despite being really widely used). The arguments end up being very technical & nit-picky & it just makes peoples' heads hurt. :-) > Should any of the DANE WG RFCs explicitly cover this ground, rather > than just defer to the rather dense 5280? These finer points of > PKIX are not obvious when one is obtaining TAs from a new source > that has its own claim to authenticity and an independent validity > interval via signed DNSSEC RRsets? ] AIUI, the PKIX WG owns the PKIX RFCs, so only they can issue updates, clarifications, etc. If the DANE WG were to try to do what you're asking, someone would inevitably think that our interpretation is inconsistent with PKIX (and thus not an interpretation), and it would get slapped down (if it didn't get slapped down out of general principal). IIRC, the reaction when we requested clarification on how self-signed certificates are handled by PKIX was that the PKIX WG feels the specs are already perfectly clear on the matter, if you read the definitions carefully. > - Does it matter whether the TLSA record is a "2 0 0" or > are we in the same boat with any "2 x y" describing the > same self-signed leaf CA/server. Somewhat -- if the TLS server omits the TA from its certificate chain but hashes it (or only provides a SPKI), and the client doesn't already know the TA certificate, then the client will have no way to match it. Diagnostics that this is why you aren't using that record might be useful, but I don't think there's any reason to hardcode "x & y aren't 0 & 0, so reject!" into your code. If the TA certificate is included in the TLS certificate chain or it's embedded in the client's TA store, it can work. > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 1 (0x1) > Signature Algorithm: ecdsa-with-SHA256 > Issuer: CN=3Dmail.example.com > Validity > Not Before: Mar 21 06:21:45 2013 GMT > Not After : Mar 21 06:21:45 2014 GMT > Subject: CN=3Dmail.example.com > Subject Public Key Info: > Public Key Algorithm: id-ecPublicKey > Public-Key: (256 bit) > pub:=20 > 04:58:4a:6a:8a:42:d6:6a:d6:33:a5:27:95:3c:8b: > a0:54:e1:9d:df:b7:99:70:76:63:7e:48:e8:d0:54: > 1a:dd:f7:69:e4:13:1e:5e:b1:13:2e:66:c6:08:4c: > 34:23:e6:84:59:e9:ec:97:fd:9b:6e:ca:e4:76:91: > 37:38:8d:6e:e9 > ASN1 OID: secp256k1 > X509v3 extensions: > X509v3 Subject Alternative Name:=20 > DNS:mail.example.com > Signature Algorithm: ecdsa-with-SHA256 > 30:44:02:20:56:c3:44:e0:10:67:f1:97:24:fc:e5:2a:fb:55: > 70:66:2c:ef:84:b6:57:7e:1d:bc:a7:1c:06:94:51:cf:7e:5c: > 02:20:64:95:f8:fa:74:d8:b3:c1:f5:1e:54:71:45:2a:a4:ab: > 89:23:6e:1a:f6:17:a2:22:f7:50:cd:00:bc:f5:3b:de Based on my understanding of PKIX, this should work (as long as your software supports ECDSA): Only the key & name matter on a TA, but other checks are a matter of local policy. It's an EE certificate, because there's no basic constraint saying that this is a CA (and the certificate is X.509v3), so it's legal for a server named mail.example.com to use as its certifiate in TLS. It's self-signed, so if I interpret the chain as mail.example.com (as TA) -> mail.example.com (as EE), then I have a path length of 1, and it's legal. (But that might depend on specifics of how path length is determined.) Depending on how you interepret the definition of the certificate chain in the TLS RFC, maybe we're supposed to transmit both certs in the chain (i.e., the same certificate twice). But I think if the client has the full certificate via TLSA, then the TA is "well-known" to that client and can be omitted from the chain. So I can't see any reason to reject this certificate, even being spec-pedantic. Does that help? --=20 Scott Schmit --uQr8t48UFsdbeI+V Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQBAYJKoZIhvcNAQcCoIIP9TCCD/ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DTUwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBvkwggXhoAMCAQICAwR4CjANBgkqhkiG 9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDcwNDEz NTc1MVoXDTEzMDcwNTA1MjcyNlowQDEbMBkGA1UEAwwSaS5ncm9rQGNvbWNhc3QubmV0MSEw HwYJKoZIhvcNAQkBFhJpLmdyb2tAY29tY2FzdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCxn+QJTgdUJ1RAOi6JbFsDfl21ZX/OPx/ttuXWQP1vWwBZybHU+4/+bRXH 5ONhjbc5ikZvz/E406iQLy2xMT5PI/hx4uIZQQYpkjxd4rCbbvLNACz5L+cFaGj4WfGwAXDv bw4nx8Mh3WjbR5yjBCWYqadiv7HWAWmhaJmuaTp/e+mO2EEOOdoNQ8b2mxMyN43TlElx6Zos t7g/eQUcLWgTB5apPhowCCGnFU6uHK053QsPmsmZ67gg8acpb5ic0+P+X1j+IgD3jcsDzjrF TPlrvU4ZuBYQJISqngbc2ua/uutx75Xs4iFXWNRlnYfZMFJy96USzrhIBRqcORrjbyGXAgMB AAGjggOtMIIDqTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcD AgYIKwYBBQUHAwQwHQYDVR0OBBYEFAxkdHPHW3mhf+gXJjezdazgoDRuMB8GA1UdIwQYMBaA FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB0GA1UdEQQWMBSBEmkuZ3Jva0Bjb21jYXN0Lm5ldDCC AiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3 YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVt ZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUg aW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9i bGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBT ZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9h aWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBACJi0f4m 0bSVq+pq4AHeC2Rj4S8rciW+Uce6LC69UlyVMijKv/pZNFM08vqRXEI9WpKQhKXacJ+rK9az DBmnxq1scqKhn7991V6Yt2t0tEY8vUX7q330GybUB/rQLNrh66GFXaEWU/S692pGzvUXeV+w zz48snMpoMHQdxkHHW5sQkpo99SF/vOA5/sqvFmJ+ai1iDRjtKcChjkmAtFmCKv/dNrXnvew 5+QnLlnE/TsW4Sdv3bcLdlthD4eavS3BdgXfX7dfj0ykel53J2Us3CikNbyuCsJpwMH+gX1j LcXZOYIDLzZXCFEOFajhgsAZ5JQrW0fFRxjGIp8Rs+rxdFwxggKXMIICkwIBATCBlDCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEeAowCQYFKw4DAhoFAKCB2DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAzMjExNDA2NTdaMCMG CSqGSIb3DQEJBDEWBBQW++o0wIZ4S8bR9b5U/5CDHyAjODB5BgkqhkiG9w0BCQ8xbDBqMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq hkiG9w0BAQEFAASCAQB1MGgBsOLP63drXA31bITS5Hwzpbnp67f+mZJb1qa+HRoa5WOjefRb XMmZ2zmQPkV0KBl62OYCx0R7oQLg6j5mXrYpnasAIEu06bZeUQqiYzQpygrx2ZCvnsTgvK7T r1uvrMES4XhBa9uXWwRjwktyIaUNXAziszr5Z7mKAOLkJAZRPgmiBBxrpDlpfF+UDdv8GlvB qhCqSQLLZdTq/783mhVjWAs2eDpuWTWnaaRUkgvc4Y0sM+DvT/1yr1E/uf4JPqdbzuB/zUDe xFZ3/PVjH1/BvPUuTPBPww+hd2VNzNEVi+YnOOMQOWZ4FGd2entMjb3wjVAIPPnhARcpGdkQ --uQr8t48UFsdbeI+V-- From viktor1dane@dukhovni.org Thu Mar 21 12:28:47 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486AC21F8CA4 for ; Thu, 21 Mar 2013 12:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CB4HF7N8lOQl for ; Thu, 21 Mar 2013 12:28:46 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 998F321F85A0 for ; Thu, 21 Mar 2013 12:28:43 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BA6F82AAE1C; Thu, 21 Mar 2013 19:28:42 +0000 (UTC) Date: Thu, 21 Mar 2013 19:28:42 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130321192842.GC28046@mournblade.imrryr.org> References: <20130320213732.GA28046@mournblade.imrryr.org> <20130321035641.GA14868@odin.ulthar.us> <20130321065504.GB28046@mournblade.imrryr.org> <20130321140657.GB14868@odin.ulthar.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130321140657.GB14868@odin.ulthar.us> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] TA certs at depth 0? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 19:28:47 -0000 On Thu, Mar 21, 2013 at 10:06:57AM -0400, Scott Schmit wrote: [ Quoting your last paragraph first: ] > So I can't see any reason to reject this certificate, even being > spec-pedantic. > > Does that help? Yes, thanks, I think I can largely go with what I have, what remains to verify is the first part of the side question from my original post: [ I guess I should also ask whether the expiration dates of non-degenerate TA certificates matter with "IN TLSA 2 x y" resource records. At the moment I don't accept expired TA certs. ] So, with certificate usage 2, should I allow "expired" TA certs at depth > 0? If the TA is to be viewed as just a public-key in X.509 garb, and in view of the fact that the expiration times are set by some entity I may not trust (trust starts at the TA), perhaps not? On the other hand if the TA is actually self-signed, then its own statement about expiration times could be taken at face value (as OpenSSL does with self-signed trust anchors in its trust store). Bottom line, should I allow expired TA certs, and does it matter whether they are self-signed. > > which is hypothetically also the server certificate, so the "and" > > above is a conjunction of two references to the same thing). > > Right, but certificate processing/TLS code will treat different cases of > that differently, depending on how they interpreted the PKIX & TLS > specs. And there *is* more than one case of that: Checking the OpenSSL x509_vfy.c source I find that: - The expiration time of a self-signed issuer certificates (at any depth including 0) is *not* ignored. So with a typical trust chain starting at a public root CA, the root CA's expiration time is honoured. - OpenSSL ignores the "CA:true" vs. "CA:false" for depth 0 self-signed certificates. I'll go along with that. > If the CA flag is set, some (most?) TLS software will reject it because > it's not an EE cert. FWIW, OpenSSL (which Postfix uses for TLS+X509 support) does not care at the leaf. > It's an EE certificate, because there's no basic constraint saying that > this is a CA (and the certificate is X.509v3), so it's legal for a > server named mail.example.com to use as its certifiate in TLS. I'm going to let OpenSSL ignore the CA bit for me. That way I don't have to parse the X509 cert myself in the verification callback. And name checks will still apply. -- Viktor. From viktor1dane@dukhovni.org Thu Mar 21 17:07:26 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC37E21F8626 for ; Thu, 21 Mar 2013 17:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSZeDxTO-HVp for ; Thu, 21 Mar 2013 17:07:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 50F7921F85EE for ; Thu, 21 Mar 2013 17:07:26 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4CFE22AAE1C; Fri, 22 Mar 2013 00:07:25 +0000 (UTC) Date: Fri, 22 Mar 2013 00:07:25 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130322000725.GF28046@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] IN TLSA 2 0 0 and handshake trust chain? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 00:07:26 -0000 Are servers that publish their trust anchor details via DNS in full: _25._tcp.mail.example.com. IN TLSA 2 0 0 exempt from being obligated to provide the same certificate somewhere in their trust chain? It is far easier to treat the "2 0 0" case as a more specific bulky match blob, than to also arrange for it to be an input into the client's trust chain construction algorithm. The latter is largely impractical with OpenSSL. I though I saw some text in the RFC about "2 x y" trust-anchors needing to be explicitly provided in the server's trust chain, since clients cannot be expected to already have these on hand. Can't seem to find it any more. I am hoping that the above includes the "2 0 0" case, for though the cert is available in DNS it is not in the trust chain or trust store, and moving it from the DNS into the trust chain or trust store is non-trivial. I am also hoping that almost nobody will use match type 0 certs, and that in practice all TLSA records will be sha2 digests. If verifiers are obligated to attempt to use the certificate in "2 0 0" as part of the trust chain if missing, then I may need to treat "2 0 0" as "unusable" until OpenSSL makes it possible to configure each connection with a private list of additional trust anchors before starting the handshake (without polluting the trust store for future connections that use the same persistent SSL_CTX). -- Viktor. From stpeter@stpeter.im Thu Mar 21 18:23:09 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFE521F8B7E for ; Thu, 21 Mar 2013 18:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZiZBtxuM2hw for ; Thu, 21 Mar 2013 18:23:09 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E459821F89AA for ; Thu, 21 Mar 2013 18:23:08 -0700 (PDT) Received: from [192.168.1.8] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E820140C2E; Thu, 21 Mar 2013 19:32:11 -0600 (MDT) Message-ID: <514B860E.80003@stpeter.im> Date: Thu, 21 Mar 2013 15:13:34 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: IETF DANE WG list X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dane] terminology in draft-ietf-dane-srv X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 01:23:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Regarding draft-ietf-dane-srv, I think it would be good to agree on our terminology in this space. For example, RFC 6125 uses the terms "source domain" and "derived domain" whereas draft-ietf-dane-srv uses the terms "service domain" and "target server host name". Jeff Hodges and I tried to make our terminology in RFC 6125 both clear and consistent with RFC 2782. If we failed in that regard, please let us know (we do plan to work on 6125bis at some point). If not, I suggest that we try to align draft-ietf-dane-srv with RFC 6125. Thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRS4YNAAoJEOoGpJErxa2prm4P/2qIKZBfvUOrXe3iB9lEysa8 OOJ6qKYZe69YADT87TENR7sAn0Krktw2grxXxknMXSfDkSnd9yGFzdicy0EVuIRm apPTkiOFmt+VJhlieA1vWn3sfauFNujw3MpmNyGR8TkwMbTlU47tcONDcmm3+c67 JWv6ZTgyHTizzmFmXTYfReNYuNDBgsAI8MZxVlOFXt3biYPtgK7MdEf3AawnEGce jEggzt/r43kcCIUFuwFkJluS+m5GqLOgGPB32nYviwcdyxF40tbb1V48TLKgLEOI s6NUo7wMqjTxxOiJXFLFyvsq72mWPU3DiROswBtDteI1/MNzfho55/U2OavmJUqU U21zbn9DowGwNiXqYnorW/1h/tsBZ+y82zhCMw1GLpItG/E7xizfk+ZzyFw8/M0Q OqpiwHx55hiB16wLcj7PBmlkhgyg3CaJPIi3NhU2S7SfaSOZeLxaxwv1gKumZ7WS V+8rEcaC2qdjqFi4K4/AiPJfvZJb0Unt4YKy9iudc4Yga3fy9KqGj+lGqYeGFmaQ AyWj68I9LZgGbLQrWFFkMysSZt9a2BKqmynztLV6tiuxEo3TCZYh08XJYmAFPnhj f5JU3u8C8xQH08qnsLg5mvF0hPvHCoedXyOOwVzt3gLYPU3LukUSLrDYDmCUyr3I c97b+auRp1hhD/WCLRGp =8Zfq -----END PGP SIGNATURE----- From fanf2@hermes.cam.ac.uk Fri Mar 22 04:36:54 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C8521F84D9 for ; Fri, 22 Mar 2013 04:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZHdoq3Kwyu5 for ; Fri, 22 Mar 2013 04:36:53 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC8421F84D8 for ; Fri, 22 Mar 2013 04:36:53 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:59364) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1UJ0H9-0005Ix-RG (Exim 4.72) (return-path ); Fri, 22 Mar 2013 11:36:47 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UJ0H9-0000Ev-C8 (Exim 4.72) (return-path ); Fri, 22 Mar 2013 11:36:47 +0000 Date: Fri, 22 Mar 2013 11:36:47 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Peter Saint-Andre In-Reply-To: <514B860E.80003@stpeter.im> Message-ID: References: <514B860E.80003@stpeter.im> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: IETF DANE WG list Subject: Re: [dane] terminology in draft-ietf-dane-srv X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 11:36:54 -0000 Peter Saint-Andre wrote: > > Regarding draft-ietf-dane-srv, I think it would be good to agree on > our terminology in this space. Yes. > For example, RFC 6125 uses the terms "source domain" and "derived > domain" whereas draft-ietf-dane-srv uses the terms "service domain" and > "target server host name". Jeff Hodges and I tried to make our > terminology in RFC 6125 both clear and consistent with RFC 2782. If we > failed in that regard, please let us know (we do plan to work on 6125bis > at some point). If not, I suggest that we try to align > draft-ietf-dane-srv with RFC 6125. I think I would prefer to stay closer to RFC 2782 terms, something like "SRV Name field" and "SRV Target field", perhaps. As I understand it, the RFC 6125 terms are generic, intended to apply to more situations than just SRV indirections. I want to keep this spec as concrete and direct as I can. The reason for the current terminology is that I want to emphasize the difference between host names (to which TLSA records are related) and domain names (a more general concept). There is also some hangover from the earlier MX-specific version, where "mail domain" and "MX target host name" is fairly normal terminology. Thank you for the feedback. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From viktor1dane@dukhovni.org Fri Mar 22 09:51:36 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A0621F8DDC for ; Fri, 22 Mar 2013 09:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9SgaLB-ARHO for ; Fri, 22 Mar 2013 09:51:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id DBC7921F8928 for ; Fri, 22 Mar 2013 09:51:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2A85A2AB90A; Fri, 22 Mar 2013 16:51:34 +0000 (UTC) Date: Fri, 22 Mar 2013 16:51:34 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130322165133.GG28046@mournblade.imrryr.org> References: <20130322000725.GF28046@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130322000725.GF28046@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] IN TLSA 2 0 0 and handshake trust chain? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 16:51:36 -0000 On Fri, Mar 22, 2013 at 12:07:25AM +0000, Viktor Dukhovni wrote: Any comments at all on the below? It is tempting to simply treat "IN TLSA x 0 0" as "unusable", for all "x", and thereby discourage the notion that it is a good practice to deliver full certificates via DNS, instead of the TLS handshake... > Are servers that publish their trust anchor details via DNS in full: > > _25._tcp.mail.example.com. IN TLSA 2 0 0 > > exempt from being obligated to provide the same certificate somewhere > in their trust chain? It is far easier to treat the "2 0 0" case > as a more specific bulky match blob, than to also arrange for it > to be an input into the client's trust chain construction algorithm. > > The latter is largely impractical with OpenSSL. I thought I saw > some text in the RFC about "2 x y" trust-anchors needing to be > explicitly provided in the server's trust chain, since clients > cannot be expected to already have these on hand. Can't seem > to find it any more. FWIW, I have a practical solution for OpenSSL, but I'd rather not have to field it. > I am hoping that the above includes the "2 0 0" case, for though > the cert is available in DNS it is not in the trust chain or trust > store, and moving it from the DNS into the trust chain or trust > store is non-trivial. > > I am also hoping that almost nobody will use match type 0 certs, > and that in practice all TLSA records will be sha2 digests. > > If verifiers are obligated to attempt to use the certificate in > "2 0 0" as part of the trust chain if missing, then I may need > to treat "2 0 0" as "unusable" until OpenSSL makes it possible > to configure each connection with a private list of additional > trust anchors before starting the handshake (without polluting > the trust store for future connections that use the same > persistent SSL_CTX). So no new OpenSSL library code is required to support this, if one stares at the (lightly documented) OpenSSL API hard enough, but still "IN TLSA x 0 0" looks unwieldy. -- Viktor. From guido@witmond.nl Fri Mar 22 11:33:03 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA7D21F8E7D for ; Fri, 22 Mar 2013 11:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax9jCgP640-m for ; Fri, 22 Mar 2013 11:33:02 -0700 (PDT) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by ietfa.amsl.com (Postfix) with ESMTP id D165D21F87B6 for ; Fri, 22 Mar 2013 11:33:01 -0700 (PDT) Received: from [10.1.2.6] (mail.witmond.nl [80.100.189.3] (may be forged)) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id r2MIWtJI037935; Fri, 22 Mar 2013 19:32:59 +0100 (CET) (envelope-from guido@witmond.nl) Message-ID: <514CA361.9020408@witmond.nl> Date: Fri, 22 Mar 2013 19:30:57 +0100 From: Guido Witmond User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: viktor1dane@dukhovni.org, dane@ietf.org References: <20130322000725.GF28046@mournblade.imrryr.org> <20130322165133.GG28046@mournblade.imrryr.org> In-Reply-To: <20130322165133.GG28046@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [dane] IN TLSA 2 0 0 and handshake trust chain? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 18:33:03 -0000 On 03/22/2013 05:51 PM, Viktor Dukhovni wrote: > On Fri, Mar 22, 2013 at 12:07:25AM +0000, Viktor Dukhovni wrote: > > Any comments at all on the below? It is tempting to simply treat > "IN TLSA x 0 0" as "unusable", for all "x", and thereby discourage > the notion that it is a good practice to deliver full certificates > via DNS, instead of the TLS handshake... > >> Are servers that publish their trust anchor details via DNS in full: >> >> _25._tcp.mail.example.com. IN TLSA 2 0 0 >> >> exempt from being obligated to provide the same certificate somewhere >> in their trust chain? It is far easier to treat the "2 0 0" case >> as a more specific bulky match blob, than to also arrange for it >> to be an input into the client's trust chain construction algorithm. >> >> The latter is largely impractical with OpenSSL. I thought I saw >> some text in the RFC about "2 x y" trust-anchors needing to be >> explicitly provided in the server's trust chain, since clients >> cannot be expected to already have these on hand. Can't seem >> to find it any more. >> I am hoping that the above includes the "2 0 0" case, for though >> the cert is available in DNS it is not in the trust chain or trust >> store, and moving it from the DNS into the trust chain or trust >> store is non-trivial. >> >> I am also hoping that almost nobody will use match type 0 certs, >> and that in practice all TLSA records will be sha2 digests. >> >> If verifiers are obligated to attempt to use the certificate in >> "2 0 0" as part of the trust chain if missing, then I may need >> to treat "2 0 0" as "unusable" until OpenSSL makes it possible >> to configure each connection with a private list of additional >> trust anchors before starting the handshake (without polluting >> the trust store for future connections that use the same >> persistent SSL_CTX). > > So no new OpenSSL library code is required to support this, if one > stares at the (lightly documented) OpenSSL API hard enough, but > still "IN TLSA x 0 0" looks unwieldy. > I use the 2-0-0 right now to set the TLS-context to that certificate only. (No global CA's), so that only server certificates signed with that certificate will pass validation. The connection fails if the server certificate doesn't match when my connection is hijacked with a MitM. If I understand you correctly, dropping TLSA 2 0 0 (full certificates) means that I would have to connect to a server, learn its certificates in the handshake and then perform the hash verification against the TLSA-record. It could tempt some into adding a 'override tlsa-record validation' button later. That road leads to the madness we give to our browser users. People who are unable to make a good decision, especially if the rendered page (with the wrong certificate) looks like a bank-page with a large transaction pending. (phishing). I have a very good use case to set the 2-0-0 certificate as the only certificate in the session connection context. It allows clients to limit their connections only to servers signed with the certificate from the TLSA-record. I call it Cryptographic Same Origin Policy. Please see: http://witmond.nl/ecca/eccentric-authentication.html I humble believe that creating a new session context (with just a single CA-cert) for each session is the way forward. Having a single certificate store is the old way of the global 'Trusted' CAs. I remember the pain of doing that in Firefox with NSS. It's easy in Go-lang. Cheers, Guido. From viktor1dane@dukhovni.org Fri Mar 22 12:30:28 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C01721F8E7F for ; Fri, 22 Mar 2013 12:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ2nxIxhmmHb for ; Fri, 22 Mar 2013 12:30:27 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id A27CA21F8E11 for ; Fri, 22 Mar 2013 12:30:27 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F15B42AB90A; Fri, 22 Mar 2013 19:30:26 +0000 (UTC) Date: Fri, 22 Mar 2013 19:30:26 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130322193026.GH28046@mournblade.imrryr.org> References: <20130322000725.GF28046@mournblade.imrryr.org> <20130322165133.GG28046@mournblade.imrryr.org> <514CA361.9020408@witmond.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <514CA361.9020408@witmond.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] IN TLSA 2 0 0 and handshake trust chain? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 19:30:28 -0000 On Fri, Mar 22, 2013 at 07:30:57PM +0100, Guido Witmond wrote: > > So no new OpenSSL library code is required to support this, if one > > stares at the (lightly documented) OpenSSL API hard enough, but > > still "IN TLSA x 0 0" looks unwieldy. [ I should probably mention that my issue is even worse with "2 1 0". I now have the public key of the TA, but as with "2 0 0" potentially no TA certificate either in the server trust chain, or in the system trust store. So now I need a new API to validate trust chains starting from just a public key (which is worse than with "2 0 0", where I need to inject a possibly missing TA certificate into the trust chain.). ] > I use the 2-0-0 right now to set the TLS-context to that certificate > only. Why "2 0 0" and not "2 1 1" (with the certificate configured in your server chain)? So that instead of the TA cert coming from DNS, it is explicitly included in the server's SSL/TLS HELO (response)? > (No global CA's), so that only server certificates signed with > that certificate will pass validation. The connection fails if the > server certificate doesn't match when my connection is hijacked with > a MitM. The effect of "2 1 1" is the same, but the DNS data is much more sensible, and the TA certificate is supplied during the SSL handshake inline, rather than out-of-band via DNS. > If I understand you correctly, dropping TLSA 2 0 0 (full > certificates) means that I would have to connect to a server, learn > its certificates in the handshake and then perform the hash > verification against the TLSA-record. Yes, you have to connect to the server either way. With "2 0 0" the trust-anchor certificate is out-of-band in DNS, and the handshake might omit the TA cert from the server response (send only the stuff signed by the TA down to the leaf). With "2 1 1" just the TA fingerprint is in DNS and the actual TA cert is in the TLS handshake. "2 1 1" does not tax DNS caches, especially when servers have certs from multiple CAs and perhaps multiple versions of a CA when key rollover happens. And it dramatically simplifies client-side implementation, when the TA is not already in the system store. > It could tempt some into > adding a 'override tlsa-record validation' button later. This is a non-sequitur. > I have a very good use case to set the 2-0-0 certificate as the only > certificate in the session connection context. It allows clients to > limit their connections only to servers signed with the certificate > from the TLSA-record. Why is this better than "2 1 1". > I call it Cryptographic Same Origin Policy. How does "2 1 1" fail to serve the same need, with the server trust chain containing the cert you publish via DNS? A deployment guide for DANE should likely specify that domain owners publishing "2 1 1" or "2 0 1" TLSA records MUST include the TA cert in the server's configured trust chain. The "x y 0" RRs are a pain to implement, and substantially increase the effectiveness of DNS reply amplification attacks. > I humbly believe that creating a new session context (with just a > single CA-cert) for each session is the way forward. Having a single > certificate store is the old way of the global 'Trusted' CAs. I seems you're somehow confused, or I'm not understanding your reply. The "3 1 1" and "2 1 1" use cases cover everything other than how the mechanism for conveying the TA issuing certificate. -- Viktor. From cloos@jhcloos.com Sat Mar 23 14:29:52 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6701121F892D for ; Sat, 23 Mar 2013 14:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=0.803, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHllMsljoJhL for ; Sat, 23 Mar 2013 14:29:52 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2604:8800:100:81ca::53]) by ietfa.amsl.com (Postfix) with ESMTP id D660621F877A for ; Sat, 23 Mar 2013 14:29:51 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 71687402CF; Sat, 23 Mar 2013 21:29:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1364074185; bh=fJDCWu+ugknTPqYpxLo2Zq0fKakfnT8qLrk/xsJjnNY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=oCEtRLkiKXb+rFTvuKd92oLvuLMAO4DWbDgATkwc/w9EluvmSYtXGmwRGHyc3C87d RJXn8qBs2GJ/aCYuVeJwD0KXsnPPLtLZ4p7KVeYMgN1kmfOZ2aV8UGvBcxPmjR7bkT QHmem+aZdhjUWj+/acXgHKl1VNSvny+zjlMzvDNQ= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 5DCFA60028; Sat, 23 Mar 2013 21:23:41 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20130322000725.GF28046@mournblade.imrryr.org> (Viktor Dukhovni's message of "Fri, 22 Mar 2013 00:07:25 +0000") References: <20130322000725.GF28046@mournblade.imrryr.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sat, 23 Mar 2013 17:23:41 -0400 Message-ID: Lines: 35 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:130323:viktor1dane@dukhovni.org::qBHdcoaJ7wrrj8h5:000000000000000000000000000000000000hA4VP X-Hashcash: 1:30:130323:dane@ietf.org::On8lOts2kW+QgTsU:000N7lju Cc: dane@ietf.org Subject: Re: [dane] IN TLSA 2 0 0 and handshake trust chain? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 21:29:52 -0000 >>>>> "VD" == Viktor Dukhovni writes: Fist of all, thank you for all of the questions. Questions from implementors are an important part of the process and the ensuing dialog should help tlsa progress towards Full Standard. VD> Are servers that publish their trust anchor details via DNS in full: VD> _25._tcp.mail.example.com. IN TLSA 2 0 0 VD> exempt from being obligated to provide the same certificate somewhere VD> in their trust chain? I had a probably too long answer written, but after reading the rfc a couple more times, and notwithstanding our early discussion here (some of which would have supported permitting elision), I've concluded that the text in §2.1.1: ,----< 2 -- Certificate usage 2 ... > | The target certificate MUST pass PKIX certification path validation, | with any certificate matching the TLSA record considered to be a | trust anchor for this certification path validation. `---- means that the cert has to be included in the tls startup negotiation; it cannot be elided. VD> I am also hoping that ... in practice all TLSA records will be VD> sha2 digests. Sha2 matches should be documented as the Best Practice for TLSA. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From viktor1dane@dukhovni.org Sat Mar 23 17:52:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FAD21F8CCE for ; Sat, 23 Mar 2013 17:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTYs20JfGziC for ; Sat, 23 Mar 2013 17:52:15 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 6A94421F8C9B for ; Sat, 23 Mar 2013 17:52:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2142F2AB3BD; Sun, 24 Mar 2013 00:52:14 +0000 (UTC) Date: Sun, 24 Mar 2013 00:52:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130324005213.GJ28046@mournblade.imrryr.org> References: <20130322000725.GF28046@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] IN TLSA 2 0 0 and handshake trust chain? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 00:52:16 -0000 On Sat, Mar 23, 2013 at 05:23:41PM -0400, James Cloos wrote: > VD> Are servers that publish their trust anchor details via DNS in full: > VD> _25._tcp.mail.example.com. IN TLSA 2 0 0 > VD> exempt from being obligated to provide the same certificate somewhere > VD> in their trust chain? > > I had a probably too long answer written, but after reading the rfc a > couple more times, and notwithstanding our early discussion here (some > of which would have supported permitting elision), I've concluded that > the text in ?2.1.1: > > ,----< 2 -- Certificate usage 2 ... > > | The target certificate MUST pass PKIX certification path validation, > | with any certificate matching the TLSA record considered to be a > | trust anchor for this certification path validation. > `---- > > means that the cert has to be included in the tls startup negotiation; > it cannot be elided. I take it you read the phrase "with any certificate matching the TLSA record... " to mean that such a certificate must come from the server in the server SSL HELO. If I squint hard enough, I can read it the same way, but I could also suppose that the PKIX validation path in question was in part constructed by the verifier, and so no explicit requirement for the server to provide the certificate. This should probably be spelled out more completely in an implementation guideline section, or similar. The above is rather subtle. Since of course with usage 2 there is no presumption that the verifying client has the TA public key (or equivalently a certificate containing it) already in hand, the requirement to include the certificate in the trust chain should I think be more explicit. At some noticeable complexity cost (though not a lot of lines of code), I've added full support for "2 0 0" and "2 1 0" TLSA records, so now I can verify trust chains that omit the corresponding issuing certificate and begin with something signed by the TA. > VD> I am also hoping that ... in practice all TLSA records will be > VD> sha2 digests. > > Sha2 matches should be documented as the Best Practice for TLSA. So at this point what I have is: - Full support for "IN TLSA [13] x y ..." for all x, y. - Full support for "IN TLSA [02] x 0 ..." for all x. - Support for "IN TLSA 2 x [12] ..." for all x, provided it is clear from the RFC that the server is obligated to include the TA cert in its server SSL HELO (reply). If this is not clear, then I might need to treat "IN TLSA 2 x [12] ..." as "unusable". [ If mail to enough sites fails because domain owners are having trouble creating a usable configuration, senders will not want to enable DANE TLSA support. There should be no subtle traps for domain owners publishing TLSA records. ] If the RFC does not clearly require "IN TLSA 2 x [12] ..." to mandate the TA cert in server's SSL HELO, then I'll have to go with "2 x [12]" as "unusable". - I likely have to treat "0 x [12]" as "unusable", because when the TA in the association is a public root CA, they will typically (common practice pre-DANE) not include the TA cert in their trust chain. I cannot require Postfix MTAs to have every single public CA in their CAfile, this is a non-starter. So "0 x [12]" will fall back to mandatory TLS with no authentication. I can only improve on qualified support for: IN TLSA 0 0 1 - Trust anchor cert likely not available in server HELO IN TLSA 0 0 2 - ... IN TLSA 0 1 1 - ... IN TLSA 0 1 2 - ... IN TLSA 2 0 1 - Trust anchor cert in SSL HELO may not be RFC mandated IN TLSA 2 0 2 - ... IN TLSA 2 1 1 - ... IN TLSA 2 1 2 - ... if the RFC requires conforming server implementations to always include the TA certificate in their SSL HELO (reply) trust chain. I expect that progress on the "IN TLSA 2 x [12] ..." front is possible, by clarifying the RFC text. I would guess that I'll find resistance on the "IN TLSA 0 x [12] ..." front, so support for that will likely not be available in Postfix. -- Viktor. From viktor1dane@dukhovni.org Sat Mar 23 19:44:23 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B78E21F8C85 for ; Sat, 23 Mar 2013 19:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN7WrFdTcqe5 for ; Sat, 23 Mar 2013 19:44:22 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 6A96221F8C84 for ; Sat, 23 Mar 2013 19:44:22 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 986DA2AB3BD; Sun, 24 Mar 2013 02:44:12 +0000 (UTC) Date: Sun, 24 Mar 2013 02:44:12 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130324024412.GK28046@mournblade.imrryr.org> References: <20130320213732.GA28046@mournblade.imrryr.org> <20130321035641.GA14868@odin.ulthar.us> <20130321065504.GB28046@mournblade.imrryr.org> <20130321140657.GB14868@odin.ulthar.us> <20130321192842.GC28046@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130321192842.GC28046@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] TA certs at depth 0? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 02:44:23 -0000 On Thu, Mar 21, 2013 at 07:28:42PM +0000, Viktor Dukhovni wrote: > > So I can't see any reason to reject this certificate, even being > > spec-pedantic. > > > > Does that help? > > Yes, thanks, I think I can largely go with what I have, what remains > to verify is the first part of the side question from my original post: > > [ I guess I should also ask whether the expiration dates of > non-degenerate TA certificates matter with "IN TLSA 2 x y" > resource records. At the moment I don't accept expired TA certs. ] In the end, the implementation of "IN TLSA 2 1 0" and "IN TLSA 3 1 0" leads me to treat TAs per PKIX/ITU as just public keys, and thus I no longer check expiration dates in TA certs. I had to put in a snippet of extra code to support zero-length "IN TLSA 2 1 0" chains, which are somewhat easier to reject than to accept, but the primary requirement for SMTP security is to not fail whenever success is an option, so "IN TLSA 2 0 0" will also be supported at depth 0, provided the server's certificate is self-signed. -- Viktor. From guido@witmond.nl Sun Mar 24 09:00:14 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3427421F8D59 for ; Sun, 24 Mar 2013 09:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdrHjlUKder7 for ; Sun, 24 Mar 2013 09:00:13 -0700 (PDT) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1447221F8D7A for ; Sun, 24 Mar 2013 09:00:11 -0700 (PDT) Received: from [10.1.2.6] (mail.witmond.nl [80.100.189.3] (may be forged)) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id r2OG0AJ1074872 for ; Sun, 24 Mar 2013 17:00:10 +0100 (CET) (envelope-from guido@witmond.nl) Message-ID: <514F2291.30802@witmond.nl> Date: Sun, 24 Mar 2013 16:58:09 +0100 From: Guido Witmond User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: dane@ietf.org References: <20130322000725.GF28046@mournblade.imrryr.org> <20130322165133.GG28046@mournblade.imrryr.org> <514CA361.9020408@witmond.nl> <20130322193026.GH28046@mournblade.imrryr.org> In-Reply-To: <20130322193026.GH28046@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [dane] IN TLSA 2 0 0 and handshake trust chain? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 16:00:14 -0000 On 03/22/2013 08:30 PM, Viktor Dukhovni wrote: > On Fri, Mar 22, 2013 at 07:30:57PM +0100, Guido Witmond wrote: > >>> So no new OpenSSL library code is required to support this, if one >>> stares at the (lightly documented) OpenSSL API hard enough, but >>> still "IN TLSA x 0 0" looks unwieldy. > > I seems you're somehow confused, or I'm not understanding your > reply. The "3 1 1" and "2 1 1" use cases cover everything other > than how the mechanism for conveying the TA issuing certificate. > To clear up any confusion, I wanted to give an example of why I use 2-0-0 full certificates and I'm not convinced to give them up, yet. Although your DNS-cache arguments are quite compelling. thanks, Guido. From guido@witmond.nl Sun Mar 24 14:46:12 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A02D21F8DA2 for ; Sun, 24 Mar 2013 14:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.725 X-Spam-Level: X-Spam-Status: No, score=0.725 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40wWz6RvfjlR for ; Sun, 24 Mar 2013 14:46:11 -0700 (PDT) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by ietfa.amsl.com (Postfix) with ESMTP id 15CE021F8D7A for ; Sun, 24 Mar 2013 14:46:10 -0700 (PDT) Received: from [10.1.2.6] (mail.witmond.nl [80.100.189.3] (may be forged)) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id r2OLk9nL046385 for ; Sun, 24 Mar 2013 22:46:09 +0100 (CET) (envelope-from guido@witmond.nl) Message-ID: <514F73A7.7080300@witmond.nl> Date: Sun, 24 Mar 2013 22:44:07 +0100 From: Guido Witmond User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [dane] A DANE Application - Cryptographic Same Origin Policy X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 21:46:12 -0000 Hello Everyone, In my quest to replace passwords with client certificates I've come up with a way to replace the current hostname:port based Same Origin Policy with one based upon Public Key Cryptography. It wasn't possible with the global CAs as they only certify a domain name. But with DNSSEC and DANE, not only can we *safely* use self signed certificates for our servers, we can run our own CA and sign our server certificate with that. When we *restrict* the use of our own CA to sign *only* the servers that we control, we tie them together into a group *identified* by our local CA's Root Certificate. Browsers can check whether resources on a page are signed with the same CA. If so (and if it's not a global CA), the browser can decide to place these resources in a single trust domain. Resources not signed by our own local CA are placed in a different (lower) trust domain. The browser can run our javascript application, say web mail or photo manipulation safely while avoiding a hostile javascript from a spying or hacked advertisement platform. I call it the Cryptographic Same Origin Policy. For details please read [1] With regards, Guido Witmond. [1] http://witmond.nl/blog/2013/03/23/Cryptographic-same-origin-policy.html From viktor1dane@dukhovni.org Tue Mar 26 01:22:25 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C984B21F898A for ; Tue, 26 Mar 2013 01:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPCX38l7uPPf for ; Tue, 26 Mar 2013 01:22:22 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id CE9E821F89D8 for ; Tue, 26 Mar 2013 01:22:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E5A4B2AB685; Tue, 26 Mar 2013 08:22:19 +0000 (UTC) Date: Tue, 26 Mar 2013 08:22:19 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130326082219.GS28046@mournblade.imrryr.org> References: <20130322000725.GF28046@mournblade.imrryr.org> <20130324005213.GJ28046@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130324005213.GJ28046@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] IN TLSA 2 0 0 and handshake trust chain? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 08:22:25 -0000 On Sun, Mar 24, 2013 at 12:52:14AM +0000, Viktor Dukhovni wrote: > > ,----< 2 -- Certificate usage 2 ... > > > | The target certificate MUST pass PKIX certification path validation, > > | with any certificate matching the TLSA record considered to be a > > | trust anchor for this certification path validation. > > `---- > > > > means that the cert has to be included in the tls startup negotiation; > > it cannot be elided. > > I take it you read the phrase "with any certificate matching the > TLSA record... " to mean that such a certificate must come from > the server in the server SSL HELO. If I squint hard enough, I can > read it the same way, but I could also suppose that the PKIX > validation path in question was in part constructed by the verifier, > and so no explicit requirement for the server to provide the > certificate. This looks even more important with "2 1 0", since we find in: https://tools.ietf.org/html/rfc5280#section-6.1.1 (d) trust anchor information, describing a CA that serves as a trust anchor for the certification path. The trust anchor information includes: (1) the trusted issuer name, (2) the trusted public key algorithm, (3) the trusted public key, and (4) optionally, the trusted public key parameters associated with the public key. and in https://tools.ietf.org/html/rfc5280#section-6.1 (b) certificate 1 is issued by the trust anchor; Since, as James points out, we have in: https://tools.ietf.org/html/rfc6698#section-2.1.1 2 -- Certificate usage 2 is used to specify a certificate, or the public key of such a certificate, that MUST be used as the trust anchor when validating the end entity certificate given by the server in TLS. This certificate usage is sometimes referred to as "trust anchor assertion" and allows a domain name administrator to specify a new trust anchor -- for example, if the domain issues its own certificates under its own CA that is not expected to be in the end users' collection of trust anchors. The target certificate MUST pass PKIX certification path validation, with any certificate matching the TLSA record considered to be a trust anchor for this certification path validation. a clear requirement to build a PKIX trust chain. Since the word "issued" (not the same as "signed") implies a name comparison not a signature check, in order to use an "IN TLSA 2 1 0 ..." RR, we need to map the trust-anchor's public key to its subject name, which is only possible when the corresponding certificate must appears in the peer's chain! Now if that's a requirement, then "2 1 0" use-case is simply a waste of bits in DNS, we get the same result via "2 1 1", since both match the same element of the chain, but 2 1 1 is substantially more compact. ------ SO: What's the story wrt. requiring the trust-anchor certificate in the server's chain? Is my analysis correct? Should the text be more clear? ------ > At some noticeable complexity cost (though not a lot of lines of > code), I've added full support for "2 0 0" and "2 1 0" TLSA records, > so now I can verify trust chains that omit the corresponding issuing > certificate and begin with something signed by the TA. My current "2 1 0" support checkes "signed by TA" not "issued by TA", is that a valid interpretation of "2 1 0"? There is a real tension here between robustness of the protocol in the face of sloppy administrator practices (neglecting to include the top signer in the chain) and the stated requirement to do "PKIX validation". Which do you want? If it's strict "PKIX", then the TA cert is required and then "2 1 0" devolves to "2 1 [12]" and is redundant (modulo SHA2 2nd-preimage attacks which break so much else that it is not worth considering other than future introduction of SHA3 or beyond matching types via the IANA registry). If "2 1 0" is not strict PKIX, and supports chains merely signed by a TA, but not necessarily "issued" by that TA, then 2 1 0 has some meaning, but violates the "issued by TA" requirement on the top element of the chain. Implementing the TA portion of the standard is uncovering murky corner cases that I don't see clearly covered in 6698. The leaf certificate use cases all work. None of the certificate usage "2" (other than "2 0 0") cases work at all unless the TA certificate is absolutely required in the peer's chain, but even "2 0 0" is DNS-hostile due to excessive RRset sizes. If one takes certificate usage 0 at face value, then one is required to be able to build a PKIX chain for all its incarnations without any DANE RRset input, and then with all the right material already hand, there are no problems with "1 x y". For SMTP however, the requirement on the verifier of having at hand "a complete CA certificate set" (whatever that means) is untenable. There is no human to click "OK" when the CA list is incomplete, and administrators will quickly disable DANE if it routinely breaks mail delivery to a non-trivial fraction of destinations. So I need to ignore the requirement for pre-existing shared CA trust with certificate usage "0" and treat it as equivalent to "2". Thus I'm left with either (amended 6698 or draft-ietf-dane-smtp): - All DANE-enabled TLS servers MUST respond with server SSL HELO chains that contain the associated TA certificate (for both usage 0 and 2). In this case "2 0 0" and "2 1 0" are both silly, "2 0 1" or "2 1 1" do the same job much better. And, for SMTP at least, "0 0 0" and "0 1 0" meet the same fate. OR - I can support only the DNS-hostile "0 0 0" and "2 0 0" and also the more compat "0 1 0" and "2 1 0" provided I re-interpret "issued by TA" as "signed by TA" in the case of full public-key TAs. What I have implemented so far is the second alternative. I am a bit stunned by the silence of the majority of the list. Are my questions to hard, too annoying, or just inconveniently timed? -- Viktor. From jakob@kirei.se Tue Mar 26 04:53:04 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E7A21F84B6 for ; Tue, 26 Mar 2013 04:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9W6Kc2nI0zgO for ; Tue, 26 Mar 2013 04:53:03 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 8593E21F8A7E for ; Tue, 26 Mar 2013 04:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer; bh=z6wT/01jTfWqzvBlQ3/si2kjHcGN/5s1q4HwfUu36TI=; b=Gx2fT7Wz04t64v95SOOhY6v7cy9k6vCWhMoXASBrDXcN0/lPR+mckHGC+D2LDgtbJ5y/69gwRAbI6 m+NRE7J4252sUhum1QVl2GMh9VOB6b/IYnqaMfLFxXfiFlzeL0Aq6lIg9w9Ecw/gOh2W1oCRthTtxk vqSPV+SelkVAm5M0= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Tue, 26 Mar 2013 12:52:37 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jakob Schlyter In-Reply-To: <20130326082219.GS28046@mournblade.imrryr.org> Date: Tue, 26 Mar 2013 12:52:36 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20130322000725.GF28046@mournblade.imrryr.org> <20130324005213.GJ28046@mournblade.imrryr.org> <20130326082219.GS28046@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1503) Subject: Re: [dane] IN TLSA 2 0 0 and handshake trust chain? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 11:53:04 -0000 On 26 mar 2013, at 09:22, Viktor Dukhovni wrote: > Now if that's a requirement, then "2 1 0" use-case is simply a waste > of bits in DNS, we get the same result via "2 1 1", since both > match the same element of the chain, but 2 1 1 is substantially > more compact. I agree "2 1 0" is a waste of bits - "2 x {1,2}" makes a lot more sense". jakob From cloos@jhcloos.com Tue Mar 26 06:51:34 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08EC21F8B6D for ; Tue, 26 Mar 2013 06:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPR0lZ7Y6+km for ; Tue, 26 Mar 2013 06:51:34 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2604:8800:100:81ca::53]) by ietfa.amsl.com (Postfix) with ESMTP id 399A521F8B45 for ; Tue, 26 Mar 2013 06:51:34 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id D1B1A40560; Tue, 26 Mar 2013 13:51:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1364305890; bh=cL9iB7jHIO6fHLn8G81Xl+ZwW5gLwUywDYochGzfm5g=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=US2itexa5yg8mnd3q3gNC9Avo2w0KuC9guDYApMWRx5MNnN2qcMizTNBIxcHhS9gO dJeFANnpzZgoCJ2lPL1M20pwM6N415F8SEqPYogZpfreBAbUZLOTR4f3EwoO0xTw54 aQTceYaEuBOXgySBR60DMhdihviBCg+wOXDgV/uo= Received: by carbon.jhcloos.org (Postfix, from userid 500) id BA81260028; Tue, 26 Mar 2013 13:50:06 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20130326082219.GS28046@mournblade.imrryr.org> (Viktor Dukhovni's message of "Tue, 26 Mar 2013 08:22:19 +0000") References: <20130322000725.GF28046@mournblade.imrryr.org> <20130324005213.GJ28046@mournblade.imrryr.org> <20130326082219.GS28046@mournblade.imrryr.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 26 Mar 2013 09:50:06 -0400 Message-ID: Lines: 13 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130326:viktor1dane@dukhovni.org::5s6Xk6+jnO2bnola:0000000000000000000000000000000000007zPo4 X-Hashcash: 1:30:130326:dane@ietf.org::JTmcTnPQZhC77+70:0002FgtG Cc: dane@ietf.org Subject: Re: [dane] IN TLSA 2 0 0 and handshake trust chain? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 13:51:34 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> Since the word "issued" (not the same as "signed") implies a name VD> comparison not a signature check, I'm not sure that such a meaning is intentional rather than possibly sloppy language. I'd consider a signature sufficient. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From cloos@jhcloos.com Tue Mar 26 06:53:13 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76D721F8518 for ; Tue, 26 Mar 2013 06:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xh2qTzOFKXqM for ; Tue, 26 Mar 2013 06:53:13 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id 0779F21F8536 for ; Tue, 26 Mar 2013 06:52:55 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 6EC4C40560; Tue, 26 Mar 2013 13:52:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1364305974; bh=+OXdVQGVDiU9Q424618dGyY8/Wxnls4SIWiJAEfjQFY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=MW0cjNbGIAfIbfbyWjCQ6Nhy2CQBVWfs2Dpjt/sSpp70sDxKxNsRQa7SkdF9gFsPs DQg8mOi0DKXPJLoGkBhUrKW5e1tC6CzC8gUdz6f/lSb06aIhIBNmtbXFoZD0nHr0IF evle1JU8ktLLjxfQTlfDOXRHYWkXMRg0fnxFs1ss= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 7995F60028; Tue, 26 Mar 2013 13:48:11 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20130324005213.GJ28046@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sun, 24 Mar 2013 00:52:14 +0000") References: <20130322000725.GF28046@mournblade.imrryr.org> <20130324005213.GJ28046@mournblade.imrryr.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 26 Mar 2013 09:48:11 -0400 Message-ID: Lines: 29 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130326:viktor1dane@dukhovni.org::HQbY49COKo6op27A:000000000000000000000000000000000000C1c5d X-Hashcash: 1:30:130326:dane@ietf.org::CMU6IPQiKSpyaM9v:000A+8ZY Cc: dane@ietf.org Subject: Re: [dane] IN TLSA 2 0 0 and handshake trust chain? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 13:53:13 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> I take it you read the phrase "with any certificate matching the VD> TLSA record... " to mean that such a certificate must come from the VD> server in the server SSL HELO. Yes, but I should have written something more like "in the HELO or in the client's trust store"; any case where a type 0 can work also should work with a type 2 pointing at the same cert. VD> If I squint hard enough, I can read it the same way, but I could VD> also suppose that the PKIX validation path in question was in part VD> constructed by the verifier, and so no explicit requirement for the VD> server to provide the certificate. I did forget the other day, as I wrote above, the case where the type 2 points at a cert in the client's store. Since you wrote that, after all, you wrote the code to handle the type 2 case where the cert isn't in the local store or in the HELO, I have to say "working code beats word lawyering". I think it would have been OK to skip the extra code for those possibil- ities, using the language in the RFC as an excuse. But since you wrote it anyway, use it. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From viktor1dane@dukhovni.org Tue Mar 26 10:27:28 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2778921F8B8D for ; Tue, 26 Mar 2013 10:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Cp0vwbCOEgi for ; Tue, 26 Mar 2013 10:27:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id A720C21F8B45 for ; Tue, 26 Mar 2013 10:27:26 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C4EDC2AB685; Tue, 26 Mar 2013 17:27:25 +0000 (UTC) Date: Tue, 26 Mar 2013 17:27:25 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130326172725.GT28046@mournblade.imrryr.org> References: <20130322000725.GF28046@mournblade.imrryr.org> <20130324005213.GJ28046@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] IN TLSA 2 0 0 and handshake trust chain? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 17:27:28 -0000 On Tue, Mar 26, 2013 at 09:48:11AM -0400, James Cloos wrote: > >>>>> "VD" == Viktor Dukhovni writes: > > VD> I take it you read the phrase "with any certificate matching the > VD> TLSA record... " to mean that such a certificate must come from the > VD> server in the server SSL HELO. > > Yes, but I should have written something more like "in the HELO or in > the client's trust store"; any case where a type 0 can work also should > work with a type 2 pointing at the same cert. I must not be making my question clear enough. The "or in the client's trust store case" is NOT an option for any of the "2 x y" forms. The domain owner is not psychic, and must not be given the freedom to divine what may or may not be in the trust stores of every plausible client. Yes, I have code that supports the DNS unfriendly "2 0 0" and I'll likely keep it in place, although I am also considering disabling it by default. The deeper problems are: - "2 x [12]" are too fragile to support in any implementation that commits *verify* the peer's certificate or else drop the connection. If we're proceeding opportunistically without dropping the connection, what's the point of DANE? Unless the certificate in sure to be in hand, that is unless it is REQUIRED (MUST, no excuses) to be provided in the server's SSL HELO, I cannot make TLS certificate *verification* mandatory for a connection to a "2 x [12]" endpoint". Since usage "2" supports private CAs, there is NO presumption that clients already have the TA cert, so the RFC has to mandate its presence in the server SSL HELO chain. If this is not clearly required by 6698, server operator practices will vary on this point, and I must then treat all "2 x [12]" TA associations as "unusable". - In addition, "2 1 0" is also unusable if PKIX means "issued and signed by the TA", and not just "signed by the TA". Which is it? Is 6698 relaxing 5280 on this point? My reading of 5280 is that they mean "issued", and TAs must have a subject name for that purpose. If that's not what 5280 means, DANE should specify the "signed by is sufficient" interpretation, or else MANDATE that the peer present the TA certificate after the server SSL HELO reply. - Without a MANDATE to include the TA in the server's configured SSL trust chain, it turns out that the *only* "2 x y" case I can implement robustly, but hesitantly, since I'm endorsing bad DNS hygiene in doing so, is "2 0 0". Since for SMTP I must also read "0 x y" as "2 x y", and I am guessing that this group will not agree to language in 6698 or related standards that also MANDATES the TA certificate in the server's SSL certificate chain (sent by the server itself, not optionally found by the client), I have to treat all "0 x y" associations other than "0 0 0" as unusable. I am also inclined to treat "0 0 0" as unusable in order to promote "DNS hygiene". I cannot encumber Postfix users with a feature that routinely makes email sit in queues for spurious reasons. Can the group clarify the RFC 6698 requirements with respect to the content of the SSL "server certificate" message: https://tools.ietf.org/html/rfc2246#section-7.4.2 Structure of this message: opaque ASN.1Cert<1..2^24-1>; struct { ASN.1Cert certificate_list<0..2^24-1>; } Certificate; certificate_list This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. The part starting with "Because certificate validation..." is clearly cast in a new light by DANE with associations that specify TA digests. Where/what is the normative language in 6698 that refines this requirement for server operators (and domain owners) who choose to publish DANE TLSA associations? > VD> If I squint hard enough, I can read it the same way, but I could > VD> also suppose that the PKIX validation path in question was in part > VD> constructed by the verifier, and so no explicit requirement for the > VD> server to provide the certificate. > > I did forget the other day, as I wrote above, the case where the type 2 > points at a cert in the client's store. > > Since you wrote that, after all, you wrote the code to handle the type 2 > case where the cert isn't in the local store or in the HELO, I have to > say "working code beats word lawyering". > > I think it would have been OK to skip the extra code for those possibil- > ities, using the language in the RFC as an excuse. But since you wrote > it anyway, use it. Yes, I have code that handles "2 0 0" and "0 0 0" out-of-band, but I'd much rather not need it, it brings-in dependencies on low-level primitives (X509 signature checks) from OpenSSL's libcrypto that I'd rather not introduce. For the same implementation complexity price, I also have code that handles "2 1 0" and "0 1 0", but only if "issued by" is to be taken to mean "signed by". I have no code that can deal with "2 x 1" or "2 x 2" unless there is clear language in 6698 that mandates the corresponding TA in the server's "certificate_list" (https://tools.ietf.org/html/rfc2246#section-7.4.2) My request to the group is as follows: Please consider *mandating* that any TLSA association that specifies a trust anchor (0, 2 and any additional ones in the future) obligates the server to present the corresponding TA certificate in its "certificate_list". If that is done, I can support all "0 x y" and all "2 x y" associations, and publish documentation for Postfix SMTP server operators to be DNS-friendly and use "2 x 1" rather than "2 x 0". If the group can only mandate on-the-wire TA certificates in the "certificate_list" for "2 x y" associations and not for "0 x y" associations, then I must drop support for all "0 x y" associations other than "0 0 0", but it may be better to simply not support "0 x y" at all for all "x y". If there is no "certificate_list" mandate for any of the "usage" values, then I can only implement "0 x 0" and "2 x 0", with x=1 meaning "signed by". So my take on the standard from an implementation viewpoint is that so far the *only* robust associations are "3 1 1" and "3 0 1". - 3 0 0 and to a lesser extent 3 1 0 are not DNS-friendly. - 3 1 2 alone is fragile because matching type 2 support is optional, one must publish 3 1 1 along with it. So essentially nobody will publish 3 1 2. - "0 x y" and "1 x y" needlessly risk rejection by clients with an incomplete public CA set that implement the spec as written and implement these as "constraints" and not "assertions". - "2 x [12]" is unusable without the "certificate_list" mandate. - "2 1 0" is unusable unless "issued by" is read as "signed by", it is also not very DNS-friendly, a 2048-bit RSA public key is around 300 bytes of DER (an EC public key at ~90 bytes may be sufficiently svelte, but we're not yet at broad support for EC in SSL). - "2 0 0" is not DNS-friendly. With a "certificate_list" mandate for "2 x y", I get: - Cleaner implementation support for "2 x 0" associations, no need for signature checks in my code, the chain will be checked by OpenSSL's built-in verification code. - Support for "2 x [12]" associations, since I can expect to find the TA in the server chain. With a "certificate_list" mandate for "0 x y" (which I expect I won't get, but it would be a shame not to ask) the above applies with "2" replaced by "0". With no "certificate_list" mandate, and without clarification of "issued by" vs. "signed by", I may have to withdraw support for everything other than "3 x y" and (after remapping constraint to assertion) "1 x y". -- Viktor. From viktor1dane@dukhovni.org Tue Mar 26 14:54:11 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD40B21F86BA for ; Tue, 26 Mar 2013 14:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It0dGscOcxg9 for ; Tue, 26 Mar 2013 14:54:10 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id DED7321F86B7 for ; Tue, 26 Mar 2013 14:54:09 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 257BB2AB90E; Tue, 26 Mar 2013 21:54:08 +0000 (UTC) Date: Tue, 26 Mar 2013 21:54:08 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130326215407.GY28046@mournblade.imrryr.org> References: <20130322000725.GF28046@mournblade.imrryr.org> <20130324005213.GJ28046@mournblade.imrryr.org> <20130326082219.GS28046@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] TA associations (was: IN TLSA 2 0 0 and handshake trust chain?) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 21:54:11 -0000 On Tue, Mar 26, 2013 at 12:52:36PM +0100, Jakob Schlyter wrote: > On 26 mar 2013, at 09:22, Viktor Dukhovni wrote: > > > Now if that's a requirement, then "2 1 0" use-case is simply a waste > > of bits in DNS, we get the same result via "2 1 1", since both > > match the same element of the chain, but 2 1 1 is substantially > > more compact. > > I agree "2 1 0" is a waste of bits - "2 x {1,2}" makes a lot more sense". What about the larger issue, how can I use "2 x 1" or "2 x 2" if the TA certificate is not required in the peer's chain? Or is it? How can I use "2 1 0" (waste of bits and all) if I must check "issued" rather than "signed"? Is the group tired of my questions? I need to converge on a viable implementation profile and some guidance is essential at this point. The problem isnt't how to write the code, that's easy. The problem is choosing appropriate TLSA RR semantics. I don't know when it is safe to commit to verification of the peer's chain if I can't predict its required contents. What requirements on the peer's "certificate_list" are implied by publishing a trust anchor TLSA RR with "2" (and ideally also "0") as the certificate usage? -- Viktor. From scottr.nist@gmail.com Wed Mar 27 11:19:29 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F7B21F92BE for ; Wed, 27 Mar 2013 11:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1bNrGhxJpLZ for ; Wed, 27 Mar 2013 11:19:28 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB7721F92BA for ; Wed, 27 Mar 2013 11:19:25 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id k11so10655930iea.10 for ; Wed, 27 Mar 2013 11:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=VnDWOYS+2xRfPLp/H+7M/sOCF1316dpvVMXZpsLteos=; b=aYUo1w60ob413zkY5X32fPjm31N+G6jkGTsb6rxv6TwWnUCeO9ey6hr0d7DrGlQ8/q gCv9dYy3SzQxo1fNKJruzbTxIQrcWV2NW3bVfZvBqMnADxQ3/Ic3AJ0FHkw8bMz9Colm 0kC+f473Rkue5Qqr5C9pHs6I5M0Ty0ATcJvDu5ELmrL4RPEtIDcmynEfPHIT1C+zITTm /dbiZZ9Tpw2SiB2PuKZahwWqpKQ0uZ5cFJlroETzXKKFBMl+7UT2c8z34rmAhWt6q2o6 +UT9Xirn1h496LXJYSmz0tf0pizuC1eETtlYDnaRYZ3Xyj0XyYxJp+FFAV0KRDOthRoV rrzg== MIME-Version: 1.0 X-Received: by 10.50.17.71 with SMTP id m7mr5076548igd.14.1364408364960; Wed, 27 Mar 2013 11:19:24 -0700 (PDT) Received: by 10.50.79.234 with HTTP; Wed, 27 Mar 2013 11:19:24 -0700 (PDT) In-Reply-To: <20130319173028.9409.53559.idtracker@ietfa.amsl.com> References: <20130319173028.9409.53559.idtracker@ietfa.amsl.com> Date: Wed, 27 Mar 2013 14:19:24 -0400 Message-ID: From: Scott Rose To: dane@ietf.org Content-Type: multipart/alternative; boundary=089e01160816ec148a04d8ec13ef Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: scott.rose@nist.gov List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 18:19:29 -0000 --089e01160816ec148a04d8ec13ef Content-Type: text/plain; charset=ISO-8859-1 I support the goal of this draft and want to see it progressed. I do think it might need a bit more besides just copying the TLSA RR format, or at least a re-definition of the values since the two uses don't map 1-to-1. As a first stab, I'd propose the following: 2. The SMIMEA Resource Record The SMIMEA DNS resource record (RR) is used to associate an end entity certificate or public key with the associated email address, thus forming a "SMIMEA certificate association". The semantics of how the SMIMEA RR is interpreted are given later in this document. The type value for the SMIMEA RR type is defined in Section 5.1. The SMIMEA RR is class independent. The SMIMEA RR has no special TTL requirements. The SMIMEA wire format and presentation format are the same as for the TLSA record. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Usage | Selector | Matching Type | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / / Certificate Association Data / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.1. The Key Usage Field The Key Usage field is a one octet bit map where each bit represents a declared use of the key contained in the assocaited data. The bit flags for the Key Usage field are the same as the Key Usage field defined in Section 4.2.1.3 of [RFC2495] 2.2. The Selector Field A one-octet value, called "selector", specifies which part of the TLS certificate presented by the server will be matched against the association data. This field uses the same values (and meanings for those values) as the Selector field in the TLSA Record [RFC6698]. AUTHOR'S NOTE: Should this be a separate registry? 2.3. The Matching Type Field A one-octet value, called "matching type", specifies how the certificate association is presented. This field uses the same values (and meanings for those values) as the Matching Type field in the TLSA Record [RFC6698]. AUTHOR'S NOTE: Should this be a separate registry? The idea of having a key usage field is so that those with two different certs for digital signatures and encryption can have clients quickly differentiate them. The other fields may still be useful, but (personally) not totally comfortable with having two different RR's using the same registry, no matter how similar the uses are. Scott On Tue, Mar 19, 2013 at 1:30 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DNS-based Authentication of Named > Entities Working Group of the IETF. > > Title : Using Secure DNS to Associate Certificates with > Domain Names For S/MIME > Author(s) : Paul Hoffman > Jakob Schlyter > Filename : draft-ietf-dane-smime-01.txt > Pages : 6 > Date : 2013-03-19 > > Abstract: > This document describes how to use secure DNS to associate an S/MIME > user's certificate with the intended domain name, similar to the way > that DANE (RFC 6698) does for TLS. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dane-smime > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dane-smime-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --089e01160816ec148a04d8ec13ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support the goal of this draft and want to see it progressed. =A0
I do think it might need a bit more besides just copying the TL= SA RR format, or at least a re-definition of the values since the two uses = don't map 1-to-1. =A0As a first stab, I'd propose the following:

2. =A0The SMIMEA Resource Record

=A0 =A0The SMIMEA DNS resource record (RR) is used to associate an = end
=A0 =A0entity certificate or public key with the associated e= mail address,
=A0 =A0thus forming a "SMIMEA certificate association". =A0T= he semantics of
=A0 =A0how the SMIMEA RR is interpreted are given= later in this document.

=A0 =A0The type value for= the SMIMEA RR type is defined in Section 5.1. =A0The
=A0 =A0SMIMEA RR is class independent. =A0The SMIMEA RR has no special= TTL
=A0 =A0requirements. =A0The SMIMEA wire format and presentat= ion format are the
=A0 =A0same as for the TLSA record.
=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01 1 1 1 1 1 1 1 1 1 = 2 2 2 2 2 2 2 2 2 2 3 3
=A0 =A0 =A0 =A00 1 2 3 4 5 6 7 8 9 0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=A0 =A0 =A0 +-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=A0 =A0 =A0 | =A0 Key Usage =A0 | =A0 Selector =A0 =A0| Matching Type = | =A0 =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 +-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 = =A0 =A0 / =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 / =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Certificate Association = Data =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/
=A0 =A0 =A0 / =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /
=A0 =A0 =A0 +-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




2.1. =A0Th= e Key Usage Field

=A0 =A0The Key Usage field is a = one octet bit map where each bit represents
=A0 =A0a declared use= of the key contained in the assocaited data. =A0The bit
=A0 =A0flags for the Key Usage field are the same as the Key Usage fie= ld
=A0 =A0defined in Section 4.2.1.3 of [RFC2495]

<= /div>
2.2. =A0The Selector Field

A one-oc= tet value, called "selector", specifies which part of the TLS
=A0 =A0certificate presented by the server will be matched against the=
=A0 =A0association data. =A0This field uses the same values (and= meanings for
=A0 =A0those values) as the Selector field in the T= LSA Record [RFC6698].

=A0 =A0AUTHOR'S NOTE: Should this be a separate reg= istry?

2.3. =A0The Matching Type Field
<= br>
=A0 =A0A one-octet value, called "matching type", s= pecifies how the
=A0 =A0certificate association is presented. =A0This field uses the sa= me
=A0 =A0values (and meanings for those values) as the Matching = Type field in
=A0 =A0the TLSA Record [RFC6698].

=A0 =A0AUTHOR'S NOTE: Should this be a separate registry?


The idea of having a key usage fie= ld is so that those with two different certs for digital signatures and enc= ryption can have clients quickly differentiate them. =A0The other fields ma= y still be useful, but (personally) not totally=A0comfortable=A0with having= two different RR's using the same registry, no matter how similar the = uses are.


Scott


On Tue, Mar 19, 2013 at 1:30 PM, <internet-drafts= @ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the DNS-based Authentication of Named Entit= ies Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Using Secure DNS to Associate C= ertificates with Domain Names For S/MIME
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Paul Hoffman
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jakob Schlyter
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-dane-smime-01.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 6
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-03-19

Abstract:
=A0 =A0This document describes how to use secure DNS to associate an S/MIME=
=A0 =A0user's certificate with the intended domain name, similar to the= way
=A0 =A0that DANE (RFC 6698) does for TLS.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-smime

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dane-smime-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-smime-01<= /a>


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane

--089e01160816ec148a04d8ec13ef-- From paul.hoffman@vpnc.org Fri Mar 29 10:54:51 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4916A21F89E1 for ; Fri, 29 Mar 2013 10:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.292 X-Spam-Level: X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAKjqt8s1MDw for ; Fri, 29 Mar 2013 10:54:50 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BC4A421F890F for ; Fri, 29 Mar 2013 10:54:50 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r2THsncU027783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Mar 2013 10:54:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Fri, 29 Mar 2013 10:54:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <116A2073-0A51-469A-A8BB-C32D15DB2456@vpnc.org> References: <20130319173028.9409.53559.idtracker@ietfa.amsl.com> To: scott.rose@nist.gov X-Mailer: Apple Mail (2.1503) Cc: dane@ietf.org Subject: [dane] SMIMEA format X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 17:54:51 -0000 On Mar 27, 2013, at 11:19 AM, Scott Rose wrote: > I do think it might need a bit more besides just copying the TLSA RR = format, or at least a re-definition of the values since the two uses = don't map 1-to-1.=20 The difference you have from TLSA is that the TLSA "certificate usage" = field becomes the SMIMEA "key usage" field. In TLSA, certificate usage = tells the receiving party how to use the certificate (as a trust anchor = or end entity certificate); in your proposal, the key usage field is = used to say if the certificate is a signing or encrypting certificate. This is probably a false dichotomy. Your proposal prevents people from = using SMIMEA records for one of the most popular features in TLSA: = specifying trust anchors. Further, your stated reason for wanting a key = usage field seems unnecessary: > The idea of having a key usage field is so that those with two = different certs for digital signatures and encryption can have clients = quickly differentiate them. =20 The key usage is contained in the certificate itself, either implicitly = or because the key type can only be used for signing or encrypting. If = someone has two different certs (which is likely to be common), there = would simply be two SMIMEA records. Is there a strong advantage to having a new field that gives information = that is already in the certificate? BTW, I agree with your suggestions about there being separate registries = for the fields. There are definitely things that might be appropriate = for TLS that are not appropriate for S/MIME, and vice versa. --Paul Hoffman=