From warren@kumari.net Mon Jan 7 12:14: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 9468721F880E for ; Mon, 7 Jan 2013 12:14:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9yX0cjG7xVx for ; Mon, 7 Jan 2013 12:14:57 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E62821F8807 for ; Mon, 7 Jan 2013 12:14:56 -0800 (PST) Received: from [192.168.1.136] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id D468D1B40623; Mon, 7 Jan 2013 15:14:55 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> Date: Mon, 7 Jan 2013 15:14:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9677C982-555D-48E2-8B6A-44AEF93E9FDE@kumari.net> References: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> To: IETF DANE WG list X-Mailer: Apple Mail (2.1499) Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 07 Jan 2013 20:14:57 -0000 On Dec 20, 2012, at 12:17 PM, Warren Kumari wrote: > Dear DANE Working Group, >=20 > This starts a 4-week (because of time of year) consensus call on = adopting draft-fanf-dane-smtp-04 as a DANE WG document.=20 Hi all, This is a reminder to please submit feedback on adopting this (well, = these) docs=85. W >=20 > ----- DRAFT INFO ---- > Title : Secure SMTP with TLS, DNSSEC and TLSA records. > Author(s) : Tony Finch > Filename : draft-fanf-dane-smtp-04.txt >=20 > Abstract: > SMTP has a STARTTLS extension, but (especially in the case of inter- > domain mail transfer) it only provides very limited security because > it does not specify how to authenticate the server's certificate. > This memo specifies how TLSA records in the DNS can be used for > proper SMTP server authentication. >=20 >=20 > Datatracker page: = https://datatracker.ietf.org/doc/draft-fanf-dane-smtp/ > TXT URL: http://www.ietf.org/id/draft-fanf-dane-smtp-04.txt > HTML URL: http://tools.ietf.org/html/draft-fanf-dane-smtp-04 > PDF URL: http://tools.ietf.org/pdf/draft-fanf-dane-smtp-04.pdf >=20 >=20 > Please read the document and state your opinions either for or against = adoption (with reasoning why!) on the mailing list. >=20 > We note that this document has already received a bunch of discussion = onlist and in WG sessions. >=20 > The call for adoption ends 20th January 2013. >=20 > Thanks, > Ondrej and Warren. >=20 > --=20 > Never criticize a man till you've walked a mile in his shoes. Then if = he didn't like what you've said, he's a mile away and barefoot.=20 >=20 >=20 >=20 -- I don't think the execution is relevant when it was obviously a bad idea = in the first place. This is like putting rabid weasels in your pants, and later expressing = regret at having chosen those particular rabid weasels and that pair of = pants.=20 ---maf Warren Kumari warren@kumari.net From tom@ritter.vg Mon Jan 7 13:56: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 6FE5D21F84D8 for ; Mon, 7 Jan 2013 13:56:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gm2ZqxYZZrKz for ; Mon, 7 Jan 2013 13:56:03 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 940BB21F8446 for ; Mon, 7 Jan 2013 13:56:03 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id fl11so20528113vcb.29 for ; Mon, 07 Jan 2013 13:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=jR5KKiuWchCcu+GT1AGXcxPzslKjnRgqx6mk0bu6jJo=; b=Q9Uvz7A3ixBjxzYZrIiwdNBAHh6XmTjMj1Grw7xtiFpzrkEk711j7trwOJAlPW7wa5 NUW9CqPK6l4UMKdmNG8L+B1wyCHDscI3KrmmHvKDLqfJ1wtMJdZHvFrI18AUrJmq4P94 CRsW9YPP3Wr2okWY+rr6TkNgpDQVgyrDXh4yo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=jR5KKiuWchCcu+GT1AGXcxPzslKjnRgqx6mk0bu6jJo=; b=SmCyuPJV+VsT37EzCTLcAuluueW2VR1KVxHEOp4UEEUcgzL0pqfsw9B/oW3e0vdTPI FPKknZwAuGTOyE6fQcZESDz4yj6anyGt7mCwltNmshb8KEdL9ADRG4wFLq0M+bkpFMKc MFbItJddpMYWBa00RN7b/yY5D5+fOlEZ8H9kBCl62k4s5oyT0rGU4f++ZWKZhy5sW4pi w8TubII44nLAdI9WJw1eWjB5mtwUCiYDRZ0nme2Tr3qoo3q2YJd0EuuUWfypEZNLhKPI jQFXLxA97NUwm4ZHQsPODgTYiliPcv0hnaLD00VrKQbLNGENbd2aWRIo39ipZ8F1EC5+ nepw== Received: by 10.52.240.165 with SMTP id wb5mr74254989vdc.102.1357595762761; Mon, 07 Jan 2013 13:56:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.199.166 with HTTP; Mon, 7 Jan 2013 13:55:42 -0800 (PST) In-Reply-To: <9677C982-555D-48E2-8B6A-44AEF93E9FDE@kumari.net> References: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> <9677C982-555D-48E2-8B6A-44AEF93E9FDE@kumari.net> From: Tom Ritter Date: Mon, 7 Jan 2013 16:55:42 -0500 Message-ID: To: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlq2uk1BnIMWJ/9lo1SnUL6HEyJhc75bS3dCu5RSVTt2pj4HcSqPvLdv6boC5elZVjzabC+ Cc: IETF DANE WG list Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 07 Jan 2013 21:56:04 -0000 On 7 January 2013 15:14, Warren Kumari wrote: > This is a reminder to please submit feedback on adopting this (well, thes= e) docs=85. > > W I would like to see it adopted and worked on, but am not the best person to provide feedback, so take that as you will. -tom From ogud@ogud.com Mon Jan 7 14:37: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 8192121F87D5 for ; Mon, 7 Jan 2013 14:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 DbSjOHbafmGF for ; Mon, 7 Jan 2013 14:37:47 -0800 (PST) Received: from smtp154.iad.emailsrvr.com (smtp154.iad.emailsrvr.com [207.97.245.154]) by ietfa.amsl.com (Postfix) with ESMTP id 09ACB21F854F for ; Mon, 7 Jan 2013 14:37:46 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp45.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 040DC901B9 for ; Mon, 7 Jan 2013 17:37:45 -0500 (EST) X-Virus-Scanned: OK Received: by smtp45.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id DF37190186 for ; Mon, 7 Jan 2013 17:37:44 -0500 (EST) Message-ID: <50EB4E35.3050904@ogud.com> Date: Mon, 07 Jan 2013 17:37:41 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: dane@ietf.org References: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> <9677C982-555D-48E2-8B6A-44AEF93E9FDE@kumari.net> In-Reply-To: <9677C982-555D-48E2-8B6A-44AEF93E9FDE@kumari.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 07 Jan 2013 22:37:47 -0000 On 07/01/2013 15:14, Warren Kumari wrote: > > On Dec 20, 2012, at 12:17 PM, Warren Kumari wrote: > >> Dear DANE Working Group, >> >> This starts a 4-week (because of time of year) consensus call on adopting draft-fanf-dane-smtp-04 as a DANE WG document. > Support adoption Olafur From cloos@jhcloos.com Mon Jan 7 15:07: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 5596621F870A for ; Mon, 7 Jan 2013 15:07:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnQKNhICOtsF for ; Mon, 7 Jan 2013 15:07:47 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:4830:1662::53]) by ietfa.amsl.com (Postfix) with ESMTP id A4BA921F86F5 for ; Mon, 7 Jan 2013 15:07:47 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 8046F4017A; Mon, 7 Jan 2013 23:07:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1357600063; bh=/3PzXB/jJto+VdH/1JXGp6y3sVdmd6UELLUwO64KbsU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=GerLFTC82L+p/PxHfpAH8FJB5V/xb6kKhagjI/aACSjs/QG1fWX6SE4neTbHCTTs/ Oq3dfuaMHN2RKDXCjItK/Cq7VwQQ8K5+j8ZTaUy4ZA/+VqrK+ClAE6EAjg6N2CPkW4 QiQt/Gg+3UUWDPAvRPJClt6Zopzkw4Enh18pSR3Q= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 08F4FACA6E; Mon, 7 Jan 2013 22:59:44 +0000 (UTC) From: James Cloos To: Warren Kumari In-Reply-To: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> (Warren Kumari's message of "Thu, 20 Dec 2012 12:17:34 -0500") References: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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: Mon, 07 Jan 2013 17:59:43 -0500 Message-ID: Lines: 5 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130107:warren@kumari.net::MsbuX+4Vx/Ngcr6U:0000000000000000000000000000000000000000000pfvae X-Hashcash: 1:30:130107:dane@ietf.org::LMVFk38uFkThLBOs:000VOo// Cc: IETF DANE WG list Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 07 Jan 2013 23:07:48 -0000 +1 -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From cloos@jhcloos.com Mon Jan 7 15:09: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 AFB4C21F8727 for ; Mon, 7 Jan 2013 15:09:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Udvathd-Qle for ; Mon, 7 Jan 2013 15:09:57 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:4830:1662::53]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2E021F8726 for ; Mon, 7 Jan 2013 15:09:57 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id AC3904017A; Mon, 7 Jan 2013 23:09:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1357600196; bh=/3PzXB/jJto+VdH/1JXGp6y3sVdmd6UELLUwO64KbsU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=ho3gq5RLarl7CDfDdFSWs6v0FSOFYtk6YbeCk3k1BY7j3vRjjPSb36WAyBS3NzW0B xRWHqV38MRVNXVIwAD6YfjaOH/iHbXP7QjlAyLVahb5OGxy+xBvyeGVg8oOHcLSTtk Qs8mvOsLFV5C4jRR0E6BC8s7m5FLU8QrcSo82vVs= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 7EECFACA6E; Mon, 7 Jan 2013 23:00:29 +0000 (UTC) From: James Cloos To: Warren Kumari In-Reply-To: (Warren Kumari's message of "Thu, 20 Dec 2012 12:17:30 -0500") References: User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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: Mon, 07 Jan 2013 18:00:29 -0500 Message-ID: Lines: 5 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130107:warren@kumari.net::MXriXNZAzKlOcN3s:00000000000000000000000000000000000000000003dsj0 X-Hashcash: 1:30:130107:dane@ietf.org::DtEAGkeAn5hzsBi/:000Myl+L Cc: IETF DANE WG list Subject: Re: [dane] Call for Adoption - draft-fanf-dane-mua-00 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, 07 Jan 2013 23:09:57 -0000 +1 -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From cloos@jhcloos.com Mon Jan 7 15:10: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 7523E21F8727 for ; Mon, 7 Jan 2013 15:10:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IN5+5qqxOT9r for ; Mon, 7 Jan 2013 15:10:11 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id B496721F8726 for ; Mon, 7 Jan 2013 15:10:11 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id BEBF34017A; Mon, 7 Jan 2013 23:09:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1357600205; bh=5ml6Y2o3OYBOTDfGvpgj/Rv9Xbsfka+oZmYhLXprRT8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=qBYKkSpP2FdjWDV+cAkC9q4qy2GDNSFlH6ppUB+wA1cZgPRiwP+8vMUqt4xZCpIQE T4rDXu22KoCXDA2zUGJ1oOGTA+o/4TSQlSEu1PbMYMna9ul2kLgyzTH64CmlP7azlF kcLw2WQ7IMFuacBK8ZRnuj1bimlQLnGwtiD0jEFA= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 4C519ACA6E; Mon, 7 Jan 2013 23:03:56 +0000 (UTC) From: James Cloos To: Warren Kumari In-Reply-To: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> (Warren Kumari's message of "Thu, 20 Dec 2012 12:17:34 -0500") References: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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: Mon, 07 Jan 2013 18:03:56 -0500 Message-ID: Lines: 11 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130107:warren@kumari.net::bu5XPc1wxB+utC7g:0000000000000000000000000000000000000000000MjQhF X-Hashcash: 1:30:130107:dane@ietf.org::2Cg7ciLha0PGCVsk:000WgnzN Cc: IETF DANE WG list Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 07 Jan 2013 23:10:16 -0000 A point of discussion is what, if anything, the receiving MTA should do dane-wise with and cert offered by the sending MTA. the MTAs generally do a ptr lookup and an a or aaaa to confirm that the latter results in the same ip as the socket; it could use the result of that ptr lookup also to grab a _25._tcp TLSA rr. Should it? Should this draft talk about that? Should there be a draft just for that? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From stpeter@stpeter.im Mon Jan 7 18:00: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 49C8421F8645 for ; Mon, 7 Jan 2013 18:00:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ886ZzDOA6F for ; Mon, 7 Jan 2013 18:00:20 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD4021F8628 for ; Mon, 7 Jan 2013 18:00:20 -0800 (PST) Received: from [192.168.1.176] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0330F4005D; Mon, 7 Jan 2013 19:05:24 -0700 (MST) Message-ID: <50EB65D5.2000204@stpeter.im> Date: Mon, 07 Jan 2013 17:18:29 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Warren Kumari References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF DANE WG list Subject: Re: [dane] Call for Adoption - draft-fanf-dane-mua-00 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, 08 Jan 2013 02:00:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/20/12 10:17 AM, Warren Kumari wrote: > Dear DANE Working Group, > > This starts a 4-week (because of time of year) consensus call on > adopting draft-fanf-dane-mua-00 as a DANE WG document. I have no objections to adopting this work in the DANE WG, but given how similar this spec is in concept to draft-miller-xmpp-dnssec-prooftype (indeed, Matt Miller and I had talked with Tony about the possibility of merging our efforts), I am wondering what is the best way to ensure harmony between the MUA recommendations and the XMPP recommendations. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDrZdUACgkQNL8k5A2w/vzi9QCgsyCzFdw03IQYMX1PnZ4C3NSQ c7kAoOd4k6NZ+6EFS4BFa5T5ahuv3Vdk =IOPH -----END PGP SIGNATURE----- From jakob@kirei.se Mon Jan 7 23:21:50 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 EAAF321F8444 for ; Mon, 7 Jan 2013 23:21:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ArwYQma7wSs for ; Mon, 7 Jan 2013 23:21:50 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 92EE121F843E for ; Mon, 7 Jan 2013 23:21:48 -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:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=krF1v8FokNyN+9V2dJo5vuZ8WsL6PWOoVffYQNGsOcE=; b=zZ5TmOec6qEqONTokpU0+bZHfIydrT++uJWjIvbCrnCKIL57zaY4dgK6pWzW9TCqY3f+U16XAW7lL w0QIq7/47b/lVqNPDoaG6vNnMe6/vRKbryZ5pkEAL1TX5zaxBBB28qxSIOjv8cbN6E1CIVC3T5IfHB RQEHnIUTO8RzTGzw= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 8 Jan 2013 08:21:46 +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: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> Date: Tue, 8 Jan 2013 08:21:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8880BDFE-F13E-49C7-BB81-FB87A6E0C777@kirei.se> References: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1499) Cc: IETF DANE WG list Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 08 Jan 2013 07:21:51 -0000 On 20 dec 2012, at 18:17, Warren Kumari wrote: > Please read the document and state your opinions either for or against = adoption (with reasoning why!) on the mailing list. I support adoption - this is important work. jakob From jakob@kirei.se Mon Jan 7 23:22: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 BB3CE21F843E for ; Mon, 7 Jan 2013 23:22:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgl6lORvR0dq for ; Mon, 7 Jan 2013 23:22:13 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id CA08521F8447 for ; Mon, 7 Jan 2013 23:22:12 -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:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=BIvzICjOTfR+xXL4hS6vBdGJUCnjv0/LIYnAFMD40T0=; b=Ju2eXNMOvmwGgHoZ2Jd+CPUnJnPgxtN34dGI2rnbJRi7OlNiE/0tliPFf37VsczCKf1TTE5rLFY6M MNPfXz7ZZE0Z0r1wpEHDH6olHoH19Fpahip56zUtnop197A+JrawxgfpqAU4z+YE2+nMJ8sn2EXBj5 mE60o4eZxoL+zmVg= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 8 Jan 2013 08:22:10 +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: Date: Tue, 8 Jan 2013 08:22:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8F47BD26-7151-4644-9065-AF348611B349@kirei.se> References: To: Warren Kumari X-Mailer: Apple Mail (2.1499) Cc: IETF DANE WG list Subject: Re: [dane] Call for Adoption - draft-fanf-dane-mua-00 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, 08 Jan 2013 07:22:13 -0000 On 20 dec 2012, at 18:17, Warren Kumari wrote: > This starts a 4-week (because of time of year) consensus call on = adopting draft-fanf-dane-mua-00 as a DANE WG document.=20 I support adoption - this is important work (together with the SMTP = draft). jakob From Marco.Davids@sidn.nl Tue Jan 8 00:52: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 8D88021F8461 for ; Tue, 8 Jan 2013 00:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] 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 xwZw9t688XPn for ; Tue, 8 Jan 2013 00:52:07 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id AAA1A21F843B for ; Tue, 8 Jan 2013 00:52:06 -0800 (PST) Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id r088q56b020455-r088q56d020455 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Tue, 8 Jan 2013 09:52:05 +0100 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn02.SIDN.local (192.168.2.74) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 8 Jan 2013 09:52:04 +0100 Received: from iMac2.local (94.198.152.221) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 8 Jan 2013 09:52:04 +0100 Message-ID: <50EBDE33.8040101@sidn.nl> Date: Tue, 8 Jan 2013 09:52:03 +0100 From: "Marco Davids (SIDN)" Organization: SIDN User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: References: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> <8880BDFE-F13E-49C7-BB81-FB87A6E0C777@kirei.se> In-Reply-To: <8880BDFE-F13E-49C7-BB81-FB87A6E0C777@kirei.se> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.221] Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 08 Jan 2013 08:52:07 -0000 Op 08-01-13 08:21, Jakob Schlyter schreef: > On 20 dec 2012, at 18:17, Warren Kumari wrote: > >> Please read the document and state your opinions either for or against adoption (with reasoning why!) on the mailing list. > > I support adoption - this is important work. Me too. The fact that RFC3207 does not clearly describe how a server should be authenticated leaves room for MitM-abuse and is an issue that needs to be addressed. I like the idea of fixing it with DANE, especially since many certificates used in 'STARTTLS' today, are self-signed certificates. -- Marco From pawal@blipp.com Tue Jan 8 01:09: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 5670B21F88D8 for ; Tue, 8 Jan 2013 01:09:44 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 4SCGoFAkvZc5 for ; Tue, 8 Jan 2013 01:09:43 -0800 (PST) Received: from vic20.blipp.com (vic20.blipp.com [213.115.13.25]) by ietfa.amsl.com (Postfix) with ESMTP id AE38421F8830 for ; Tue, 8 Jan 2013 01:09:43 -0800 (PST) Received: from laptopw-113.office.nic.se (gw.iis.se [212.247.14.38]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by vic20.blipp.com (Postfix) with ESMTPSA id 31A3B38005; Tue, 8 Jan 2013 10:09:10 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_Wallstr=F6m?= In-Reply-To: <8880BDFE-F13E-49C7-BB81-FB87A6E0C777@kirei.se> Date: Tue, 8 Jan 2013 10:09:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <27D4B56D-94E1-4342-95B2-9C5E778C399D@blipp.com> References: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> <8880BDFE-F13E-49C7-BB81-FB87A6E0C777@kirei.se> To: Jakob Schlyter X-Mailer: Apple Mail (2.1283) Cc: IETF DANE WG list Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 08 Jan 2013 09:09:44 -0000 On Jan 8, 2013, at 8:21 AM, Jakob Schlyter wrote: > On 20 dec 2012, at 18:17, Warren Kumari wrote: >=20 >> Please read the document and state your opinions either for or = against adoption (with reasoning why!) on the mailing list. >=20 > I support adoption - this is important work. +1 From wjhns1@hardakers.net Tue Jan 8 09:01: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 8696C11E80D9 for ; Tue, 8 Jan 2013 09:01:36 -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 Cg00vhzRtusm for ; Tue, 8 Jan 2013 09:01:35 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D2A11E80BF for ; Tue, 8 Jan 2013 09:01:35 -0800 (PST) Received: from localhost (unknown [50.13.187.159]) by mail.hardakers.net (Postfix) with ESMTPSA id 97D56415; Tue, 8 Jan 2013 09:01:23 -0800 (PST) From: Wes Hardaker To: Jakob Schlyter References: <8F47BD26-7151-4644-9065-AF348611B349@kirei.se> Date: Tue, 08 Jan 2013 09:01:21 -0800 In-Reply-To: <8F47BD26-7151-4644-9065-AF348611B349@kirei.se> (Jakob Schlyter's message of "Tue, 8 Jan 2013 08:22:11 +0100") Message-ID: <0ly5g3han2.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: IETF DANE WG list Subject: Re: [dane] Call for Adoption - draft-fanf-dane-mua-00 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, 08 Jan 2013 17:01:36 -0000 Jakob Schlyter writes: > On 20 dec 2012, at 18:17, Warren Kumari wrote: > >> This starts a 4-week (because of time of year) consensus call on >> adopting draft-fanf-dane-mua-00 as a DANE WG document. > > I support adoption - this is important work (together with the SMTP draft). I agree, this document is needed and is a good starting point. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From ogud@ogud.com Tue Jan 8 11: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 C3FBC21F8614 for ; Tue, 8 Jan 2013 11:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 7HYJ7+6bSInb for ; Tue, 8 Jan 2013 11:25:16 -0800 (PST) Received: from smtp134.iad.emailsrvr.com (smtp134.iad.emailsrvr.com [207.97.245.134]) by ietfa.amsl.com (Postfix) with ESMTP id 08C2C21F8606 for ; Tue, 8 Jan 2013 11:25:15 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp33.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 71218302B5 for ; Tue, 8 Jan 2013 14:25:15 -0500 (EST) X-Virus-Scanned: OK Received: by smtp33.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 4AFEE3005B for ; Tue, 8 Jan 2013 14:25:15 -0500 (EST) Message-ID: <50EC7298.8010306@ogud.com> Date: Tue, 08 Jan 2013 14:25:12 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: dane@ietf.org References: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 08 Jan 2013 19:25:16 -0000 On 07/01/2013 18:03, James Cloos wrote: > A point of discussion is what, if anything, the receiving MTA should do > dane-wise with and cert offered by the sending MTA. > > the MTAs generally do a ptr lookup and an a or aaaa to confirm that the > latter results in the same ip as the socket; it could use the result of > that ptr lookup also to grab a _25._tcp TLSA rr. Should it? Should > this draft talk about that? Should there be a draft just for that? > > -JimC > Hum in this case there are two options a) store the DANE record in both forward and reverse zone b) place a CNAME record in the reverse zone. IMHO storing DANE record in just one place is better. Olafur From fanf2@hermes.cam.ac.uk Wed Jan 9 10:41:17 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 4813721F8507 for ; Wed, 9 Jan 2013 10:41:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muexFMc3Ao+k for ; Wed, 9 Jan 2013 10:41:16 -0800 (PST) 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 417E521F84FD for ; Wed, 9 Jan 2013 10:41:16 -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 hermes-1.csi.cam.ac.uk ([131.111.8.51]:41241) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Tt0aO-0007vI-Sp (Exim 4.72) (return-path ); Wed, 09 Jan 2013 18:41:12 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Tt0aO-0001GX-Ta (Exim 4.72) (return-path ); Wed, 09 Jan 2013 18:41:12 +0000 Date: Wed, 9 Jan 2013 18:41:12 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: James Cloos In-Reply-To: Message-ID: References: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> 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] Call for Adoption - draft-fanf-dane-smtp-04 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, 09 Jan 2013 18:41:17 -0000 James Cloos wrote: > A point of discussion is what, if anything, the receiving MTA should do > dane-wise with and cert offered by the sending MTA. I think this might be interesting to pursue but it could be a deep rat hole. I prefer to get server authentication complete first. I believe it would not be feasible to tie the sending host identity to the sending mail domain. That would repeat the error made by SPF. So the only benefit we can get is authenticating the sending host; some other mechanism (i.e. DKIM) is necessary for higher-level identities. What benefit would client authentication give you? At the moment we usually assume that bidirectional TCP is good enough for us to believe the client IP address; this is evidently a bit shaky given the lack of routing security, but even if we had secure routing we could still be open to spoofing attacks from sufficiently well-placed on-path attackers. For intra-domain mail, client authentication is useful for gaining permission to relay arbitrary mail. It's perfectly sensible to use client certificates for this, probably validated using a private CA. If DANE takes off it might be preferable to use the DNS instead. For inter-domain mail the client IP address is looked up in reputation services and used for tracing and logging. You might care about making this harder to spoof, but it's fairly marginal I think. 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 cloos@jhcloos.com Wed Jan 9 11:45: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 5472421F8833 for ; Wed, 9 Jan 2013 11:45:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dw0Tj6aPJJ9 for ; Wed, 9 Jan 2013 11:45:46 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id 24CF221F8845 for ; Wed, 9 Jan 2013 11:45:45 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 3477C40107; Wed, 9 Jan 2013 19:45:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1357760742; bh=seGasQAvccDBxr+7BKf7oWyoDrCfnLWLZhOYocPu50c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=yGI5LGx32H8REvN/7Se6FwiuKNJKyG5FFWNGtojm1IJKKUI214Gg8jT2eS+VXB7fc UjmZ1yxSeBRqVnku0pSEyFF43iAd8w8RRHiifyHUuzGqYcT5GFKf5onxllymCFxeuo xMyrCn32u6WuZQWg6ldGmghrehE/af7zyZI8Efig= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 1E83CB433D; Wed, 9 Jan 2013 19:41:18 +0000 (UTC) From: James Cloos To: IETF DANE WG In-Reply-To: (Tony Finch's message of "Wed, 9 Jan 2013 18:41:12 +0000") References: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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, 09 Jan 2013 14:41:18 -0500 Message-ID: Lines: 49 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130109:dane@ietf.org::Nd7Z6WJ5vgjhZEBF:0000Qidg X-Hashcash: 1:30:130109:dot@dotat.at::VTcJGWv0cDk21oWm:0000Cn6EP X-Hashcash: 1:30:130109:warren@kumari.net::31R/gkBJy49eY0+a:0000000000000000000000000000000000000000000Bu/bW Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 09 Jan 2013 19:45:49 -0000 >>>>> "TF" == Tony Finch writes: TF> James Cloos wrote: >> A point of discussion is what, if anything, the receiving MTA should do >> dane-wise with and cert offered by the sending MTA. TF> I think this might be interesting to pursue but it could be a deep rat TF> hole. I prefer to get server authentication complete first. Separate draft, then? TF> I believe it would not be feasible to tie the sending host identity to the TF> sending mail domain. That would repeat the error made by SPF. So the only TF> benefit we can get is authenticating the sending host; some other TF> mechanism (i.e. DKIM) is necessary for higher-level identities. +100. I only thought of it as a link in the chain. *If* all of the Received come with confirmed cert comments then *maybe* the path is a bit more trustworthy. Maybe even two bits. :) TF> What benefit would client authentication give you? At the moment we TF> usually assume that bidirectional TCP is good enough for us to believe the TF> client IP address; this is evidently a bit shaky given the lack of routing TF> security, but even if we had secure routing we could still be open to TF> spoofing attacks from sufficiently well-placed on-path attackers. Just a link in a chain, akin to a path through a (weak) web of trust. TF> For intra-domain mail, client authentication is useful for gaining TF> permission to relay arbitrary mail. It's perfectly sensible to use client TF> certificates for this, probably validated using a private CA. If DANE TF> takes off it might be preferable to use the DNS instead. Again, well stated. TF> For inter-domain mail the client IP address is looked up in reputation TF> services and used for tracing and logging. You might care about making TF> this harder to spoof, but it's fairly marginal I think. Indeed. Hense just a bit or so more trustworthy. But in some cases maybe that bit is a back-reinforcing bit? My primary MX shows about 1/8 of my recent mail came from MXs which presented a cert signed by something in my dist's root pool, and about 3/8 were anonymous tls, leaving about 1/2 clear text. FWIW. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From fanf2@hermes.cam.ac.uk Thu Jan 10 03:52: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 79D1021F88BC for ; Thu, 10 Jan 2013 03:52:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GLJUcv7ipKI for ; Thu, 10 Jan 2013 03:52:49 -0800 (PST) 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 C4D1121F88BE for ; Thu, 10 Jan 2013 03:52:47 -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 hermes-1.csi.cam.ac.uk ([131.111.8.51]:42547) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1TtGge-0001Cn-St (Exim 4.72) (return-path ); Thu, 10 Jan 2013 11:52:44 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TtGge-0004jb-Oh (Exim 4.72) (return-path ); Thu, 10 Jan 2013 11:52:44 +0000 Date: Thu, 10 Jan 2013 11:52:44 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: James Cloos In-Reply-To: Message-ID: References: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> 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 Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 10 Jan 2013 11:52:58 -0000 James Cloos wrote: > > My primary MX shows about 1/8 of my recent mail came from MXs which > presented a cert signed by something in my dist's root pool, and about > 3/8 were anonymous tls, leaving about 1/2 clear text. FWIW. Client certificates? I thought they were nonexistent for mail to MXs. Years ago when I did some preliminary experiments to prepare for enabling TLS support on our servers, I turned on an option for the server to request a client certificate. (TLS clients do not send their certificates unless asked.) This was supposed to be optional, but many clients treated it as a demand and aborted the connection, which was not what I wanted. (It implied you can't support password authentication and certificate authentication on the same server.) So I would be wary of turning on the same option on an MX! 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 cloos@jhcloos.com Thu Jan 10 09:43: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 12CC321F8A27 for ; Thu, 10 Jan 2013 09:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, NO_RELAYS=-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 0a9E2R5+xIs8 for ; Thu, 10 Jan 2013 09:43:04 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:4830:1662::53]) by ietfa.amsl.com (Postfix) with ESMTP id 7842B21F8A55 for ; Thu, 10 Jan 2013 09:43:03 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id CB6614017A; Thu, 10 Jan 2013 17:42:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1357839779; bh=aijoels9KdJDCsOwPqBzaPvApV0lK4YqeThIwSgGxCE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=UCFuvstEQUu2tGHi13MM+5Sxa+wX5KiRVTa9Qr993VhkgtKg+1j2kl5GKTLALhbKt V52gj+GluRqBz08CXDA+h+U7xnj+0pK3z6IIPaUnqCc+wQX5VqTfl8i+tuGZKBCJ2d YKlCCmomMVtRCbx1k1vxkhIioBxvl2cKZgrf/bAw= Received: by carbon.jhcloos.org (Postfix, from userid 500) id ED857ACA6E; Thu, 10 Jan 2013 17:25:43 +0000 (UTC) From: James Cloos To: Tony Finch In-Reply-To: (Tony Finch's message of "Thu, 10 Jan 2013 11:52:44 +0000") References: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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, 10 Jan 2013 12:25:43 -0500 Message-ID: Lines: 44 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130110:dot@dotat.at::CSwS0Y3wejr7YadH:0000u1CiY X-Hashcash: 1:30:130110:dane@ietf.org::4+JL59BEqTr2pklq:000O+O1E X-Hashcash: 1:30:130110:warren@kumari.net::3L32LNIw+1mG0XGD:0000000000000000000000000000000000000000000m+xW1 Cc: IETF DANE WG Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 10 Jan 2013 17:43:06 -0000 >>>>> "TF" == Tony Finch writes: TF> Client certificates? I thought they were nonexistent for mail to MXs. Yes. An example from lists.debian.org: Received: from bendel.debian.org (bendel.debian.org [82.195.75.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "bendel.debian.org", Issuer "ca.debian.org" (verified OK)) by pao.uu.jhcloos.net (Postfix) with ESMTPS id 1CAFE23CC56 for ; Tue, 8 Jan 2013 06:22:46 +0000 (UTC) and from mail from a goog group: Received: from mail-ie0-f191.google.com (mail-ie0-f191.google.com [209.85.223.191]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by pao.uu.jhcloos.net (Postfix) with ESMTPS id 3D04E23C010 for ; Thu, 10 Jan 2013 07:04:25 +0000 (UTC) OTOH, mail from a list at alioth.debian looks like: Received: from wagner.debian.org (wagner.debian.org [217.196.43.132]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pao.uu.jhcloos.net (Postfix) with ESMTPS id 9498E23C034 for ; Thu, 10 Jan 2013 07:58:00 +0000 (UTC) I have pf configured to request but not require a cert. Primarily just to see what they do. TF> ... I turned on an option for the server to request a client TF> certificate. ... This was supposed to be optional, but many clients TF> treated it as a demand and aborted the connection, which was not TF> what I wanted. I've not seen any such issue since I turned on the requests. I just added smtpd_tls_ask_ccert = yes to my postfix main.cf. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From hallam@gmail.com Thu Jan 10 11:59: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 8907D21F8922 for ; Thu, 10 Jan 2013 11:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 WnI0qygH-iiS for ; Thu, 10 Jan 2013 11:59:31 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0E53F21F8920 for ; Thu, 10 Jan 2013 11:59:30 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id ep20so1052238lab.18 for ; Thu, 10 Jan 2013 11:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6XajXY5uxT+eQ7hEzvtuGYE1W+kbtpbQeN6qBRB1/S4=; b=IOEeX9eGhxgn0obc0k+Z7EUloz56Od4n3nrpf4aQMXBgUnGzsX6Euy0q48IdE7c3+m kc5XGD/2E6ac5hrksvBVDzwDa8LmJv2InZbdPzmEAR10GbLKQ1XuzSNyYbHK9nmstZSC 9wbIO5hsjhBc3d8xGXv/aS+RyX9uqXN8iw6UxoJF7Zn87SzJOtDEAcRyAnSj6DJSZl8c fzqvb7T0Qgl8HBL6qM0hMeDKzw2HZoHCe7rRzRLKyreXkcQdLdODZdMWhXSVMAfguYLa zHlJ6SAAozqH2mgLRRFXFFMVbrVTYenYPNMah1pgtZen27LdGHf2oOYX6xUJKLiGMhwT gVzw== MIME-Version: 1.0 Received: by 10.152.125.136 with SMTP id mq8mr70399006lab.41.1357847969834; Thu, 10 Jan 2013 11:59:29 -0800 (PST) Received: by 10.112.60.166 with HTTP; Thu, 10 Jan 2013 11:59:29 -0800 (PST) In-Reply-To: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> References: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> Date: Thu, 10 Jan 2013 14:59:29 -0500 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: multipart/alternative; boundary=f46d042f9756e6a4cd04d2f49dc3 Cc: IETF DANE WG list Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 10 Jan 2013 19:59:32 -0000 --f46d042f9756e6a4cd04d2f49dc3 Content-Type: text/plain; charset=ISO-8859-1 I would like the draft to be more clear in section 3.2 If any of these checks fail, the client MUST disconnect from the server and treat this as a temporary failure. The client can now proceed to deliver mail securely. Rather than assume that the preceding sentence will be treated as throwing an exception, I think the last line needs to say 'If all the checks succeed, the client can now proceed...' The dufus implementation risk here is that someone writes code that checks for DANE SMTP records and falls back to plain SMTP after a cert check fails. No, I don't think that is a reasonable interpretation but having seen some pretty idiotic stuff over the years, I think it needs to be called out more clearly. One of the reasons we could not deploy S/MIME when phishing email started to be a problem was that the chuckleheads at AOL responded to signed email with a message box saying 'WARNING, THE MESSAGE YOU HAVE RECEIVED IS SIGNED'. It was fixed later but the deployed base was prohibitive. On Thu, Dec 20, 2012 at 12:17 PM, Warren Kumari wrote: > Dear DANE Working Group, > > This starts a 4-week (because of time of year) consensus call on adopting > draft-fanf-dane-smtp-04 as a DANE WG document. > > ----- DRAFT INFO ---- > Title : Secure SMTP with TLS, DNSSEC and TLSA records. > Author(s) : Tony Finch > Filename : draft-fanf-dane-smtp-04.txt > > Abstract: > SMTP has a STARTTLS extension, but (especially in the case of inter- > domain mail transfer) it only provides very limited security because > it does not specify how to authenticate the server's certificate. > This memo specifies how TLSA records in the DNS can be used for > proper SMTP server authentication. > > > Datatracker page: https://datatracker.ietf.org/doc/draft-fanf-dane-smtp/ > TXT URL: http://www.ietf.org/id/draft-fanf-dane-smtp-04.txt > HTML URL: http://tools.ietf.org/html/draft-fanf-dane-smtp-04 > PDF URL: http://tools.ietf.org/pdf/draft-fanf-dane-smtp-04.pdf > > > Please read the document and state your opinions either for or against > adoption (with reasoning why!) on the mailing list. > > We note that this document has already received a bunch of discussion > onlist and in WG sessions. > > The call for adoption ends 20th January 2013. > > Thanks, > Ondrej and Warren. > > -- > Never criticize a man till you've walked a mile in his shoes. Then if he > didn't like what you've said, he's a mile away and barefoot. > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --f46d042f9756e6a4cd04d2f49dc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would like the draft to be more clear in section 3.2

<= pre class=3D"newpage" style=3D"font-size:1em;margin-top:0px;margin-bottom:0= px"> If any of these checks fail, the client MUST disconnect from the server and treat this as a temporary failure. The client can now proceed to deliver mail securely.
Rather than assume that the preceding sentence will be treated = as throwing an exception, I think the last line needs to say 'If all th= e checks succeed, the client can now proceed...'

The dufus implementation risk here is that someone writ= es code that checks for DANE SMTP records and falls back to plain SMTP afte= r a cert check fails.

No, I don't think that i= s a reasonable interpretation but having seen some pretty idiotic stuff ove= r the years, I think it needs to be called out more clearly. One of the rea= sons we could not deploy S/MIME when phishing email started to be a problem= was that the chuckleheads at AOL responded to signed email with a message = box saying 'WARNING, THE MESSAGE YOU HAVE RECEIVED IS SIGNED'. It w= as fixed later but the deployed base was prohibitive.


On Thu, Dec 20, 2012 at = 12:17 PM, Warren Kumari <warren@kumari.net> wrote:
Dear DANE Working Group,

This starts a 4-week (because of time of year) consensus call on adopting = =A0draft-fanf-dane-smtp-04 as a DANE WG document.

----- DRAFT INFO ----
Title =A0 =A0 =A0 =A0 =A0 : Secure SMTP with TLS, DNSSEC and TLSA records.<= br> Author(s) =A0 =A0 =A0 : Tony Finch
Filename =A0 =A0 =A0 =A0: draft-fanf-dane-smtp-04.txt

Abstract:
=A0 =A0SMTP has a STARTTLS extension, but (especially in the case of inter-=
=A0 =A0domain mail transfer) it only provides very limited security because=
=A0 =A0it does not specify how to authenticate the server's certificate= .
=A0 =A0This memo specifies how TLSA records in the DNS can be used for
=A0 =A0proper SMTP server authentication.


Datatracker page: https://datatracker.ietf.org/doc/draft-fanf-dan= e-smtp/
TXT URL: http://www.ietf.org/id/draft-fanf-dane-smtp-04.txt
HTML URL: =A0http://tools.ietf.org/html/draft-fanf-dane-smtp-04 PDF URL: http://tools.ietf.org/pdf/draft-fanf-dane-smtp-04.pdf=


Please read the document and state your opinions either for or against adop= tion (with reasoning why!) on the mailing list.

We note that this document has already received a bunch of discussion onlis= t and in WG sessions.

The call for adoption ends 20th January 2013.

Thanks,
=A0 =A0 =A0Ondrej and Warren.

--
Never criticize a man till you've walked a mile in his shoes. =A0Then i= f he didn't like what you've said, he's a mile away and barefoo= t.



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



-- Website: http://hallambaker.com/<= br>
--f46d042f9756e6a4cd04d2f49dc3-- From mrex@sap.com Thu Jan 10 12:26: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 317B621F8583 for ; Thu, 10 Jan 2013 12:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.889 X-Spam-Level: X-Spam-Status: No, score=-9.889 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, 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 jNas-p4ckIF8 for ; Thu, 10 Jan 2013 12:26:35 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1259821F857B for ; Thu, 10 Jan 2013 12:26:34 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0AKQUnh008617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Jan 2013 21:26:30 +0100 (MET) In-Reply-To: To: James Cloos Date: Thu, 10 Jan 2013 21:26:30 +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: <20130110202630.510841A44B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: IETF DANE WG Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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: Thu, 10 Jan 2013 20:26:36 -0000 The problem with Client certs for smtpd is that basically you will have to violate the TLS protocol to not run into connection failures. SSLv3 and TLSv1.0 *REQUIRE* the TLS server to send a list of (acceptable) certificate_authorities (distinguished names) in the CertificateRequest handshake message, and sending an empty list is a protocol violation. While there was a silent change in the CertificateRequest PDU definition in TLSv1.1 (rfc4346) that appears to allow an empty list, there are no semantics defined in TLSv1.1 and TLSv1.2, so this PDU change is a defect in the TLS v1.1+v1.2 spec and must not be used. http://tools.ietf.org/html/rfc2246#section-7.4.4 opaque DistinguishedName<1..2^16-1>; struct { ClientCertificateType certificate_types<1..2^8-1>; DistinguishedName certificate_authorities<3..2^16-1>; } CertificateRequest; If you really believe that you want to violate the TLS protocol in this fashion, please state (a) that you're intentionally violating the TLS protocol (b) what the exact desired semantics of this behaviour are -Martin James Cloos wrote: > > TF> Client certificates? I thought they were nonexistent for mail to MXs. > > Yes. An example from lists.debian.org: > > Received: from bendel.debian.org (bendel.debian.org [82.195.75.100]) > (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) > (Client CN "bendel.debian.org", Issuer "ca.debian.org" (verified OK)) > by pao.uu.jhcloos.net (Postfix) with ESMTPS id 1CAFE23CC56 > for ; Tue, 8 Jan 2013 06:22:46 +0000 (UTC) > > and from mail from a goog group: > > Received: from mail-ie0-f191.google.com (mail-ie0-f191.google.com [209.85.223.191]) > (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) > (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) > by pao.uu.jhcloos.net (Postfix) with ESMTPS id 3D04E23C010 > for ; Thu, 10 Jan 2013 07:04:25 +0000 (UTC) > > OTOH, mail from a list at alioth.debian looks like: > > Received: from wagner.debian.org (wagner.debian.org [217.196.43.132]) > (using TLSv1 with cipher AES256-SHA (256/256 bits)) > (Client did not present a certificate) > by pao.uu.jhcloos.net (Postfix) with ESMTPS id 9498E23C034 > for ; Thu, 10 Jan 2013 07:58:00 +0000 (UTC) > > I have pf configured to request but not require a cert. > > Primarily just to see what they do. > > TF> ... I turned on an option for the server to request a client > TF> certificate. ... This was supposed to be optional, but many clients > TF> treated it as a demand and aborted the connection, which was not > TF> what I wanted. > > I've not seen any such issue since I turned on the requests. > > I just added smtpd_tls_ask_ccert = yes to my postfix main.cf. > > -JimC > -- > James Cloos OpenPGP: 1024D/ED7DAEA6 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From hallam@gmail.com Thu Jan 10 16:29:17 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 9B39F21F84F0 for ; Thu, 10 Jan 2013 16:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1] 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 u235DhsbEUY1 for ; Thu, 10 Jan 2013 16:29:16 -0800 (PST) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0340521F87A3 for ; Thu, 10 Jan 2013 16:29:15 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id em20so1260438lab.14 for ; Thu, 10 Jan 2013 16:29:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ktqVtnE/zoXa00t3Ok1gX6cd3Yo+IvyOUfX2aw9o5zg=; b=oqPMFasPXrQDx+O5RlWHNAzPHSZ3XG1crt2moywcxG3qnt3UZaDfUa2nKlNfOl7eJM PWygIomeRAEIN0nXaXELPOGGUGwMUHyO65XTzuhXKYVYH3mDQFUC54cmnIhXSGbj46Ew EhQskEvN9h1EBYbe+7QTa/YdBXY2b2r38qgh0tbmVphYJum8SQB6N+Rmxj5+NLwrldb1 IJBAzsvriY/1DBhMSOMcfYqknxGbEkLLSoB/ing/ch53y3oyycU66vt0V73DxjCvqaGI cD5fY27IBhLQd0RZlRlqsE2jqQ+DuyWzGvpVCSQgHR+3ddCF4+YMrWxnFxIYI7e1Kzwg A6Rg== MIME-Version: 1.0 Received: by 10.112.29.71 with SMTP id i7mr30217462lbh.85.1357864154695; Thu, 10 Jan 2013 16:29:14 -0800 (PST) Received: by 10.112.60.166 with HTTP; Thu, 10 Jan 2013 16:29:14 -0800 (PST) In-Reply-To: <20130110202630.510841A44B@ld9781.wdf.sap.corp> References: <20130110202630.510841A44B@ld9781.wdf.sap.corp> Date: Thu, 10 Jan 2013 19:29:14 -0500 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=f46d040168f1980b1004d2f862ab Cc: IETF DANE WG Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 11 Jan 2013 00:29:17 -0000 --f46d040168f1980b1004d2f862ab Content-Type: text/plain; charset=ISO-8859-1 Using terms like 'break' is inappropriate here. If the protocol does not have the desired behavior then it is being fixed, not broken. The whole point of IETF protocols is that you can extend them and adapt them. If the protocol gets in the way, fix the protocol. One option here would be to define a new flag to announce a client cert availability on some different basis. Another would be to publish the cert through DKIM. On Thu, Jan 10, 2013 at 3:26 PM, Martin Rex wrote: > The problem with Client certs for smtpd is that basically you will > have to violate the TLS protocol to not run into connection failures. > > SSLv3 and TLSv1.0 *REQUIRE* the TLS server to send a list > of (acceptable) certificate_authorities (distinguished names) > in the CertificateRequest handshake message, and sending an empty > list is a protocol violation. While there was a silent change > in the CertificateRequest PDU definition in TLSv1.1 (rfc4346) > that appears to allow an empty list, there are no semantics > defined in TLSv1.1 and TLSv1.2, so this PDU change is a defect > in the TLS v1.1+v1.2 spec and must not be used. > > http://tools.ietf.org/html/rfc2246#section-7.4.4 > > opaque DistinguishedName<1..2^16-1>; > > struct { > ClientCertificateType certificate_types<1..2^8-1>; > DistinguishedName certificate_authorities<3..2^16-1>; > } CertificateRequest; > > > If you really believe that you want to violate the TLS protocol > in this fashion, please state > > (a) that you're intentionally violating the TLS protocol > (b) what the exact desired semantics of this behaviour are > > -Martin > > > James Cloos wrote: > > > > TF> Client certificates? I thought they were nonexistent for mail to MXs. > > > > Yes. An example from lists.debian.org: > > > > Received: from bendel.debian.org (bendel.debian.org [82.195.75.100]) > > (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) > > (Client CN "bendel.debian.org", Issuer "ca.debian.org" (verified > OK)) > > by pao.uu.jhcloos.net (Postfix) with ESMTPS id 1CAFE23CC56 > > for ; Tue, 8 Jan 2013 06:22:46 +0000 (UTC) > > > > and from mail from a goog group: > > > > Received: from mail-ie0-f191.google.com (mail-ie0-f191.google.com[209.85.223.191]) > > (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) > > (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" > (verified OK)) > > by pao.uu.jhcloos.net (Postfix) with ESMTPS id 3D04E23C010 > > for ; Thu, 10 Jan 2013 07:04:25 +0000 (UTC) > > > > OTOH, mail from a list at alioth.debian looks like: > > > > Received: from wagner.debian.org (wagner.debian.org [217.196.43.132]) > > (using TLSv1 with cipher AES256-SHA (256/256 bits)) > > (Client did not present a certificate) > > by pao.uu.jhcloos.net (Postfix) with ESMTPS id 9498E23C034 > > for ; Thu, 10 Jan 2013 07:58:00 +0000 (UTC) > > > > I have pf configured to request but not require a cert. > > > > Primarily just to see what they do. > > > > TF> ... I turned on an option for the server to request a client > > TF> certificate. ... This was supposed to be optional, but many clients > > TF> treated it as a demand and aborted the connection, which was not > > TF> what I wanted. > > > > I've not seen any such issue since I turned on the requests. > > > > I just added smtpd_tls_ask_ccert = yes to my postfix main.cf. > > > > -JimC > > -- > > James Cloos OpenPGP: 1024D/ED7DAEA6 > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --f46d040168f1980b1004d2f862ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Using terms like 'break' is inappropriate here. If the protoco= l does not have the desired behavior then it is being fixed, not broken.

The whole point of IETF protocols is that you can ex= tend them and adapt them. If the protocol gets in the way, fix the protocol= .

One option here would be to define a new flag to announ= ce a client cert availability on some different basis.

=
Another would be to publish the cert through DKIM.


On Thu, Jan 10, 2013 at 3:26 PM, Martin= Rex <mrex@sap.com> wrote:
The problem with Client certs for smtpd is that basically you will
have to violate the TLS protocol to not run into connection failures.

SSLv3 and TLSv1.0 *REQUIRE* the TLS server to send a list
of (acceptable) certificate_authorities (distinguished names)
in the CertificateRequest handshake message, and sending an empty
list is a protocol violation. =A0While there was a silent change
in the CertificateRequest PDU definition in TLSv1.1 (rfc4346)
that appears to allow an empty list, there are no semantics
defined in TLSv1.1 and TLSv1.2, so this PDU change is a defect
in the TLS v1.1+v1.2 spec and must not be used.

=A0 http://tools.ietf.org/html/rfc2246#section-7.4.4

=A0 =A0 =A0 =A0opaque DistinguishedName<1..2^16-1>;

=A0 =A0 =A0 =A0struct {
=A0 =A0 =A0 =A0 =A0 =A0ClientCertificateType certificate_types<1..2^8-1&= gt;;
=A0 =A0 =A0 =A0 =A0 =A0DistinguishedName certificate_authorities<3..2^16= -1>;
=A0 =A0 =A0 =A0} CertificateRequest;


If you really believe that you want to violate the TLS protocol
in this fashion, please state

=A0(a) that you're intentionally violating the TLS protocol
=A0(b) what the exact desired semantics of this behaviour are

-Martin


James Cloos wrote:
>
> TF> Client certificates? I thought they were nonexistent for mail t= o MXs.
>
> Yes. =A0An example from lists.debian.org:
>
> Received: from = bendel.debian.org (bendel.debian.org [82.195.75.100])
> =A0 =A0 =A0 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)= )
> =A0 =A0 =A0 (Client CN "bendel.debian.org", Issuer "ca.debian.org" (verified OK))
> =A0 =A0 =A0 by pao.uu.jhcloos.net (Postfix) with ESMTPS id 1CAFE23CC56
> =A0 =A0 =A0 for <cloos@jhcloos= .com>; Tue, =A08 Jan 2013 06:22:46 +0000 (UTC)
>
> and from mail from a goog group:
>
> Received: from mail-ie0-f191.google.com (mail-ie0-f191.google.com [209.85.223.191])
> =A0 =A0 =A0 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))=
> =A0 =A0 =A0 (Client CN "smtp.gmail.com", Issuer "Google Internet Authorit= y" (verified OK))
> =A0 =A0 =A0 by pao.uu.jhcloos.net (Postfix) with ESMTPS id 3D04E23C010
> =A0 =A0 =A0 for <cloos@jhcloos= .com>; Thu, 10 Jan 2013 07:04:25 +0000 (UTC)
>
> OTOH, mail from a list at alioth.debian looks like:
>
> Received: from = wagner.debian.org (wagner.debian.org [217.196.43.132])
> =A0 =A0 =A0 (using TLSv1 with cipher AES256-SHA (256/256 bits))
> =A0 =A0 =A0 (Client did not present a certificate)
> =A0 =A0 =A0 by pao.uu.jhcloos.net (Postfix) with ESMTPS id 9498E23C034
> =A0 =A0 =A0 for <cloos@jhcloos= .com>; Thu, 10 Jan 2013 07:58:00 +0000 (UTC)
>
> I have pf configured to request but not require a cert.
>
> Primarily just to see what they do.
>
> TF> ... I turned on an option for the server to request a client > TF> certificate. ... =A0This was supposed to be optional, but many = clients
> TF> treated it as a demand and aborted the connection, which was no= t
> TF> what I wanted.
>
> I've not seen any such issue since I turned on the requests.
>
> I just added smtpd_tls_ask_ccert =3D yes to my postfix main.cf.
>
> -JimC
> --
> James Cloos <cloos@jhcloos.com= > =A0 =A0 =A0 =A0 OpenPGP: 1024D/ED7DAEA6
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
= Website: http://hallambaker.com/
--f46d040168f1980b1004d2f862ab-- From mrex@sap.com Thu Jan 10 21:18: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 EA34521F8A6C for ; Thu, 10 Jan 2013 21:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.864 X-Spam-Level: X-Spam-Status: No, score=-9.864 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, 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 tRbLBe+jFpMG for ; Thu, 10 Jan 2013 21:18:22 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDD521F8A54 for ; Thu, 10 Jan 2013 21:18:21 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r0B5IJV0015487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jan 2013 06:18:19 +0100 (MET) In-Reply-To: To: Phillip Hallam-Baker Date: Fri, 11 Jan 2013 06:18:19 +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: <20130111051819.700971A44C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: IETF DANE WG Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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: Fri, 11 Jan 2013 05:18:24 -0000 Before diving into the details, I'm having difficulties to see a purpose of DANE client-certs for SMTP-AUTH / STARTTLS. When it is about MUA->MTA (to distinguish "paying" customers from spammers looking for an open mail relay), many clients will be roaming around and use temporary, DHCP-assigned addresses from varying domains. When it is about MTA->MTA, I fail to see the benefit, because it can not possibly prevent a mail from getting delivered given the installed base. And assessing the validity of the mail itself is DKIMs job, not that SMTP-AUTH. Phillip Hallam-Baker wrote: > > Using terms like 'break' is inappropriate here. If the protocol does not > have the desired behavior then it is being fixed, not broken. The TLS protocol (at least SSLv3 and TLSv1.0) is _not_ broken, just the opposite. But the behaviour that seems to be desired here is clearly deep into undefined territory. When requesting client certs in an infrastructure like SMTP-with-STARTTLS, where there exist lots of self-signed certs, you might be in for some surprises (about TLS connection failures). My knowledge about hands-on OpenSSL behaviour is quite rusty, but looking at the current openssl-1.0.1c source -- unless the application writes and supplied its own customer Certificate verifier function, there exist only two generic verification options; SSL_VERIFY_PEER and SSL_VERIFY_NONE, and the latter is not even available on the server SSL (i.e. when checking the client cert): s3_clnt: i=ssl_verify_cert_chain(s,sk); if ((s->verify_mode != SSL_VERIFY_NONE) && (i <= 0) ) { al=ssl_verify_alarm_type(s->verify_result); SSLerr(SSL_F_SSL3_GET_SERVER_CERTIFICATE,SSL_R_CERTIFICATE_VERIFY_FAILED); goto f_err; } ERR_clear_error(); /* but we keep s->verify_result */ s3_srvr.c: i=ssl_verify_cert_chain(s,sk); if (i <= 0) { al=ssl_verify_alarm_type(s->verify_result); SSLerr(SSL_F_SSL3_GET_CLIENT_CERTIFICATE,SSL_R_NO_CERTIFICATE_RETURNED); goto f_err; } } [...] f_err: ssl3_send_alert(s,SSL3_AL_FATAL,al); } So when the server sends a CertificateRequest with an empty list of certification_authorities (which is a clear violation of the TLS protocol), and a defective TLSv1.0 client blindly sends a self-signed cert, or a cert from a private CA, there is a very high probability that the certificate path validation will fail. An SMTP server app on top of OpenSSL, which did not provide it's own fancy certificate path validation function, would be faced with a fatal handshake failure. Leaving the exact semantics, which are currently undefined within TLS, entirely up to the individual apps implementer, rather than writing them explicitly down into the SMTP-STARTTLS+DANE specification, would seem like a terribly bad idea. > > The whole point of IETF protocols is that you can extend them and adapt > them. If the protocol gets in the way, fix the protocol. The whole point of the IETF is to **STANDARDIZE** behaviour, and to provide expert review whether the solution the interest group / WG is working on, is sensical (or not). What happens much too often, though, is that protocol options and features remain seriously underspecified and it left up to the apps folks to come up with "interesting", implementation-defined behaviour. Not writing down the details, and what properties are being relied upon, is what cause the TLS renegotiation barn door to stand wide open for a whole decade, which the apps folks had been abusing for delayed authentication. > > One option here would be to define a new flag to announce a client cert > availability on some different basis. I believe this doesn't even scratch the surface of the problem. (1) This is about seperating certs into (a) client certs that can be verified by the server (b) client certs that can *NOT* be verified by the server (2) Either the server will have to convey to the client sufficient information that the client can reliably determine whether the client certificate it holds is of category (1a) -- which is what the "certificate_authorities" list in the CertificateRequest handshake message was designed for, but which doesn't really fit PKIX-free DANE usage. Or the server will have to be able to request from its TLS stack that the TLS session is established without any certificate path validation, and the app itself will have to sort out the mess all by itself, from an unverified client cert chain emitted by TLS. But that will require a lot of messy cert processing details in an apps spec, and may require changes to deployed TLS implementations before it can be used. -Martin > On Thu, Jan 10, 2013 at 3:26 PM, Martin Rex wrote: > > > The problem with Client certs for smtpd is that basically you will > > have to violate the TLS protocol to not run into connection failures. > > > > SSLv3 and TLSv1.0 *REQUIRE* the TLS server to send a list > > of (acceptable) certificate_authorities (distinguished names) > > in the CertificateRequest handshake message, and sending an empty > > list is a protocol violation. While there was a silent change > > in the CertificateRequest PDU definition in TLSv1.1 (rfc4346) > > that appears to allow an empty list, there are no semantics > > defined in TLSv1.1 and TLSv1.2, so this PDU change is a defect > > in the TLS v1.1+v1.2 spec and must not be used. > > > > http://tools.ietf.org/html/rfc2246#section-7.4.4 > > > > opaque DistinguishedName<1..2^16-1>; > > > > struct { > > ClientCertificateType certificate_types<1..2^8-1>; > > DistinguishedName certificate_authorities<3..2^16-1>; > > } CertificateRequest; > > > > > > If you really believe that you want to violate the TLS protocol > > in this fashion, please state > > > > (a) that you're intentionally violating the TLS protocol > > (b) what the exact desired semantics of this behaviour are > > > > -Martin > > > > > > James Cloos wrote: > > > > > > TF> Client certificates? I thought they were nonexistent for mail to MXs. > > > > > > Yes. An example from lists.debian.org: > > > > > > Received: from bendel.debian.org (bendel.debian.org [82.195.75.100]) > > > (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) > > > (Client CN "bendel.debian.org", Issuer "ca.debian.org" (verified > > OK)) > > > by pao.uu.jhcloos.net (Postfix) with ESMTPS id 1CAFE23CC56 > > > for ; Tue, 8 Jan 2013 06:22:46 +0000 (UTC) > > > > > > and from mail from a goog group: > > > > > > Received: from mail-ie0-f191.google.com (mail-ie0-f191.google.com[209.85.223.191]) > > > (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) > > > (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" > > (verified OK)) > > > by pao.uu.jhcloos.net (Postfix) with ESMTPS id 3D04E23C010 > > > for ; Thu, 10 Jan 2013 07:04:25 +0000 (UTC) > > > > > > OTOH, mail from a list at alioth.debian looks like: > > > > > > Received: from wagner.debian.org (wagner.debian.org [217.196.43.132]) > > > (using TLSv1 with cipher AES256-SHA (256/256 bits)) > > > (Client did not present a certificate) > > > by pao.uu.jhcloos.net (Postfix) with ESMTPS id 9498E23C034 > > > for ; Thu, 10 Jan 2013 07:58:00 +0000 (UTC) > > > > > > I have pf configured to request but not require a cert. > > > > > > Primarily just to see what they do. > > > > > > TF> ... I turned on an option for the server to request a client > > > TF> certificate. ... This was supposed to be optional, but many clients > > > TF> treated it as a demand and aborted the connection, which was not > > > TF> what I wanted. > > > > > > I've not seen any such issue since I turned on the requests. > > > > > > I just added smtpd_tls_ask_ccert = yes to my postfix main.cf. > > > > > > -JimC > > > -- > > > James Cloos OpenPGP: 1024D/ED7DAEA6 > > > _______________________________________________ > > > dane mailing list > > > dane@ietf.org > > > https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > > > > > > -- > Website: http://hallambaker.com/ From fanf2@hermes.cam.ac.uk Fri Jan 11 02:33: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 5CEB621F88B5 for ; Fri, 11 Jan 2013 02:33:26 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOuQJEbXzo-h for ; Fri, 11 Jan 2013 02:33:25 -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 3CF7921F88B2 for ; Fri, 11 Jan 2013 02:33:25 -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 hermes-1.csi.cam.ac.uk ([131.111.8.51]:42543) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1TtbvP-0005ZF-Y9 (Exim 4.72) (return-path ); Fri, 11 Jan 2013 10:33:23 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TtbvP-0006xh-I1 (Exim 4.72) (return-path ); Fri, 11 Jan 2013 10:33:23 +0000 Date: Fri, 11 Jan 2013 10:33:23 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Martin Rex In-Reply-To: <20130110202630.510841A44B@ld9781.wdf.sap.corp> Message-ID: References: <20130110202630.510841A44B@ld9781.wdf.sap.corp> 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 Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 11 Jan 2013 10:33:26 -0000 Martin Rex wrote: > The problem with Client certs for smtpd is that basically you will > have to violate the TLS protocol to not run into connection failures. > > SSLv3 and TLSv1.0 *REQUIRE* the TLS server to send a list > of (acceptable) certificate_authorities (distinguished names) > in the CertificateRequest handshake message, and sending an empty > list is a protocol violation. Right, but the client does not have to present a certificate in response, and the server can still let the connection proceed. 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 fanf2@hermes.cam.ac.uk Fri Jan 11 04:47: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 CEEDC21F88EF for ; Fri, 11 Jan 2013 04:47:35 -0800 (PST) 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] 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 2mNVkW7Bmp5n for ; Fri, 11 Jan 2013 04:47:34 -0800 (PST) Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7E65D21F88E6 for ; Fri, 11 Jan 2013 04:47:34 -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 hermes-1.csi.cam.ac.uk ([131.111.8.51]:55370) by ppsw-43.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Tte1B-00008z-nU (Exim 4.72) (return-path ); Fri, 11 Jan 2013 12:47:29 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Tte1B-0007PL-8M (Exim 4.72) (return-path ); Fri, 11 Jan 2013 12:47:29 +0000 Date: Fri, 11 Jan 2013 12:47:29 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> 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] Call for Adoption - draft-fanf-dane-smtp-04 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, 11 Jan 2013 12:47:36 -0000 Phillip Hallam-Baker wrote: > I would like the draft to be more clear in section 3.2 > > If any of these checks fail, the client MUST disconnect from the > server and treat this as a temporary failure. > > The client can now proceed to deliver mail securely. > > Rather than assume that the preceding sentence will be treated as > throwing an exception, I think the last line needs to say 'If all the > checks succeed, the client can now proceed...' Good suggestion, thanks :-) 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 fanf2@hermes.cam.ac.uk Fri Jan 11 05:02:50 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 30F5021F87AD for ; Fri, 11 Jan 2013 05:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 n7v0S-Hz+1TF for ; Fri, 11 Jan 2013 05:02:49 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id D6D3A21F8849 for ; Fri, 11 Jan 2013 05:02:48 -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 hermes-1.csi.cam.ac.uk ([131.111.8.51]:49841) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1TteFz-0001Q8-q8 (Exim 4.72) (return-path ); Fri, 11 Jan 2013 13:02:47 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TteFz-0000lg-4P (Exim 4.72) (return-path ); Fri, 11 Jan 2013 13:02:47 +0000 Date: Fri, 11 Jan 2013 13:02:47 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Martin Rex In-Reply-To: <20130111051819.700971A44C@ld9781.wdf.sap.corp> Message-ID: References: <20130111051819.700971A44C@ld9781.wdf.sap.corp> 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 Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 11 Jan 2013 13:02:50 -0000 Martin Rex wrote: > > Or the server will have to be able to request from its TLS stack > that the TLS session is established without any certificate > path validation, and the app itself will have to sort out the > mess all by itself, from an unverified client cert chain emitted by TLS. > But that will require a lot of messy cert processing details > in an apps spec, and may require changes to deployed TLS implementations > before it can be used. These worries don't seem to cause significant problems in practice. 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 mrex@sap.com Fri Jan 11 05:06: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 CE4FA21F88EA for ; Fri, 11 Jan 2013 05:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.148 X-Spam-Level: X-Spam-Status: No, score=-10.148 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 pcTSY-SfYJym for ; Fri, 11 Jan 2013 05:06:35 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 96AB021F8877 for ; Fri, 11 Jan 2013 05:06:34 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0BD6R0S005550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jan 2013 14:06:28 +0100 (MET) In-Reply-To: To: Tony Finch Date: Fri, 11 Jan 2013 14:06:27 +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: <20130111130627.CCAFB1A452@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: IETF DANE WG Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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: Fri, 11 Jan 2013 13:06:35 -0000 Tony Finch wrote: > Martin Rex wrote: > > > > Or the server will have to be able to request from its TLS stack > > that the TLS session is established without any certificate > > path validation, and the app itself will have to sort out the > > mess all by itself, from an unverified client cert chain emitted by TLS. > > But that will require a lot of messy cert processing details > > in an apps spec, and may require changes to deployed TLS implementations > > before it can be used. > > These worries don't seem to cause significant problems in practice. http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf agreed, just a minor problem .... unless you care about security in any way. -Martin From fanf2@hermes.cam.ac.uk Fri Jan 11 05:49: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 72E7321F87E3 for ; Fri, 11 Jan 2013 05:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 j-mC+TPn0c5V for ; Fri, 11 Jan 2013 05:49:51 -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 5874121F879E for ; Fri, 11 Jan 2013 05:49:51 -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 hermes-1.csi.cam.ac.uk ([131.111.8.51]:56995) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1TtezV-0007nq-ZS (Exim 4.72) (return-path ); Fri, 11 Jan 2013 13:49:50 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TtezV-0006Ck-VV (Exim 4.72) (return-path ); Fri, 11 Jan 2013 13:49:49 +0000 Date: Fri, 11 Jan 2013 13:49:49 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Martin Rex In-Reply-To: <20130111130627.CCAFB1A452@ld9781.wdf.sap.corp> Message-ID: References: <20130111130627.CCAFB1A452@ld9781.wdf.sap.corp> 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 Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 11 Jan 2013 13:49:52 -0000 Martin Rex wrote: > Tony Finch wrote: > > Martin Rex wrote: > > > > > > Or the server will have to be able to request from its TLS stack > > > that the TLS session is established without any certificate > > > path validation, and the app itself will have to sort out the > > > mess all by itself, from an unverified client cert chain emitted by TLS. > > > But that will require a lot of messy cert processing details > > > in an apps spec, and may require changes to deployed TLS implementations > > > before it can be used. > > > > These worries don't seem to cause significant problems in practice. > > http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf > > agreed, just a minor problem .... unless you care about security in any way. That paper is about server certificate authentication not client certificate authentication, but it does rather reinforce your point about messy cert processing details. However one of the big problems with server authentication is poor support for name checking, which does not apply in the same way for client authentication. Servers can support optional client certificates with OpenSSL and GnuTLS and probably others. 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 warren@kumari.net Tue Jan 15 14:03: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 A45D411E80E1 for ; Tue, 15 Jan 2013 14:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 LarcD1zMVmyp for ; Tue, 15 Jan 2013 14:03:57 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6C011E80BA for ; Tue, 15 Jan 2013 14:03:57 -0800 (PST) Received: from [192.168.10.33] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id CA37B1B40925; Tue, 15 Jan 2013 17:03:56 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Tue, 15 Jan 2013 17:03:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: IETF DANE WG list X-Mailer: Apple Mail (2.1499) Subject: Re: [dane] Call for Adoption - draft-fanf-dane-mua-00 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, 15 Jan 2013 22:03:57 -0000 On Dec 20, 2012, at 12:17 PM, Warren Kumari wrote: > Dear DANE Working Group, >=20 > This starts a 4-week (because of time of year) consensus call on = adopting draft-fanf-dane-mua-00 as a DANE WG document.=20 >=20 > --- DRAFT INFO ---=20 > Draft: draft-fanf-dane-mua-00 > Title: DNSSEC and TLSA records for IMAP, POP3, and = message submission > Number of pages: 8 >=20 > URL: = http://www.ietf.org/internet-drafts/draft-fanf-dane-mua-00.txt > Status: http://datatracker.ietf.org/doc/draft-fanf-dane-mua > Htmlized: http://tools.ietf.org/html/draft-fanf-dane-mua-00 >=20 >=20 >=20 > Please read the document and state your opinions either for or against = adoption (with reasoning why!) on the mailing list. >=20 > The call for adoption ends 20th January 2013. And just a reminder to provide feedback on this draft as well (we have = gotten lots of feedback on the smtp draft, thank you!). W >=20 > Thanks, > Warren and Ondrej. >=20 > -- > Life is a concentration camp. You're stuck here and there's no way = out and you can only rage impotently against your persecutors. > -- Woody Allen >=20 >=20 >=20 >=20 -- "Have you got any previous convictions?" "Well, I dunno... I suppose I used to believe very firmly that a penny = saved is a penny earned--" -- Terry Pratchett From cloos@jhcloos.com Thu Jan 17 16:57: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 CA7F221F88BE for ; Thu, 17 Jan 2013 16:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, NO_RELAYS=-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 nzdVjkpZFI5r for ; Thu, 17 Jan 2013 16:56:59 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:4830:1662::53]) by ietfa.amsl.com (Postfix) with ESMTP id AEDE821F8AC8 for ; Thu, 17 Jan 2013 16:56:59 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id F16BA40113; Fri, 18 Jan 2013 00:56:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1358470614; bh=78VMiPghcFjX7oUn2tV0hEuwS8H6I7gjrgas2mkEl50=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=JFDrmdeJC9giEw5Er0WViE/INVHMW/7OMyaKUOSpWbUOlMni04+h/rEIC+uv5hehH TvPpX2s6XC9G5e7ifPUTts6/qaeHoeDGDGoC/IlEUAVhMxfWCnRXUTh7rV31O3cH6i 7EmauE10gIbsSVU+Tbo8lNmeKeld+80Z5WRhy41U= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 4C268647A0; Fri, 18 Jan 2013 00:55:59 +0000 (UTC) From: James Cloos To: dane@ietf.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, 17 Jan 2013 19:55:59 -0500 Message-ID: Lines: 53 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130118:dane@ietf.org::upj9lgRjTz9/mADq:000ANDrY Subject: [dane] draft-fanf-dane-smtp-04 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, 18 Jan 2013 00:57:00 -0000 Some comments: ,---- | Is the Transmitted: header useful enough to include in this spec? | Should it be dropped, or perhaps moved to another document? `---- It does seem useful; I'm indifferent to in this document or in a document of its own. ,---- | Is the description of DNSSEC validation over-done? Can it be trimmed | down so it relies more on the core DNSSEC specs? `---- Given the desire to ensure that partial tlsa provisioning doesn't block mail delivery, it seems squarely to have hit the as simple as needed but no simpler nail. ,---- | o If there is no TLSA record or its DNSSEC validation state is | insecure or indeterminate, this protocol has not been fully | deployed. The client SHOULD deliver to this server insecurely | (which might be over unauthenticated TLS). `---- In that case the target mta might offer a cert which the client mta can authenticate by some means other than dane (eg a pool in CApath or the like). So 'insecurely' is not the right adverb. I haven't come up with an alternative wording, though. ,---- | A SHALL include: | | o A clause describing the SMTP server. The | part of a SHALL be the same as the SMTP server host | name. `---- When would/could/should the To-domain not in its entirety match the string used for the A/AAAA and TLSA lookups? ,---- | 6.1. "with" protocol types `---- It seems odd that with is used for some auth but not all. Perhaps there should be a with keyword for tlsa, too? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From fanf2@hermes.cam.ac.uk Fri Jan 18 03:28: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 9350221F85E8 for ; Fri, 18 Jan 2013 03:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 HsScyPoiskBg for ; Fri, 18 Jan 2013 03:28:13 -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 7E59621F85D9 for ; Fri, 18 Jan 2013 03:28:13 -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 hermes-1.csi.cam.ac.uk ([131.111.8.51]:57429) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1TwA7H-0002cO-YT (Exim 4.72) (return-path ); Fri, 18 Jan 2013 11:28:11 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TwA7H-0003rM-LS (Exim 4.72) (return-path ); Fri, 18 Jan 2013 11:28:11 +0000 Date: Fri, 18 Jan 2013 11:28:11 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: James Cloos In-Reply-To: Message-ID: References: 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: dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp-04 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, 18 Jan 2013 11:28:15 -0000 James Cloos wrote: > Some comments: Thanks! > ,---- > | o If there is no TLSA record or its DNSSEC validation state is > | insecure or indeterminate, this protocol has not been fully > | deployed. The client SHOULD deliver to this server insecurely > | (which might be over unauthenticated TLS). > `---- > > In that case the target mta might offer a cert which the client mta can > authenticate by some means other than dane (eg a pool in CApath or the > like). So 'insecurely' is not the right adverb. The reason it says "insecurely" here is explained in the first couple of paragraphs in the introduction. Perhaps I should add a back-reference. > ,---- > | A SHALL include: > | > | o A clause describing the SMTP server. The > | part of a SHALL be the same as the SMTP server host > | name. > `---- > > When would/could/should the To-domain not in its entirety match the string > used for the A/AAAA and TLSA lookups? They always match - that is what the text you quoted is supposed to mean. > ,---- > | 6.1. "with" protocol types > `---- > > It seems odd that with is used for some auth but not all. Perhaps there > should be a with keyword for tlsa, too? Isn't that covered by RFC 3848? ESMTPSA and so forth. 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 cloos@jhcloos.com Fri Jan 18 16:35: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 283A521F86D2 for ; Fri, 18 Jan 2013 16:35:07 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkkX++g0wGG4 for ; Fri, 18 Jan 2013 16:35:06 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id 6590D21F8688 for ; Fri, 18 Jan 2013 16:35:06 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id ACC41404CB; Sat, 19 Jan 2013 00:34:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1358555703; bh=0qlU2ju9ER2Ze5jLYmvPvrAd56QNqGwl0e4wccPn7N8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=EWoBXgBZD7qIZlzwivswP++ILPcEwltb0kbdMuY0xoM7vTRJBkTFQ+bZR2Rgozv/X iuUfdKoMP6kCSeXi26m/y7sJNh8HYSh3JAU1icBai5zyxelUtPFHqLCbVf44XwSsCQ uQtRA3ajn8ymRdJI8hg6KLhI6eMAGw1sIlvjCJHs= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 9213564913; Sat, 19 Jan 2013 00:18:36 +0000 (UTC) From: James Cloos To: Tony Finch In-Reply-To: (Tony Finch's message of "Fri, 18 Jan 2013 11:28:11 +0000") References: 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, 18 Jan 2013 19:18:36 -0500 Message-ID: Lines: 45 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:130119:dot@dotat.at::TM17kEmtyCDKUnAh:0000GDeOl X-Hashcash: 1:30:130119:dane@ietf.org::cXOCGGHVyxHwsqsW:000f5G+m Cc: dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp-04 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, 19 Jan 2013 00:35:07 -0000 >>>>> "TF" == Tony Finch writes: TF> James Cloos wrote: >> Some comments: >> In that case the target mta might offer a cert which the client mta can >> authenticate by some means other than dane (eg a pool in CApath or the >> like). So 'insecurely' is not the right adverb. TF> The reason it says "insecurely" here is explained in the first couple of TF> paragraphs in the introduction. Perhaps I should add a back-reference. I must have forgotten the earlier note by the time I got down to that section. Perahps because I had to take some breaks while reading through it. A back-reference probably is a good idea. >> When would/could/should the To-domain not in its entirety match the string >> used for the A/AAAA and TLSA lookups? TF> They always match - that is what the text you quoted is supposed to mean. I always tend to read domain name more like dns zone than like host name. Even after all these years. You remind me that I should read it more akin to fully-qualified-domain-name. >> It seems odd that with is used for some auth but not all. Perhaps there >> should be a with keyword for tlsa, too? TF> Isn't that covered by RFC 3848? ESMTPSA and so forth. So ESMTPT is for any kind of TLS authentication of the starttls creds? Either tlsa rr or set of out-of-band-maintained trusted root certs? My instinct is that it would be useful to know *how* the starttls was authenticated, not just whether. (And, yes, by the time I got down that far I see that I did glaze over a bit. "when the client successfully authenticated the server." didn't click as intended, though it is obvious today. Modulus the above q.) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From warren@kumari.net Wed Jan 23 15:52: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 82B1021F8517 for ; Wed, 23 Jan 2013 15:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 QCFBZfH+HfgN for ; Wed, 23 Jan 2013 15:52:14 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A3221F8514 for ; Wed, 23 Jan 2013 15:52:13 -0800 (PST) Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 554EF1B401C6; Wed, 23 Jan 2013 18:52:12 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Wed, 23 Jan 2013 18:52:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <49D14EF2-E91A-417E-885D-257B1CDDAB0A@kumari.net> References: To: IETF DANE WG list , Tony Finch X-Mailer: Apple Mail (2.1499) Subject: [dane] Call for Adoption - draft-fanf-dane-mua-00 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, 23 Jan 2013 23:52:21 -0000 On Dec 20, 2012, at 12:17 PM, Warren Kumari wrote: > Dear DANE Working Group, >=20 > This starts a 4-week (because of time of year) consensus call on = adopting draft-fanf-dane-mua-00 as a DANE WG document.=20 >=20 > --- DRAFT INFO ---=20 > Draft: draft-fanf-dane-mua-00 > Title: DNSSEC and TLSA records for IMAP, POP3, and = message submission > Number of pages: 8 >=20 > URL: = http://www.ietf.org/internet-drafts/draft-fanf-dane-mua-00.txt > Status: http://datatracker.ietf.org/doc/draft-fanf-dane-mua > Htmlized: http://tools.ietf.org/html/draft-fanf-dane-mua-00 >=20 >=20 >=20 > Please read the document and state your opinions either for or against = adoption (with reasoning why!) on the mailing list. >=20 > The call for adoption ends 20th January 2013. Dear DANE Working Group, This concludes the call for adoption on this draft.=20 We judge there to be consensus to adopt this draft as a Working Group = draft. Authors, please resubmit this draft as draft-ietf-dane-mua. Thanks, Warren and Ondrej. >=20 > Thanks, > Warren and Ondrej. >=20 > -- > Life is a concentration camp. You're stuck here and there's no way = out and you can only rage impotently against your persecutors. > -- Woody Allen >=20 >=20 >=20 >=20 --- Schizophrenia beats being alone. From warren@kumari.net Wed Jan 23 15:53: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 05E0321F8514 for ; Wed, 23 Jan 2013 15:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 A11A8GUKptCd for ; Wed, 23 Jan 2013 15:53:17 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618DE21F84D9 for ; Wed, 23 Jan 2013 15:53:17 -0800 (PST) Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id D7B271B409B0; Wed, 23 Jan 2013 18:53:16 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <72DB59F0-8339-45AB-9D00-A768D7867358@kumari.net> Date: Wed, 23 Jan 2013 18:53:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2D3FA2BC-321C-49C5-948A-07F8A1CEFB56@kumari.net> References: <4630A3B9-1989-4E30-9194-D22C9A79CB59@kumari.net> <72DB59F0-8339-45AB-9D00-A768D7867358@kumari.net> To: IETF DANE WG list X-Mailer: Apple Mail (2.1499) Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04 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, 23 Jan 2013 23:53:18 -0000 On Jan 23, 2013, at 6:36 PM, Warren Kumari wrote: >=20 > On Dec 20, 2012, at 12:17 PM, Warren Kumari wrote: >=20 >> Dear DANE Working Group, >>=20 >> This starts a 4-week (because of time of year) consensus call on = adopting draft-fanf-dane-smtp-04 as a DANE WG document.=20 >>=20 >>=20 [ SNIP ]=20 >> The call for adoption ends 20th January 2013. Dear DANE Working Group, This concludes the call for adoption on this draft.=20 We judge there to be consensus to adopt this draft as a Working Group = draft. Authors, please resubmit this draft as draft-ietf-dane-. Thanks, Your friendly chairs... >=20 >=20 >=20 >>=20 >> Thanks, >> Ondrej and Warren. >>=20 >> --=20 >> Never criticize a man till you've walked a mile in his shoes. Then = if he didn't like what you've said, he's a mile away and barefoot.=20 >>=20 >>=20 >>=20 >=20 > -- > It is impossible to sharpen a pencil with a blunt axe. It is equally = vain > to try to do it with ten blunt axes instead. > -- E.W Dijkstra, 1930-2002 >=20 >=20 >=20 -- It is impossible to sharpen a pencil with a blunt axe. It is equally = vain to try to do it with ten blunt axes instead. -- E.W Dijkstra, 1930-2002 From internet-drafts@ietf.org Fri Jan 25 07:33: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 2A8E421F8606; Fri, 25 Jan 2013 07:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 CBRy0WVRx2-y; Fri, 25 Jan 2013 07:33:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E6521F8415; Fri, 25 Jan 2013 07:33:35 -0800 (PST) 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.37 Message-ID: <20130125153335.11147.27704.idtracker@ietfa.amsl.com> Date: Fri, 25 Jan 2013 07:33:35 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-00.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: Fri, 25 Jan 2013 15:33:36 -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 : Secure SMTP with TLS, DNSSEC and TLSA records. Author(s) : Tony Finch Filename : draft-ietf-dane-smtp-00.txt Pages : 15 Date : 2013-01-25 Abstract: SMTP has a STARTTLS extension, but (especially in the case of inter- domain mail transfer) it only provides very limited security because it does not specify how to authenticate the server's certificate. This memo specifies how TLSA records in the DNS can be used for proper SMTP server authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smtp-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From marc.lampo.ietf@gmail.com Wed Jan 30 00:11: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 37EAA21F8B25 for ; Wed, 30 Jan 2013 00:11:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwIFc9FZXgfQ for ; Wed, 30 Jan 2013 00:11:47 -0800 (PST) Received: from mail-vb0-f46.google.com (mail-vb0-f46.google.com [209.85.212.46]) by ietfa.amsl.com (Postfix) with ESMTP id A065A21F89AA for ; Wed, 30 Jan 2013 00:11:47 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id b13so867031vby.33 for ; Wed, 30 Jan 2013 00:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=+RBZNXJO/P4UTR106S+tFc2zwJwAtN9oeMZ9Y7M8KRw=; b=ZX3aRIMZyXFPPAT5w2fq9DCshuXodpOvEyRridZ3dAhHEuEja98M0xyE8xeaZEXZlZ hCa/rSYb8fuhtEEPEjb+1fUbDkbKIohlihDrRH/ab7xjQIz9OoiWNRUIW2Pil6saVI+j YDj7By70JdlHbh+GMj8QBcMRbMAlT4WROKZjvqfxVXPFdZm5yfhcLxDNGBo00SyVKKMY ofmWeGz3u7zSIz6puGO/H9sT/g7YE1EJ9jlo9+WpNuswohxpJ8gWxOn5ZrA5FTUpNd6Y fDjGS18OCdBrbnLA6AFXImq0CSJlO44fbDscq+iHLO+qkMgpnlvNuSajCzdnMAcmW+oW JNYA== MIME-Version: 1.0 X-Received: by 10.220.153.69 with SMTP id j5mr4099769vcw.35.1359533507120; Wed, 30 Jan 2013 00:11:47 -0800 (PST) Received: by 10.58.59.38 with HTTP; Wed, 30 Jan 2013 00:11:47 -0800 (PST) Date: Wed, 30 Jan 2013 09:11:47 +0100 Message-ID: From: Marc Lampo To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? 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, 30 Jan 2013 08:11:48 -0000 Hello, If a correct TLSA record for a domain would mean there is no warning to the user about : cannot verify certificate I'm a bit concerned about the value 3 for "Certificate Usage" ! Because there (value is 3), I read : "This certificate usage is sometimes referred to as "domain-issued certificate" because it allows for a domain name administrator to issue certificates for a domain without involving a third-party CA." So basically both the certificate (self signed) and the TLSA record (in the DNS of the domain) are under control of the owner of the domain name. But since domain registration can be quite anonymous doesn't this mean that anybody could, if support for TSLA is widespread, create https websites that do not cause warning messages to users. To me it seems that anybody could, kind of, produce his own identity card ? It that is the case, it would only increase the need for HTTPS inspection - "man-in-the-middle" - in which case the certificate offered to the user will change and no longer be "in line" with the TLSA record. Is that interpretation of that value 3, and its consequences, correct ? Or am I missing something terribly important ? Kind regards, Marc Lampo From Marco.Davids@sidn.nl Wed Jan 30 00:41: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 6EFC821F8745 for ; Wed, 30 Jan 2013 00:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] 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 rg0oPSVBavY7 for ; Wed, 30 Jan 2013 00:41:09 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id B502E21F86E8 for ; Wed, 30 Jan 2013 00:41:08 -0800 (PST) Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r0U8f7vj020568-r0U8f7vl020568 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Wed, 30 Jan 2013 09:41:07 +0100 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn01.SIDN.local (192.168.2.73) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 30 Jan 2013 09:41:06 +0100 Received: from [94.198.152.219] (94.198.152.219) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server id 14.2.328.9; Wed, 30 Jan 2013 09:41:06 +0100 Message-ID: <5108DCA2.5010806@sidn.nl> Date: Wed, 30 Jan 2013 09:41:06 +0100 From: "Marco Davids (SIDN)" Organization: SIDN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=9F781B52 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.219] Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? 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, 30 Jan 2013 08:41:09 -0000 On 01/30/13 09:11, Marc Lampo wrote: > But since domain registration can be quite anonymous > doesn't this mean that anybody could, if support for TSLA is widespread, > create https websites that do not cause warning messages to users. It does. In fact, this is identified as a security consideration (8.1.4) in the RFC. -- Marco From marc.lampo.ietf@gmail.com Wed Jan 30 00:57: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 80FA221F88BC for ; Wed, 30 Jan 2013 00:57:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIpZocAW+O5M for ; Wed, 30 Jan 2013 00:56:59 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8B421F8691 for ; Wed, 30 Jan 2013 00:56:59 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn17so3336922wib.6 for ; Wed, 30 Jan 2013 00:56:58 -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=39ThzD3aoXk91ccsUlV5xc/UgdawxddmHQwWGYH2uaM=; b=NDUm0NcyFpWx7PXtV7/goqJgn7tROP42ak1v0X3FXGYKOjF2byP34zyLVSfHA0KpPx vu8sJZaBs9XheqkERB2G6ymkF6N0C3+3Orfzh07Flb7o0m95ln6djPqAkeN3r9f2Bzy3 jQsXnn8PivAGX3FWTIYXbG3+8ivbhtysovrPWWvpI/FTp2nZj5nahij87k+dDYkvGbJv Q9wgH8Wyznx23myIzas3C8gqrnwp0v30QH96hCascfdvIfwoc46igYrBM+2+XwclMu7V WEF32xeiE8mp9HG4+V2ZaP5PbK5ihHSfFKDeauyPcd19xYVwvBl7QR+Bqqc9iB5JLZP1 2p2w== MIME-Version: 1.0 X-Received: by 10.194.58.175 with SMTP id s15mr7208791wjq.31.1359536218624; Wed, 30 Jan 2013 00:56:58 -0800 (PST) Received: by 10.194.14.2 with HTTP; Wed, 30 Jan 2013 00:56:58 -0800 (PST) In-Reply-To: <5108DCA2.5010806@sidn.nl> References: <5108DCA2.5010806@sidn.nl> Date: Wed, 30 Jan 2013 09:56:58 +0100 Message-ID: From: Marc Lampo To: "Marco Davids (SIDN)" Content-Type: text/plain; charset=ISO-8859-1 Cc: dane@ietf.org Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? 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, 30 Jan 2013 08:57:00 -0000 On second reading (of 8.1.4) it does indeed come down to my concern. Thanks for pointing in that direction ! Marc On Wed, Jan 30, 2013 at 9:41 AM, Marco Davids (SIDN) wrote: > On 01/30/13 09:11, Marc Lampo wrote: > >> But since domain registration can be quite anonymous >> doesn't this mean that anybody could, if support for TSLA is widespread, >> create https websites that do not cause warning messages to users. > > It does. > > In fact, this is identified as a security consideration (8.1.4) in the RFC. > > -- > Marco > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From fanf2@hermes.cam.ac.uk Wed Jan 30 03:49: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 58FBD21F87B9 for ; Wed, 30 Jan 2013 03:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.284 X-Spam-Level: X-Spam-Status: No, score=-5.284 tagged_above=-999 required=5 tests=[AWL=1.315, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 hsazitj02cKz for ; Wed, 30 Jan 2013 03:49:39 -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 809E321F87A3 for ; Wed, 30 Jan 2013 03:49:39 -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 hermes-1.csi.cam.ac.uk ([131.111.8.51]:39885) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1U0WAc-0002CX-WY (Exim 4.72) (return-path ); Wed, 30 Jan 2013 11:49:38 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1U0WAc-00067Z-0I (Exim 4.72) (return-path ); Wed, 30 Jan 2013 11:49:38 +0000 Date: Wed, 30 Jan 2013 11:49:38 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Marc Lampo In-Reply-To: Message-ID: References: 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: dane@ietf.org Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? 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, 30 Jan 2013 11:49:40 -0000 Marc Lampo wrote: > But since domain registration can be quite anonymous > doesn't this mean that anybody could, if support for TSLA is widespread, > create https websites that do not cause warning messages to users. Yes, that is the desirable outcome. > To me it seems that anybody could, kind of, produce his own identity card ? No, the identity is provided by the parent domain. > It that is the case, it would only increase the need for HTTPS inspection > - "man-in-the-middle" - Why? > in which case the certificate offered to the user will change > and no longer be "in line" with the TLSA record. Indeed. DANE will detect the man-in-the-middle attack. 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 n.mavrogiannopoulos@gmail.com Wed Jan 30 04:04: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 407E921F889C for ; Wed, 30 Jan 2013 04:04:07 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k04pugrwkYLX for ; Wed, 30 Jan 2013 04:04:06 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 73C7C21F8840 for ; Wed, 30 Jan 2013 04:03:59 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id c13so1168101ieb.37 for ; Wed, 30 Jan 2013 04:03:58 -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=TS+p6k4LCpvnPDr3O3K4NtV9xnmTBd2Z3gozKqU3CyI=; b=fFyIpO3RlnQdRdHv42/hXtSp6Od4vd0IDwI9jUS2y90CcSHoDd7U+soo9zhshB0cCk xa4ffNo5RX4QO5IXSJw+uG0lVTlSg18ZUKEZvwOsIEwWThyxUt1vKY4PO1yz4ORSMH67 J3eh23NxXqChA7abXGwEnGm7H/Vbd3iYhhpl7i40CEd16shMA+FHX8EAuKEchwXdbAjN uJo6cDG1YIVKShFMSScQeNjlKfPiqxWqJFnTm9tcZZ+StSi40B9VRXJK3e8ADukRPoxj a3TC2V4+a81dFsFm9LtUG76nLcVpuriNmFaD0c7AjA3vIPIWmhK6EBtEpo2g8LQazvks 8t0g== MIME-Version: 1.0 X-Received: by 10.50.189.193 with SMTP id gk1mr3544260igc.87.1359547438795; Wed, 30 Jan 2013 04:03:58 -0800 (PST) Received: by 10.64.89.71 with HTTP; Wed, 30 Jan 2013 04:03:58 -0800 (PST) In-Reply-To: References: Date: Wed, 30 Jan 2013 13:03:58 +0100 Message-ID: From: Nikos Mavrogiannopoulos To: Marc Lampo Content-Type: text/plain; charset=UTF-8 Cc: dane@ietf.org Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? 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, 30 Jan 2013 12:04:07 -0000 On Wed, Jan 30, 2013 at 9:11 AM, Marc Lampo wrote: > Hello, > If a correct TLSA record for a domain would mean > there is no warning to the user about : cannot verify certificate > I'm a bit concerned about the value 3 for "Certificate Usage" ! [...] > But since domain registration can be quite anonymous > doesn't this mean that anybody could, if support for TSLA is widespread, > create https websites that do not cause warning messages to users. > To me it seems that anybody could, kind of, produce his own identity card ? That's how dns is, anybody may register a domain (i.e. create an ID). I'd interpret the value 3 as the ability, for one who registered a DNS domain, to prove that it is the same person with the one who operates the web server. regards, Nikos From marc.lampo.ietf@gmail.com Thu Jan 31 10:02: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 6F79421F861F for ; Thu, 31 Jan 2013 10:02:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubJy3UXT1n0t for ; Thu, 31 Jan 2013 10:02:46 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A4E3521F8619 for ; Thu, 31 Jan 2013 10:02:46 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id l6so1922917vcl.31 for ; Thu, 31 Jan 2013 10:02:46 -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=J42AMDb86SRg45P7rBZEUh2jCnGCpGH3SvTC93N0x6o=; b=bLfTXz4QWgu+hdQcqZEsQGeKDi6JtE5kRhAzayOISQcWWFE5cpOS7wqfA/Rkg/hZRa nbBzpJvwKAG8etuZvVRPDMlCx6I/cHrPBiUT3iyDPuwJLwiu6xyXaPQ+klDjB7UXs7IR f5bsI44+1wltgX0YouKENjOwPXbP2ls44Pkjzz9DVOnS42vndXFnQ1A56L5bkdFHwXVk CAIiHiLIXE1A9zS63kjc46vIVksJ3FmANsSFTQcjcmDalqnuCI0cdDDRx94fJU6UspBE /PxFMYYMdL22ZUeZ6+YsXn+VUYN6ZUAP/qA4b7hlfR6McOm7ue1rSQuhXWBRwpkIWIUy UKPQ== MIME-Version: 1.0 X-Received: by 10.52.89.48 with SMTP id bl16mr7686224vdb.120.1359655365916; Thu, 31 Jan 2013 10:02:45 -0800 (PST) Received: by 10.58.59.38 with HTTP; Thu, 31 Jan 2013 10:02:45 -0800 (PST) In-Reply-To: References: Date: Thu, 31 Jan 2013 19:02:45 +0100 Message-ID: From: Marc Lampo To: Tony Finch Content-Type: text/plain; charset=ISO-8859-1 Cc: dane@ietf.org Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? 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, 31 Jan 2013 18:02:47 -0000 Tony, how can the *parent* domain provide the identity ? The TLSA record is content of the domain (not the parent) is it ? I know that, for DNSSEC, the parent signs the domains public key information (DS), but that is purely DNSSEC. It does not contribute to the identity of the domain holder. Or what am I missing ? Marc On Wed, Jan 30, 2013 at 12:49 PM, Tony Finch wrote: > Marc Lampo wrote: > >> But since domain registration can be quite anonymous >> doesn't this mean that anybody could, if support for TSLA is widespread, >> create https websites that do not cause warning messages to users. > > Yes, that is the desirable outcome. > >> To me it seems that anybody could, kind of, produce his own identity card ? > > No, the identity is provided by the parent domain. > >> It that is the case, it would only increase the need for HTTPS inspection >> - "man-in-the-middle" - > > Why? > >> in which case the certificate offered to the user will change >> and no longer be "in line" with the TLSA record. > > Indeed. DANE will detect the man-in-the-middle attack. > > 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 fanf2@hermes.cam.ac.uk Thu Jan 31 10:11: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 A240E21F86AE for ; Thu, 31 Jan 2013 10:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.613 X-Spam-Level: X-Spam-Status: No, score=-5.613 tagged_above=-999 required=5 tests=[AWL=0.986, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 aF1l9O6B7OBE for ; Thu, 31 Jan 2013 10:11:00 -0800 (PST) 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 BD69621F855D for ; Thu, 31 Jan 2013 10:11:00 -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 hermes-1.csi.cam.ac.uk ([131.111.8.51]:33746) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1U0ybD-00025s-Qn (Exim 4.72) (return-path ); Thu, 31 Jan 2013 18:10:59 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1U0ybD-00031o-9L (Exim 4.72) (return-path ); Thu, 31 Jan 2013 18:10:59 +0000 Date: Thu, 31 Jan 2013 18:10:59 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Marc Lampo In-Reply-To: Message-ID: References: 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: dane@ietf.org Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? 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, 31 Jan 2013 18:11:01 -0000 Marc Lampo wrote: > > how can the *parent* domain provide the identity ? It authenticates the owner of the zone, in a similar way that certification authorities authenticate the recipient of an X.509 certificate. They have about the same amount of connection to the owners of individual services addressed from the zone. 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 paul@cypherpunks.ca Thu Jan 31 11:13: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 C83AA21F8455 for ; Thu, 31 Jan 2013 11:13:18 -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 tRIvL5-Imr9y for ; Thu, 31 Jan 2013 11:13:18 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4D88E21F844E for ; Thu, 31 Jan 2013 11:13:17 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id B7E9380597; Thu, 31 Jan 2013 14:13:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7F5878053A; Thu, 31 Jan 2013 14:13:14 -0500 (EST) Date: Thu, 31 Jan 2013 14:13:14 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Marc Lampo In-Reply-To: Message-ID: References: User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dane WG list Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? 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, 31 Jan 2013 19:13:19 -0000 On Thu, 31 Jan 2013, Marc Lampo wrote: > how can the *parent* domain provide the identity ? He who controls the spice, controls the universe! Oh wait, I mean to say the parent can already take control of all of its children, so yes in the DNS world, the "ID card" analogy does not quite work. (In the X509 world, the ID card analogy compares perhaps to US drivers licenses, each state looks different so no one can really verify the authenticity anymore) So, parent DNS controls child DNS. Child DNS controls where it points the webserver at. So no new "vulnerabilities" are introduced by putting trust in selfsigned certs anchored to DNS. > The TLSA record is content of the domain (not the parent) is it ? > I know that, for DNSSEC, the parent signs the domains public key > information (DS), > but that is purely DNSSEC. > It does not contribute to the identity of the domain holder. > Or what am I missing ? DNS does not provide "identity" information. But "Domain Validated" (DV) certificates don't either. Anyone controlling example.com acn get a DV cert issued by the CABforum members without any identity check. If you are talking about EVcerts, apparently CABforum people do more checks before handing this out, allegedly doing identity validation, so I would need to provide some Example Inc. paperwork before they should give me an EV cert. This part cannot be replaced with TLSA records, although TLSA records can contradict (rogue) EV certs. Paul From kent@bbn.com Thu Jan 31 12:46: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 35DDD21F8546 for ; Thu, 31 Jan 2013 12:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Lk36JBIpbiUn for ; Thu, 31 Jan 2013 12:46:54 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A3AD221F8505 for ; Thu, 31 Jan 2013 12:46:54 -0800 (PST) Received: from [128.89.89.145] (port=54307 helo=bud-d360.bbn.com) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U1125-000Hdf-Hl; Thu, 31 Jan 2013 15:46:53 -0500 Message-ID: <510AD83D.6030307@bbn.com> Date: Thu, 31 Jan 2013 15:46:53 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: paul@cypherpunks.ca References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] TLSA - Certificate Usage value 3 - produce one's own identity card ? 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, 31 Jan 2013 20:46:55 -0000 Paul, I think the simple argument here is that, in the DNS, the parent is authoritative for (DNS) names it assigns to nodes below it, period. This differs from the browser PKI model (let's not dump on X.509 for this truly awful PKI design), where any TA can issue a cert for any name. Steve From paul@cypherpunks.ca Thu Jan 31 14:32:17 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 1414821F8473 for ; Thu, 31 Jan 2013 14:32:17 -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 mnen19CMXC4S for ; Thu, 31 Jan 2013 14:32:16 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9A89021F8438 for ; Thu, 31 Jan 2013 14:32:16 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 013B780597; Thu, 31 Jan 2013 17:32:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EA9AD8053A; Thu, 31 Jan 2013 17:32:12 -0500 (EST) Date: Thu, 31 Jan 2013 17:32:12 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Stephen Kent In-Reply-To: <510AD83D.6030307@bbn.com> Message-ID: References: <510AD83D.6030307@bbn.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] TLSA - Certificate Usage value 3 - produce one's own identity card ? 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, 31 Jan 2013 22:32:17 -0000 On Thu, 31 Jan 2013, Stephen Kent wrote: > I think the simple argument here is that, in the DNS, the parent is > authoritative for (DNS) names it assigns to nodes below it, period. > This differs from the browser PKI model (let's not dump on X.509 for this > truly awful PKI design), where any TA can issue a cert for any name. But it is not different at all, _because_ the parent or child DNS admin can point the webserver elsewhere and get a new certificate issued. That cert was never safe from any DNS admin control before TLSA, and not after TLSA. So I disagree with Marco's claim that DNSSEC/TLSA changed something. Paul