From nobody Fri May 1 07:48:45 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2E41B2A89; Fri, 1 May 2015 07:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sffbrkHxkC9m; Fri, 1 May 2015 07:48:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A0F1B2AB3; Fri, 1 May 2015 07:48:23 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150501144823.1163.30596.idtracker@ietfa.amsl.com> Date: Fri, 01 May 2015 07:48:23 -0700 Archived-At: Cc: dane mailing list , dane chair , RFC Editor Subject: [dane] Protocol Action: 'Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records' to Proposed Standard (draft-ietf-dane-srv-14.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 14:48:42 -0000 The IESG has approved the following document: - 'Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records' (draft-ietf-dane-srv-14.txt) as Proposed Standard This document is the product of the DNS-based Authentication of Named Entities Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv/ Technical Summary This document specifies the general case how to find TLSA records, for a protocols that uses SRV records for service discovery. The goal of this document is to cover the general cases not every corner case. It is explicitly called out that protocols that use SRV may specify differently. Working Group Summary There has been good discussion on this document, there is strong consensus about the whole document. Document Quality The document is well written. The protocol specified here is for the general case where SRV records are used. There is interest to deploy this technology in number of existing and proposed protocols. Personnel Document Sheperd: Olafur Gudmundsson Area Director: Stephen Farrell From nobody Sun May 3 22:37:47 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E655D1AC42D for ; Sun, 3 May 2015 22:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOZe4gw9qlVs for ; Sun, 3 May 2015 22:37:44 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6E11AC40F for ; Sun, 3 May 2015 22:37:31 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 993E2283031; Mon, 4 May 2015 05:37:29 +0000 (UTC) Date: Mon, 4 May 2015 05:37:29 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150504053729.GN17743@mournblade.imrryr.org> References: <20150427180122.GH20186@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150427180122.GH20186@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [dane] Feedback please: (WGLC for draft-ietf-dane-ops-07) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 05:37:46 -0000 On Mon, Apr 27, 2015 at 06:01:22PM +0000, Viktor Dukhovni wrote: > This draft is normative for both the SRV and SMTP drafts which have > progressed to the IESG and IETF LC respectively. So it is important > to get this reviewed and moving along the process. > > Please read this draft carefully, and provide feedback as soon as > you can. I'm not available for editing from mid May through early > June, so I'd like to see the WG LC complete before then, and be > back in action to make any changes that come out of IETF LC in June > (IETF LC last week of May, first week of June would work fine). Really, nobody has any comments? Surely the document is not that perfect. :-) If at all possible, please provide feedback soon! -- Viktor. From nobody Mon May 4 10:11:39 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9CB1ABD8F for ; Mon, 4 May 2015 10:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffNyyWFiNNSR for ; Mon, 4 May 2015 10:11:30 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B3C1ABD3C for ; Mon, 4 May 2015 10:11:29 -0700 (PDT) Received: by widdi4 with SMTP id di4so117399732wid.0 for ; Mon, 04 May 2015 10:11:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=6cZE2ZGcdXn/6Oosj24L1PxgQt7RssysRaWsAylMPh8=; b=WV5BvfoS34US4clg4k/dB4LwFz/UPUAUyjpnq6Jyx8NLQpH3Fa2J90WzjzbIGr6vFW R116SVycgQVRTA08/fftM4l1PC+fwwmPq5JW9qstr+d3xIYqdi6AdzWt9ARRgcG4LRLt pwaBdBdUhM+PqAUY/H4TEm1minyU/ITszRHYaV1/EAzRjx9Fb/Nr7I9ut3zEKxbDkz2c CIkavUWyOBeYtAWYhM7wGl3NR8r0SlMKhufsIUJt4odyyT3LSifRO+TutSHfrCRcfxAP 8140ZWWsMEsIUjO3Essv/ah36G6eUFPrjmZMIkH6Sa/oNCJNMPlr5tzAdfpfTjGcN1AG j0tQ== X-Gm-Message-State: ALoCoQk+JC1+qskoTPZCafvIubVhfsTtONYycJE4QTeyRVzVYCzBXYo0XXGpXIlfxyOURKoxHOF7 MIME-Version: 1.0 X-Received: by 10.194.216.196 with SMTP id os4mr9368586wjc.117.1430759488429; Mon, 04 May 2015 10:11:28 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Mon, 4 May 2015 10:11:28 -0700 (PDT) In-Reply-To: <20150504053729.GN17743@mournblade.imrryr.org> References: <20150427180122.GH20186@mournblade.imrryr.org> <20150504053729.GN17743@mournblade.imrryr.org> Date: Mon, 4 May 2015 13:11:28 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] Feedback please: (WGLC for draft-ietf-dane-ops-07) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 17:11:36 -0000 On Mon, May 4, 2015 at 1:37 AM, Viktor Dukhovni wrote: > On Mon, Apr 27, 2015 at 06:01:22PM +0000, Viktor Dukhovni wrote: > >> This draft is normative for both the SRV and SMTP drafts which have >> progressed to the IESG and IETF LC respectively. So it is important >> to get this reviewed and moving along the process. >> >> Please read this draft carefully, and provide feedback as soon as >> you can. I'm not available for editing from mid May through early >> June, so I'd like to see the WG LC complete before then, and be >> back in action to make any changes that come out of IETF LC in June >> (IETF LC last week of May, first week of June would work fine). > > Really, nobody has any comments? Surely the document is not that > perfect. :-) If at all possible, please provide feedback soon! Yes please! We need some more feedback from the WG to be able to call consensus. This document has had some discussion earlier in it's life, but we'd like the WG to express continued support for it... W > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- 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. ---maf From nobody Mon May 4 18:01:12 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7901B2D39 for ; Mon, 4 May 2015 18:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnN2fDXePbak for ; Mon, 4 May 2015 18:01:09 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 330901B2D19 for ; Mon, 4 May 2015 18:01:09 -0700 (PDT) Received: from [10.20.30.101] (50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t45117hc018094 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2015 18:01:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Paul Hoffman In-Reply-To: Date: Mon, 4 May 2015 18:01:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <65F9DF37-8958-4D7C-84B7-9C7287DC4058@vpnc.org> References: To: dane@ietf.org X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [dane] WGLC for draft-ietf-dane-ops-07 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 01:01:10 -0000 On Apr 27, 2015, at 9:14 AM, Warren Kumari wrote: >=20 > Dear DANE WG, >=20 > The authors of draft-ietf-dane-ops have indicated that they believe > that the document is ready, and have asked for Working Group Last Call > (actually, they requested this a while back, we'd delayed while doing > toe other docs...) >=20 > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ >=20 > Please review this draft to see if you think it is ready for > publication and send comments to the list, clearly stating your view. >=20 > This WGLC ends Mon 11-May-2015. Sorry for the late review. This document is large, but it is also quite = important for DANE deployment. In fact, it is probably as important for = DANE deployment as the original TLSA document was. I found only two = substantial issues in the document (I am sending editorial nits to the = authors). In Section 12, there is the question of whether or not the section is = really useful. Yes, it is. For a long document such as this, an operator = will want a checklist of changes from RFC 6698. In Section 13, there is no justification for why TLSA records for HTTP = servers should have a TTL an order of magnitude shorter than those for = SMTP servers, and I can't think of one. Proposal: suggest all TLSA = records have a TTL of an hour. --Paul Hoffman= From nobody Mon May 4 22:38:36 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABE61A9149 for ; Mon, 4 May 2015 22:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtyuPA30VnQX for ; Mon, 4 May 2015 22:38:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FAB71A914C for ; Mon, 4 May 2015 22:38:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1549D283032; Tue, 5 May 2015 05:38:32 +0000 (UTC) Date: Tue, 5 May 2015 05:38:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150505053831.GJ17272@mournblade.imrryr.org> References: <65F9DF37-8958-4D7C-84B7-9C7287DC4058@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65F9DF37-8958-4D7C-84B7-9C7287DC4058@vpnc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] WGLC for draft-ietf-dane-ops-07 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 05:38:35 -0000 On Mon, May 04, 2015 at 06:01:07PM -0700, Paul Hoffman wrote: > In Section 13, there is no justification for why TLSA records for HTTP > servers should have a TTL an order of magnitude shorter than those for > SMTP servers, and I can't think of one. Proposal: suggest all TLSA records > have a TTL of an hour. Without necessarily disagreeing, the rationale was: * MTA to MTA SMTP is non-interactive store and forward, and moderately high latency (mail queueing until the problem is fixed) is tolerable, if sufficiently rare. * HTTP servers provide generally interactive services, where users might be less forgiving of a 1 hour outage. Perhaps the right answer is to not suggest any particular TTL, but just note the issue, leaving the choice of TTL to the reader... -- Viktor. From nobody Tue May 5 07:30:57 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39A51AD213 for ; Tue, 5 May 2015 07:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYYMtiedt7hE for ; Tue, 5 May 2015 07:30:53 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B64F1AD210 for ; Tue, 5 May 2015 07:30:53 -0700 (PDT) Received: from [10.20.30.101] (50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t45EUpE7029482 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 May 2015 07:30:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Paul Hoffman In-Reply-To: <20150505053831.GJ17272@mournblade.imrryr.org> Date: Tue, 5 May 2015 07:30:53 -0700 Content-Transfer-Encoding: 7bit Message-Id: <34F55819-7A7F-433A-A56D-00C962D2CF45@vpnc.org> References: <65F9DF37-8958-4D7C-84B7-9C7287DC4058@vpnc.org> <20150505053831.GJ17272@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [dane] WGLC for draft-ietf-dane-ops-07 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 14:30:54 -0000 On May 4, 2015, at 10:38 PM, Viktor Dukhovni wrote: > > On Mon, May 04, 2015 at 06:01:07PM -0700, Paul Hoffman wrote: > >> In Section 13, there is no justification for why TLSA records for HTTP >> servers should have a TTL an order of magnitude shorter than those for >> SMTP servers, and I can't think of one. Proposal: suggest all TLSA records >> have a TTL of an hour. > > Without necessarily disagreeing, the rationale was: > > * MTA to MTA SMTP is non-interactive store and forward, and > moderately high latency (mail queueing until the problem is > fixed) is tolerable, if sufficiently rare. > > * HTTP servers provide generally interactive services, where > users might be less forgiving of a 1 hour outage. > > Perhaps the right answer is to not suggest any particular TTL, but > just note the issue, leaving the choice of TTL to the reader... That works for me as well, and is not onerous on the reader. --Paul Hoffman From nobody Wed May 6 08:23:41 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99101AD0A6; Wed, 6 May 2015 08:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2b_xvz8Xr75; Wed, 6 May 2015 08:23:37 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C380B1A00C7; Wed, 6 May 2015 08:23:07 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 92417283033; Wed, 6 May 2015 15:23:06 +0000 (UTC) Date: Wed, 6 May 2015 15:23:06 +0000 From: Viktor Dukhovni To: ietf@ietf.org, dane@ietf.org Message-ID: <20150506152306.GW17272@mournblade.imrryr.org> References: <9904FB1B0159DA42B0B887B7FA8119CA5CA24107@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA24107@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "Romascanu, Dan \(Dan\)" Subject: Re: [dane] Gen-ART review of draft-ietf-dane-smtp-with-dane-16 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 15:23:39 -0000 On Wed, May 06, 2015 at 02:58:42PM +0000, Romascanu, Dan (Dan) wrote: > Ready with minor comments. > > I liked the operational considerations section and the security > consideration section - very useful in putting this work in the context > of other similar contributions. Thanks. > Minor issues: > > As the document uses heavily the term 'downgrade' (downgrade attack, > downgrade-resistant) it would be nice to either explain or provide a > reference for what it means in the context of this work. In RFC 4949, at the bottom of page 112 we find: downgrade attack (I) A type of man-in-the-middle attack in which the attacker can cause two parties, at the time they negotiate a security association, to agree on a lower level of protection than the highest level that could have been supported by both of them. We could add "downgrade attack" to the terminology, and briefly define "downgrade resistance" under the same heading. Alternatively, since the primary downgrade at issue is stripping of STARTTLS, some additional text could be added in 1.3.1 to introduce the terms. Any advice on how to proceed? > Nits/editorial comments: > > The last paragraph in section 2.2.1, page 15 has a comment marked twice > by --. This may be an editorial left-over to be corrected. That's what the RFC editor's xml2rfc does with "—". When I run xml2rfc, it produces "richer" HTML output, in which the mdashes remain as such. Should I avoid "—"? -- Viktor. From nobody Wed May 6 12:57:36 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E731A036A for ; Wed, 6 May 2015 12:57:35 -0700 (PDT) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obaUsbO-PmyT for ; Wed, 6 May 2015 12:57:33 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE8D1B2EA7 for ; Wed, 6 May 2015 12:57:33 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so4588916igb.1 for ; Wed, 06 May 2015 12:57:32 -0700 (PDT) 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=7OniQo2lgh1bZe5+G8EhPBaSCtb6r0QeiqEDru06jto=; b=i3JMEMbH6vibmEAxg6El6F7xyy9qx43+6oZEo2BPg9lI7ntxccks8OOvdinJDte1wq e61Ri9hmaM9KXRaAVdmZF6rEVcmXwwSOAV2kZgMW5g6XsDoJGw6c7emAKl9LPp6uOT7O AgG21KOzQG77KMhT9GvFA/AAcX0gWZR54jhodESnhK1NYN+D63ih4Z8DJVRA9mDAQqfT y26DmcxSbIy5RPdInX30JvtJwc4sN0pKZsKtli+cndhAtfpLm7SVGfGI1W9dHY8GNH+m j1tnV+iUQ4XLXBVMrtiTEbC8I7BEFzSXlUaXLhl0qdqcX5Ct+bvt4AffKGV2wvYQ06O7 qRfw== MIME-Version: 1.0 X-Received: by 10.43.173.70 with SMTP id ob6mr134892icc.45.1430942252805; Wed, 06 May 2015 12:57:32 -0700 (PDT) Received: by 10.64.111.161 with HTTP; Wed, 6 May 2015 12:57:32 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 May 2015 12:57:32 -0700 Message-ID: From: Brian Dickson To: Warren Kumari Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [dane] WGLC for draft-ietf-dane-ops-07 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 19:57:35 -0000 I have reviewed the document, and believe it is ready for publication. I do not have a strong opinion regarding including/excluding section 9, but if it makes the document cleaner, maybe it could go into its own document? (I will go along with group concensus on this and this is just a very weak suggestion.) Brian Dickson On Mon, Apr 27, 2015 at 9:14 AM, Warren Kumari wrote: > Dear DANE WG, > > The authors of draft-ietf-dane-ops have indicated that they believe > that the document is ready, and have asked for Working Group Last Call > (actually, they requested this a while back, we'd delayed while doing > toe other docs...) > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ > > Please review this draft to see if you think it is ready for > publication and send comments to the list, clearly stating your view. > > This WGLC ends Mon 11-May-2015. > > > In addition, to satisfy RFC 6702 ("Promoting Compliance with > Intellectual Property Rights (IPR)"): > Are you personally aware of any IPR that applies to > draft-ietf-dane-ops? If so, has this IPR been disclosed in compliance > with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more > details.) > > Thanks, > Warren Kumari > (as DANE WG co-chair) > > -- > 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. > ---maf > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Wed May 6 17:46:18 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F23D1B2FEA for ; Wed, 6 May 2015 17:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFDECyPJeK7J for ; Wed, 6 May 2015 17:46:14 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C901B2F8A for ; Wed, 6 May 2015 17:46:14 -0700 (PDT) Received: by lagv1 with SMTP id v1so19444680lag.3 for ; Wed, 06 May 2015 17:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=eBDfIR02pg9tBT7yOtiMIHA/Y/iJ6obyKoxAk12psdU=; b=a8viqwkceDW7Vkwq7xTkrkFNM3ggeeobaAtwaQqYbvEH3bnxrPKhmFXvduxeyVnEQU cGM0UuLsPdXSbADNvC+UtBnMd9VT8TRIt65sqYL/RNgugpKUh1QeCnGiYzXwQQbMLMzZ ew35TmLCE73kU0pMu8sd/YkOzKL6/isXoW9yDpuQXSTEmHKlXDmhivUgSqWBtBpEZP9b Z1R9kpyky133+KBH/1geZ4FbltLgbD+HkXB2qKqmHhd96VKZ+whUzbqDKsgqgkBMqRiu RDXpa66flXtqzfng/PDX9e3XZ60vvDHIXsr0Yy7OYN7VTuucLeMSbs2AwnBC8AvM9LrD 5J3g== X-Received: by 10.153.11.163 with SMTP id ej3mr954939lad.105.1430959572518; Wed, 06 May 2015 17:46:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.235.228 with HTTP; Wed, 6 May 2015 17:45:51 -0700 (PDT) From: Jigar Joshi Date: Wed, 6 May 2015 17:45:51 -0700 Message-ID: To: dane@ietf.org Content-Type: multipart/related; boundary=001a1134635a02620d0515733d6e Archived-At: Subject: [dane] trying to understand dane better X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 00:46:17 -0000 --001a1134635a02620d0515733d6e Content-Type: multipart/alternative; boundary=001a1134635a0262080515733d6d --001a1134635a0262080515733d6d Content-Type: text/plain; charset=UTF-8 I was using this https://www.dnssec-validator.cz/ I got this icon [image: Inline image 2] for a local network url which is over http (no https support for that url) however hovering over still says secured by dnssec my understanding is it compares the fingerprint of certificate with one dnssec says to check identify of host https://www.dnssec-validator.cz/pages/documentation.html doesn't list this icon (in orange color specifically and hovering over says secured by dnssec) if it is not using https how can it compare fingerprint ? -- -- Jigar --001a1134635a0262080515733d6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a1134635a0262080515733d6d-- --001a1134635a02620d0515733d6e Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_14d2bd58a2dbe278 iVBORw0KGgoAAAANSUhEUgAAAIUAAAA9CAIAAAAMIT1zAAAKyWlDQ1BJQ0MgUHJvZmlsZQAASA2t lndU08kWx+f3S2+0hAhICb0J0gkgvYYiSAdRCUkgocQYCM2GyOIKrCgqImADF0UUXJUia0EsWFgE FLAvyKKgrosFUVF5P2CJe955+9+bnJn55Dt37tzfnDvnXADInWyRKBmWAyBFmCYO9nZjREZFM3C/ AwhgAAGoASs2J1XkGhTkD/61fehHrJF2x2TG17+a/e8FeS4vlQMAFIQsx3FTOSkIn0H6KY5InAYA io/o2hlpohkuQpgmRgJE+OAMJ8wxYg9ocXN8fdYmNNgdsXkEAJ7MZosTACCNIjojnZOA+CHjETYT cgVChJkIO3H4bC7CmQgvSklZPcOHETaI+4efhH8wmx0n9clmJ0h57luQncjBHoJUUTI7a/bP/3NI SZYg9zXbNJGRzBf7BCMzHbmzyqTVflIWxi0NnNcFyBfNM1/iEzbPnFR35C7n9nLZHn7zLEkKc51n thihv20EaazQeRavDpb6FyYvncmP2Rj4PJaUeameIfN6vMCLNc/Z/NCIeU4XhC+d59SkEGkM2Xx3 qS6WBEtjjhd7Sb8xJRXZ+fe5HPb3s9L4oT7zOpfn4TnPPGGYNB5RmpvUjyh5Nr9n4+cle0v11PQQ 6d40cahUT2T7zuTrrL0oLUh6J8ADeAJ/5McAYcACWAFzZAwAII2XieQdAO6rRVliQQI/jeGKvBQe gyXkmC5iWJiZWwMw8+5mbAB4d2/2PUF0/HdNhJxl54HkdPV3LU4FgGYkF5QJ3zWdIwDIRgLQlMOR iNPn/KFnJgwgAllAA8pAHWgDA2CCRGYDHIALErEvCAShIAqsBBzABylADDLAOrAJ5INCsB3sBuXg AKgGR8EJcAo0g3PgErgGboFu0AcegkEwAl6CcfABTEEQhIMoEBVShjQgXcgYsoCYkBPkCflDwVAU FAslQEJIAq2DNkOFUAlUDh2CaqFfoLPQJegG1APdh4agMegt9BlGwWSYBqvBevBimAm7wn5wKLwC ToDXwNlwHrwNLoOr4ONwE3wJvgX3wYPwS3gCBVAkFB2liTJBMVHuqEBUNCoeJUZtQBWgSlFVqHpU K6oDdQc1iHqF+oTGoqloBtoE7YD2QYehOeg16A3oInQ5+ii6CX0FfQc9hB5Hf8NQMKoYY4w9hoWJ xCRgMjD5mFJMDaYRcxXThxnBfMBisXSsPtYW64ONwiZi12KLsPuwDdg2bA92GDuBw+GUccY4R1wg jo1Lw+Xj9uKO4y7ienEjuI94El4Db4H3wkfjhfhcfCn+GP4Cvhf/HD9FkCPoEuwJgQQuIYtQTDhM aCXcJowQpojyRH2iIzGUmEjcRCwj1hOvEh8R35FIJC2SHWkZSUDKIZWRTpKuk4ZIn8gKZCOyOzmG LCFvIx8ht5Hvk99RKBQ9igslmpJG2UappVymPKF8lKHKmMqwZLgyG2UqZJpkemVeyxJkdWVdZVfK ZsuWyp6WvS37So4gpyfnLseW2yBXIXdWbkBuQp4qby4fKJ8iXyR/TP6G/KgCTkFPwVOBq5CnUK1w WWGYiqJqU92pHOpm6mHqVeoIDUvTp7FoibRC2glaF21cUUHRSjFcMVOxQvG84iAdRdejs+jJ9GL6 KXo//fMCtQWuC3gLti6oX9C7YFJpoZKLEk+pQKlBqU/pszJD2VM5SXmHcrPyYxW0ipHKMpUMlf0q V1VeLaQtdFjIWViw8NTCB6qwqpFqsOpa1WrVTtUJNXU1bzWR2l61y2qv1OnqLuqJ6rvUL6iPaVA1 nDQEGrs0Lmq8YCgyXBnJjDLGFca4pqqmj6ZE85Bml+aUlr5WmFauVoPWY22iNlM7XnuXdrv2uI6G ToDOOp06nQe6BF2mLl93j26H7qSevl6E3ha9Zr1RfSV9ln62fp3+IwOKgbPBGoMqg7uGWEOmYZLh PsNuI9jI2ohvVGF02xg2tjEWGO8z7lmEWWS3SLioatGACdnE1STdpM5kyJRu6m+aa9ps+nqxzuLo xTsWdyz+ZmZtlmx22OyhuYK5r3mueav5WwsjC45FhcVdS4qll+VGyxbLN1bGVjyr/Vb3rKnWAdZb rNutv9rY2oht6m3GbHVsY20rbQeYNGYQs4h53Q5j52a30e6c3Sd7G/s0+1P2fzmYOCQ5HHMYXaK/ hLfk8JJhRy1HtuMhx0EnhlOs00GnQWdNZ7ZzlfNTF20XrkuNy3NXQ9dE1+Our93M3MRujW6T7vbu 693bPFAe3h4FHl2eCp5hnuWeT7y0vBK86rzGva2913q3+WB8/Hx2+Ayw1FgcVi1r3NfWd73vFT+y X4hfud9TfyN/sX9rABzgG7Az4NFS3aXCpc2BIJAVuDPwcZB+0JqgX5dhlwUtq1j2LNg8eF1wRwg1 ZFXIsZAPoW6hxaEPwwzCJGHt4bLhMeG14ZMRHhElEYORiyPXR96KUokSRLVE46LDo2uiJ5Z7Lt+9 fCTGOiY/pn+F/orMFTdWqqxMXnl+lewq9qrTsZjYiNhjsV/Ygewq9kQcK64ybpzjztnDecl14e7i jvEceSW85/GO8SXxowmOCTsTxvjO/FL+K4G7oFzwJtEn8UDiZFJg0pGk6eSI5IYUfEpsylmhgjBJ eGW1+urM1T0iY1G+aHCN/Zrda8bFfuKaVCh1RWpLGg0pcDolBpIfJEPpTukV6R8zwjNOZ8pnCjM7 s4yytmY9z/bK/nktei1nbfs6zXWb1g2td11/aAO0IW5D+0btjXkbR3K8c45uIm5K2vRbrlluSe77 zRGbW/PU8nLyhn/w/qEuXyZfnD+wxWHLgR/RPwp+7NpquXXv1m8F3IKbhWaFpYVfijhFN38y/6ns p+lt8du6im2K92/Hbhdu79/hvONoiXxJdsnwzoCdTbsYuwp2vd+9aveNUqvSA3uIeyR7Bsv8y1r2 6uzdvvdLOb+8r8KtoqFStXJr5eQ+7r7e/S776w+oHSg88Pmg4OC9Q96Hmqr0qkqrsdXp1c8Ohx/u +Jn5c22NSk1hzdcjwiODR4OPXqm1ra09pnqsuA6uk9SNHY853n3C40RLvUn9oQZ6Q+FJcFJy8sUv sb/0n/I71X6aebr+jO6ZykZqY0ET1JTVNN7Mbx5siWrpOet7tr3VobXxV9Nfj5zTPFdxXvF88QXi hbwL0xezL060idpeXUq4NNy+qv3h5cjLd68su9J11e/q9Wte1y53uHZcvO54/dwN+xtnbzJvNt+y udXUad3Z+Jv1b41dNl1Nt21vt3Tbdbf2LOm50Ovce+mOx51rd1l3b/Ut7evpD+u/NxAzMHiPe2/0 fvL9Nw/SH0w9zHmEeVTwWO5x6RPVJ1W/G/7eMGgzeH7IY6jzacjTh8Oc4Zd/pP7xZSTvGeVZ6XON 57WjFqPnxrzGul8sfzHyUvRy6lX+n/J/Vr42eH3mL5e/Oscjx0feiN9Mvy16p/zuyHur9+0TQRNP PqR8mJos+Kj88egn5qeOzxGfn09lfMF9Kftq+LX1m9+3R9Mp09Mitpg9WwugkBGOjwfgLVInUKIA oHYDQJSZq4tnLaC5Wh5h6O8+I/8Xz9XOMwtIDQGq2wAIzQHAH5n3IrMe0mVdAAhCeqgLgC0tpR3M tdR4S4tZgkjNSGlSOj39DqkHcYYAfB2Ynp5qnp7+WoPUOg8AaPswV4/PWMsdB+BgtlmQnf+tgv45 R/8Y/wOOHgAVn32irQAAAn9pVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADx4OnhtcG1ldGEgeG1s bnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IlhNUCBDb3JlIDUuNC4wIj4KICAgPHJkZjpS REYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMj Ij4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6 ZXhpZj0iaHR0cDovL25zLmFkb2JlLmNvbS9leGlmLzEuMC8iCiAgICAgICAgICAgIHhtbG5zOnRp ZmY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vdGlmZi8xLjAvIj4KICAgICAgICAgPGV4aWY6UGl4ZWxZ RGltZW5zaW9uPjYxPC9leGlmOlBpeGVsWURpbWVuc2lvbj4KICAgICAgICAgPGV4aWY6UGl4ZWxY RGltZW5zaW9uPjEzMzwvZXhpZjpQaXhlbFhEaW1lbnNpb24+CiAgICAgICAgIDx0aWZmOkNvbXBy ZXNzaW9uPjE8L3RpZmY6Q29tcHJlc3Npb24+CiAgICAgICAgIDx0aWZmOk9yaWVudGF0aW9uPjE8 L3RpZmY6T3JpZW50YXRpb24+CiAgICAgICAgIDx0aWZmOlBob3RvbWV0cmljSW50ZXJwcmV0YXRp b24+MjwvdGlmZjpQaG90b21ldHJpY0ludGVycHJldGF0aW9uPgogICAgICA8L3JkZjpEZXNjcmlw dGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KKKF5aQAAJgdJREFUeAHtnHmYlNWVxr9a u6o3ugWkm0WhARdABGRRFlsRAyqgDGKiIupoRB01ipGYqBijRiRqnpiJycQoMcbdjHGJCgoKKCKE HcRGFkFoxG6g6bWqa5vf/d7qy0c3mkyeeeaPmdzHXM495z3vOXf97lddFd/dd98dCAQcx0m7xefz Iav4/f5UKkWNJRgMIlurXGhmMhlkAHKhCd66o5cXGEwUXJLJJE0xCwlMplAohFUMABQFkxdmqSQA pjQ3N1MrH1HRxAsMhOgpREGpVGkiy6QM0YCXHoyNAgwAnIwAegAI1CjVFKdqhUYvQcxQwSwNMlaK eoQXBVMikYAWwc8QoFIekmkqM9zQyxlq5WF8WnqOSWGAKQBNkCpYKYBVQw6MIQBJrfDIpEihKQAy ycGg0JYBAQ0FEzKOxKJGo2GlScEdDXqKYLZ3hEAJxrC4PNReWpcgIw2cQopEtMJLT7YoRS69ZLlj JRYAwAiYKBoWNGCkQZYePFaDRCUtDamyBr/fJkE8ivS2V/KiZm1SA7AZIBNSw6T88KUJwBC5SwwN XhSU1EpLTWT1RHqmBxdgUFGTAE0wsqpvShUlYDSY4FeTuMpc0eUIABLp0QgMCQWYamWO1WrQh8Nh mrjLahxcFymFxKTO0mSgFRElSDnSBWGIy+ghKxOsZo/gpqQlkygFmWJlTYN1w0QYxZASEqUuF5q4 kAFWClE1jugB4CiwrCjRoGc0Tf9cL5pEAUAtL3UMPU2rFJVqwPKlBkORC7VdDV6ZlIgIFXitaMmw 5eTkUMOAhogUb0RkNYmoKNRK1WaCRmmgJxB4BKJDJS8ALrE5ALEi4xv89NNPaSAJh4NkCTaYBJAU mSxSJm8wTAoGGDZkrCRHCDRKQnrVyhs9SDS4mzAtW0d4mqIF4xrNJNET9c0yi4HaC1ZThPBbQmmI LiUCbEoDE82CgoLS0lKoNJ2WE0F5ogeJTAi5wFBTU1NbWxuLxUSrWrFsYnKh6c3cNDdv3sw/rYoX BJGarTDf3FSvwNg8/ibnN0T5OpPlVJI2HONlNfRcTWv1Zg6DtylZOe/bt+/dd989cOBA+/btmRub gyZDixpywBQmhrJ3715OguOPP/64447r3Lkz08m2w3rEKN64FuPbtWuXTcKGlNCKRT7U4JUTAIo0 rQSawDBRJHvDW9nCBLa0amKlWBIE9NLYIbZU3kDCqLYA64veq2wli4dljsD4zp07t2vXrsh2SgiN CzUToA3KoVdfXw94wIABZ511Vn5+PlaiUATGXVHQWNnGRak9hMbcaqzh64RMOlW/4e30tkW+RBPM cJr/eWJkHVFlyMCXCUX9ZeX5/cb5/IeuesbmelGDb2pqos/0xBuU7pGPnpk2dSt4kZLbmkRukQpK 0wqSqS3Sa5IjGg10x44d0TATaEiMbPHShtMtRuPIZHBGTZ06tWfPnsCYAxW8bCBF8WoUy0ZUPuaR KxVt+dD0OtOsWfdm/o53fEEfaWbSGTOcbVaYocs47F4fK8Npznw+v85xigdOtGwIKkwDxytx8/Ly CESXKOoAJI2NjXV1dex0NDQp6oPNrYXm0L8yCUmNQRpqinDSt8UQGoCsltE6Kiv0TA8TQOaaG5oC g2RhsVGuvfbao446isnAhFIwaMWsGhebj40lk/TI5u74dSDLEqt4pzDqpNLZuwR4uVhfBDpGbSaF I5U15ffHK951Bk40KrfDAtCr6urqDh06xONxeiIeOyiag2g0WlVVBYbuyQsGTLYPVsBd/FYjwSrx UggvUrIwFkCzpQvZhIEpH7tkLbllY8ccPHjwwgsvVLbgKV9++WVFRcX+/fvBM0knnHBCSUkJss3K ypZHzNRmni3OCtYsIROvS4Ry/D765qTZA+6awpRdey2CbWLi2pGO1UNoQ5Io2VdWVvJ4ZH+gl0lr imXV0NDAQqOJO1tn9+7dHNxaiUpMeKWkWnqbthVaWeXoBaMBYzVr1649+eSTydA6YtIqoZaAC8kw N5jYKAJwTPXr169Hjx6csWYq/P4NGzZs3LgRa25uLrCv3NKnT5+TTjrJRlSUtk002X1nERKgs51H MOcQmyPgpFNxf9o8PRx/kJ1gLC1FLrQ40AJBc4N0T68sACS5fv755+RNH+TE0HPNp16xYgWPzZtv vpmbyWuvvfaXv/zl9ttvLyoq2rZtGxrAIofB8Lc8h0RiNV7B5m9SdENTA2BTrl69misM27SwsLBT p04MEzf+TZs2MR+WUFRq4qjnNpx0ivnQ9DDWLC9Mo0aNoguapz179nzyySfMxPDhw9kx+HIYLFu2 DCWrkBuXN0RbmRDmvGprgMh2iVHImEFIJuONvtyjnFA0E6t14rUIXsfs1DBX7glhkvYdtvM4glau XMn+5ThiVpiJo48+ms0O/xtvvLFo0aKZM2fSQ2RWK48QRo2ZAw/M5kNEm5iNbrtgBS/e5O92h8H6 4IMPmBKa+EJO9M8++0xNMVtONSGkIzYiSDKEkMJe4VHHcuFRx2SgAaaXByaDi4BoSZ4m92ZMXbp0 ET8mm2qriNn9IXOrzKzPnsoDifZ53c64Mnr8WU4gnKrdE1vzcmzbEn+As0UTYXYLT0ZmIZlK85FF POGrrmno5nk4bdmyhdXErJABnSkuLqYbO3fuJMq6det69erFecUG4uRlzXKs0VtMW7dupUtKWvkw iOvWrc/Lzwu4lzfbn2Qq2dDQOGjgAK6bQqoGgMCzavHixbyjcbawFdgchJs/fz4Tr15bsCW0QQFQ ADDodIG0pWFuSJvNockAzzODzaFbGXgKSjYKSj1OWpHbEFY4dE+Qs2qFpwZHXVWxrfv0nwT6TGiK 1UdDwUBRt9wzbtlX29C0e0MgFOGDAO5caR73fFBEvvFEKpZo3ldVUxfHHUKxsd7pCRqGhtMpEonM mjWL4eCFi1k59dRTef/Cm/N27NixWpXgeYpYErqN3K5du2O7d+f8hEHZoiQEtCWdSlitaioussqq VauYgLKystNPP1394phialvshkH8VmPJSYPEpNfRRBMrhBxBdjIAQEIRUoLSsLUwYqa2m0/6LfN/ fei8wl9u2Lz+NIu69c4tG7Rs9pU5zQf73/BotH1nnu0lZ89I1O/zBXjdIA+eKuThc5IJ8wISDB3c snrl3PvwpSg8z3DOKLLn5GWU2SLoeUiwFRjK/v37M9BLly4FwG3EdMv9wAcvuasW2zHdum7Zui3q 84fD2Zcnngc8sLp27YKXMAjWBZkppx48eLCsPLE4FQFYmCbDNoEJSW0nA7wKM2QOZHdxoNGU4MtD grdCFhZ7Aj0AlCw4Zo5nFU2K9JIVVHLjxmfPvOqnh57nwlm0FUBHSsqSjbWNGxelM4nYvt3RDryv psLRXP4Tl+pEMhEKhrgUp+Kx9sPG+15/Gj085ITAkDEHZMDD48Ybb+RzIbp0zDHHLFmyhHkaOHAg 5xKXE84xOgOYPjNzHPfeEBovOLt0Lt2z58t27QoFo8NdupinpU1bgsVz+iHrKEMYMmTI0KFDwQsg wQZCaWVLSPKCea1oAFgSPiZhPlhVep5jZW54aCHQU+ojFpchsfbN250TZ2f3hxgtr01CmvrKLUXd ep08fXYqVlfU2ywxntosj+Z4DHHNk7O69Ojt69J/yx/vOe786Vs/eKtdxOfvdlLTjk3i0SpgGjR2 1Aw9+Wnd8fDo3r07G4UTlmdM7969kemVNhBetsPa3eoSF+LcvFyeB9wOGhub8vLyEWz+wpg0W1YD U85bNAcU5NLL5F2hNpDcaVLIVoXFgaBtQY0MDE69uio0T+y+ffty333nnXd4ZqBk64tt/fr1PFcU XZrD6/j2lU6f8cdn9weBMbsJmNkmHona/jfs3la1Yl5p+XcAYAXJNeqvj9+Z3vVpJhBq2rFhx+p5 ST4jidV99sQd2A76fcmVC6Nhd/cAd29wPEJZ9TBAy9GvgWYOuNSOHj2abUE3uAKNGzdOpzMdJha9 pbbpqQ9qlpaUcGrxxymeW8cea1af9Ca9w89eIh577LGMCFfPc845RzBheCbzSJAvGgTbazWZBlaG wBoTNMIz4iTMQUSqmleYuSxwavFw0gMcKyuP0CydhQsX0lPGARiFQHiJmeEPFzifrNt+6LwiBkVm r4DMubTzlV/wQtFh2IRgTrSuek/Fq79pXPpyTiBID/JyGXdfOJPK5OUz8ubhDntuXrzJ/TuS+55C +G7dum3fvp3UmRW2MEfTxIkTmQyWGK9LZPbFF18wEzxITMRwmFEgY7xo2uyVGDXFcHbtsunTij4n niCNrTFJlkA9aNAgxoj9x8sNdweu0VwcPv74Y94PysvLec57XayXSDQmJEMhf6YQADKLHU774oIS JC68xlJsMgjsDCbDTol2iSajBZY/aOxk34zfmfNKRIoqRjTgVKMJR3L86eSul2bvXvh0OpTXXLM3 2LC/oKiIGQLovq6b9w7SwYtLkI//zAdw2c+oFZiDiMsr653+PP/88yAnT57MnkA48cQT6d7y5cux suU5rDhemA+eCpzIdhGBMbl6zmvOqJNO6sdnRpB487dNgWFgVZ533nmvvvoqU0KxYCaezQoAcmrr aMeBCaBgZRuhVA7UKOGkRySpK6842zKgZ/ezM7xTgga9IuJC6T35Bz/5cGi2J7TdnmZ7q6YNwK4K 5oT8Pt489jL+EY7OwnY80rOfRPLi7il4sXt5uvDRo+VBYI0wJTzfGPRLLrmEztANHrCTJk1iDvDi WnXxxRdzCJAlA00qPPN1lxc9GgSQakpmMpSnrKoxWbDVsNWmTZvGO+mOHTu4Z0NOYTuSD3g7NJYH QYWhx8oc6BFiOuiepTTJ9v333x8/fjwAwEpMQqsme4IpWbBgAbuEKyXzYQHycoJdrnp0t8/ewTF7 u6qmfJbMOLUownxwszX95BMRhiXL0vLPYe7cgH3OwXhy5MMfYYdW/WFnkBBrn+GmJ2TGlNA3PfTQ Q8JyQ48Xxxp/SwDQEiH7r1JqpVRTE9O2bgsWRnplbmmticOTTO6///7u3bsz9NKTD72gO7qMMJe8 ePNJOy+GdEQkIrTkNjoMfCjAZHAe2HDWKs2h9w8MXiKc0SiJYF67SLCZz9LRmFkxtsPmQ458qoXA A5aapRIImOe5K2Z5GHFexzi1ucUy3PSKDkOm5YZSYPpMb0Hay1Wr3CwtgjJE0EliTaKipghjkWAE s3orePXW1yrtNIBHpiZPtt2LL744ffp0runeKcELAEUJiIRdws5AtgUAssVkP9G0ZiVBMATVmDqO uIivkASCfj4opHe+ALdAvgJi/nM/8TRAs6eDZrJC4RBI3l+PHvltSLzMDBn3VD6A43GKXhuFvcK4 I3OOU8iPjEeOHMlRZnrj9kc8yk21TLJCZWFejGSsCLZGkGx9vTCLFD9IdoZOKjTIagKjzxTWEPlz qD777LMcg0wPMDdCtrKEVvBakdFbE0Lr+5XQNlc1y86+fLvPObDi1VTTQT4k5KlGTI00FMrgkIa5 yCkoHnZ+jzHT5K54ik3N8ufU5q2VvxNQc1hpadMxboo8YzRbdr1/XQ+VpKxKw8qK+3W1HLFawWYo F/QUEuD2hUZzIBNKbV9d/6jJn2ch6+mll17ikzdWEmsOQu0VeNqSQ9VKKXKj5wFrG0cU8IRUJq/s 1Vj914UBLBLVgslLsrVaBgQ7JTZWWx4c5UJtZeG99RFNR1QqBCYm4+233+ayx07VicrEMAHyomY3 8ywRHgzbhcHkHC4rK+NxwpsHnwDZE8ybTCsZKpHQBd+MGTMUgM5TIEVJYIioWQso0aiW0tIJJjyO 6C1MnNYR/aGQ7sCBlxIMMjsdAQwh0NNt7X2RoxQhtQRcNBaYbD5yV1DlIxi1hhLBBkWAChdiiYEm QSGkBgkPxz0LnyEWM7U1MTIAaMKDgBc8PN7JijcqPnbjKINQbOL3RkeDozS4kx4yJci7mBihBoRN OASlCyOC1WOliSdgWKxeTWrwKElOJvAqaMSDniJyK0AoNtdorBQ0sFEjI8ADPwUwsmpM8lVcWVFa AUJkkSOo4IJehICFwYRehGgYWS57HEfI6GVFoKChMGIKikYTw18TmCeujkyMRgAYjnBSAFOjUY1e IyMBPTxBXlOtljZ5Y9bY0RSU2vC5jNZZvDQR1FsACCwoCJWNNGAosKHXsKJHRgmMGpm9T81KhA2N AEpR/IyOOk/PbWJoAKNRwjQR4MEdLx30ACgoyQ1HTNTAqNVZrAokGIG4X4BHKUL4MeFIjUk81ABQ UiwtANzRyEpTiSEoAZr0UR2hBqxsAdA0eEVFS0Npwa5I1BJkoqYQjFpcAhAbdwXWsCo/+YLHRGBg DBACegSaFJriJEtIMCEoBBhpaErAytCgR8BXERHUPZRQgdRA08RRLtQU9BQpicK6kd4ON1bYhKFG LxlOYslkawUiIiRSoiET+G3BnQ5SY6JAIrzypBY/DLhAAiD7/qF4+IBQABA4UBDQIBBMKcpfGpuK GFEqKnr1Ew05wSxBgaAiEBq8lBN4RRRAJgJBogQ06CxPTAIrDdVgAGCiKQC0+CqQZPRmVFr6SBMv qHABJlmxwGClaHGQEnqadET7g6YtkIOHwXYTE02iU/BFT60cqAlHUAFAQotVEU1u/A839dCiESgo qXHAGR/lTY0LRYyCwQsYJMXKYABTwLCoKbhISURgmOgeWwoZPTCiiASTlHKhxgqGKBSa0igraqxo 8EWgxp0QCKpxUXSs0KIXlZDWRanSBI+JgowjgsIBwNHEdgvJKzSC8rcdkS/uJAAWK75SIlAIIQEG vMBQgzfTRYNaMgJu+FsQVpyZZNFRo5ESDE0V0cFOBrjjAgZOZAoYZDAU9DSBgWEBUgRwgQYJiXJl LNQfavl6Y4kEvZKHBw2c1HJXJjTlq2QYOwQ7lDIRGiWFJnjiihY2EYpEtcIBpqkaMDC5UFNESE1n wVslGrJCIz01sRSOGkLzhSJ6AgJGoARgOGx4aRRYmQFAiZdCohS1YtOEikIGeGkWBUaDLyYlRFOB +MgEvayQyFFNarIEj6BMQIIhCgWlAhEFQTlLqShatsgkgLvCeUOgUUrUuKsAQBCzarmIwasnB5r4 kgAhaMpR+ShhfOWixFAqCkpcbL9ogoQqyDUZiYIKKClaH5ogKDKBQQOFGNFLsGkJAIPyU0KaDMDA kKESGzVUKK2XNNRoxEkNhqKhhFAYsSErBwBkYsmBwYASd/TIglHjgtWmhAwAJHpFpAlMhDYWeEZJ XmQCIY5iE0a0+CIoeZaRkGhgRkZQGgCgUlBq4RHAQGsOL1RAlRBNCtSiU7rUEiCVlS2FC440UWJV fghMhgilhBYTkUBaFwSaGg45Wio1seJo8nMvNjTFhkDBRI0GgdrVmTQEllJ69Rxy9RYlMIp8cZQs NlkBo6SmSTKwKSXV4hEADTBCIAAWCSblQ/I6iGgiAxM/AIZIbJjkSxQFMhtW/uAoeFKrG/irWCVN 3JQxAo7kJyUu6CkiREAjDBpggFFSS4+SQGgUFACCMCitIxqboQS5UxMXpDKkSaEJBg1eYtPRgVJn MgACUWMFJjCxaCpDNBRplAy06j5NDkBMFJsVYEJwJQGmUUawDCDxpUlEXIhIIBVkl8lMNoJe2lCa azUUMgOV2dsxGxuBggk8XiD1ZTIbT75gEBQbGaSeAXSYjE1I99TWSNGEkJoCmLQQGDu8lAxNABSN l1UCJg31FgE9GJFIpql+gcQXpADkRtEQC4AeFzCWBFlg8cOACXIBaCJDQk1RJkoYQhwt/sI/vCAM tfFvqSVYDbTIpYHgb6+9wgRWf6ghVXIEE68E5UGtVDApG/APzJ7iBvpndYQRCN113hG0R1Kt6z2N PykxquZ+BUCjz3BTkBlo9JhpUqtJjYxeAOojMf9T94+MAEPp7jrHbGQGHQ6/P9Kx9Ggexw2NNfv2 1Wn/5rQvaV/gr9+7s6bRvBIKafaXu1fki/yPpPBPH88ImPlwz8DgZQPzf7u06ujBE6+ZfFqhRcQ3 3fuD5869855TOhgV07B92R9++af1fMrPrEhT2H/S1L6RcKiuOdHyCsbLTcCXTqLIPrss3xEFaP9f zCVfqeVjHvccOsI4sB94I3a3B8/U4BOLtsV6XXjL5NMylR/fO/uXG/dFj+k35IwBBQ2J5NZV8z/6 +J3VXxw8+/o5Fw0765inPqoMBpkSSN0jy72H+AP+TJIHInuMP9fWVdc0JZKhgvzcUHbTtBp07TCl pU1mU/TOjRcGQCYpvbBE9ebnFiQuvKiP/ekD1qo1H37Y0OuCEdnvy3oTOJzWxy8VSZ7vf9sQNpm/ JSSqqxsCgUh+caTl+xZtNS4HkxGJ0AEz4OaETx2oriNeTk4eP77lUOJ6w3U2nZefjpkXQX9NzBl5 xmkBp/KhWx5Zu5erW7pm5+o33lwai8SXzpu3pcb8eXLp6l18dbiknfnmh64cPEviSOb6D5v7nI/v nXPB0HYdx5R0Hte+4KYNMS6HpuSEQ8bMbPGKZP7/DbhDoePnPGTIiJgmhT+6ZwfLF2CYXBV1OOBO qy8QNFQtMMuW3LvumstXp+ENmp/2CL9rwe1TF+0Pmp+FUtixZn/73fAoXRTfleEXRabmn4rnH4hG RkRyhrv/3fDA0+v45SOlbuNraP74SfYLn07dJ1O+9dIBvp+/dfmUnPKuXc4tLRldOPgVwG01dRvf xjdQUB7IHeX3D/nViv2ZhsbaNUsuDQ5vXzL26JKx7YpHBke/XNvYxAdHzFbw2qvZIuYtsthfckK3 nGTFkqXNzfx9ke8SkLG98PH0DgSOv3Fqn8yuhfO+SEWPMh86MY0sQ1/Qn2r6PJXuxpccMslE1Yo3 f/T6lM0Nt5X5Dq5fu7tzTioR59IaiISDAT93bU4wfm0bSCf5+4CfUfI7LEt+NcCsJh1GmzHlpyOY mIJ0Mt6c9AfdWWMs+Xg+4IeuOe2P8HMqRHOTMGzREPfjNN+f4LteCf6uEOIrwn4ncnI/f4iYsVgi EMIhmIqbezYOfKuPj/PNNy78TnOCd7QQmlRDneO7euNX327XUL999YJRk6595YtHP/yR+zVlx7l6 0G+H13+vzBzS/L7DfLl7+W9uffOmn1X9bESkrnrz1lTEcZa20cQcPkzr+dbGR4eX5vJ8zuGnKntW jRz8/dBt9+29bVSHaKqueu/azXHzQObDKl4ATh3CdxLMumlmjQT5uZ/pIsuJVxsKE+UurnCm+OTv P/jdYw6uuueup/lFHCauWMwF1lQzHxvUMz3sEL55Eqva62RqqmtSTjBy3Mk9CnxpXzCz/PcP+X2D g+Fpzyw/yA08k2z+/MO3p4SHoQxH7l1dm9701JxrntrJQec4seeuvOmJTXGfE3tx+syf/3nR9aGh p8zZxNvIsrk/Ax8KT3t5db3ZLT5nxwevDvAP9vu+PeWG2b7T+QSeQyeuz6iRQ6y35h1zZ1yWGx0Z /ZfH1+xLL3/sh2PvW57IJGPxRMMn8wec+ftK84BjRVKz2eqcvkUdC3I7lHYacu4ln71y8bp7fr9G e8TYX/jOnL/yr1uIldhfzd/Wq+qSTqigQ98BnUJH0AjMj0PyC4oLitvlRYPO+nlPbfBNe20Wk4E1 UNCh88jhPYxovhvi8ELIUWNusInA/s0745EThg9z26x9dgQTZUDRgTNuuiB3w5+vuO1XX7h/hmTr MB+saJ485lZsljIr3xzEvSdeeX/5/OFdht3wqw8r00GOjq/e+c0Z1+ZuTvz1wJpLvlv+i81JJ1P5 Ya8z7un0+BP7GpdWbr+uV364uXHXuhre/sxqqF6/qraZhZyp2rvkRxc/OWrZy+9e12vP/P8YfV3u lsSK/aunXn7aQxt5Ou39+IQxD16+5I2mxkenlQ/E0RYzW5ScTqtn3VU54s7dlS/ce/Dxwd97r9fw 0967+5G/7qdTqYVzfhw4ZxA/TXC7KAdTs8jU6Hbm2HJn1YqtdVw1feV3rFz4/XX33PTEmrhjBo9V Hxp354Ojnp1TlnfZY29WmH13BI2Yljx019P33fvY/U+ubvLHl89bc8rPTidu6+I+5xOfbeW0wOQv DGcWL1zpOMf+4N+/3yfPfFXQX1A2esywUCwz/orxxc6eF19Y2qWs7Ljex+a7n0Jrqsx88IMo8yBM JZlh1n746Jvfemf5n275zS0ze+fPXnsgsfxPzziZDU/OeuzBJxc5zpZ9Tc7Wj/m64vk3X9a3OBrq UNq+XZgh4Mgyxx9EHD18kch8Jfhz54fz/n3q0O7FBc7K116E5Hezfj1n7nuQ7K1P71m13PHdfPXI klCoaPSkMZnFjJHZNC0D6svEvjx59pN3TD6hfVHnS2dclH7uK9+A4bOcrb+d/yXPhCnPZR74V/OV 7ZYZyU6DOc/MNuUvAaaK5gQdPnRf3NBz1IX/eVPg306du60uWHCU+fgg2nPEvJpXnvtp7xmTrmz3 b/N5orTVKJn+p/UdPqz/8P4lIR7pdb7DvgdngnAyBXwRw9m0YCGzwdgG77y6/IaH/nDvi/4ZF42Y +egIF+Wkqj6a3xAoNN8vLL3qJw+Cy2Tq//zTO5c3mQ9wCGZuArw5JhgHfhLFWc8HX6zx6KB/uTS5 t89lnb77zPLLh3JeTzz7wstO8cWSky73HRdxvmpucnyFOoqhNmcde6sgmMONwPHFNzgc+hzrHNId OubyY16+GMxg+yaMueDSQaHmMVOuifQqzvmy9qDTt5u7mHz8NkQJmwlpKUlE/kDk+MPRKPvUVXe4 +JmJfR74zzO37/BNuHskl3jzECWBNI8eHjCGhi/7BflFS2LPR+8vckb9sneeU+G6BoPn3/fUxY9O /faMr44q1ETS0U6Tbp2156wBpcN+/NGdZ51bGmilOd24jvrWuYP68cflaIR71MDJQ6753rI9tw44 whbhi6mvv5kOhjl4gjc+PI9TaNf7f7j+7ae79CiJ+hMN+3dV1ZFl6Oe3XsdXVyicUXzHi5Kfn/19 OJraNc/+/M3KZ4bf6svw1yqnuuLTvYU9+pZmnFSmnh8hRCNDJ0xJT1ha8/NxI8pCzbV1yXis2/Az nczMJ/88/o7ze8Sq9ztF7clg1XsVlVeUbnr83lsd5yF6kTaf1jXHGxPpaE4gdOrEizITP2r4xTmn 9Qwn6+v4Rm3HE/s7Gx58bXX5Bd0aH79rju/022KxOJdOVkkq0czDM5RTsPbX7234Trfjj2p696mn /Tc8zC9wis4eP/7Sa65Y7zy87Ef8jYFzBjyJx1JccKKZDY3762MBJ7Hz478MmPD78x+b2zuQoheU Zr7aGu7x8OIZnU9/xFfeP+gkKpZ/XnhiWWlBwN1IPYsj6Yrl2w7XmI88HKdyX1WsKT+drG0IFhb2 P+87zk0zJvyw5+t3lHeOBpoOVC5bceDUs/tEWJQJs5bdx3kmyLcCuU3xVsFd9mBV1VfxuN/P953D zAeDznObaTC7Aa37BQAGS/uDJlZkN7ZTtfSZIde/L7l85v3XDmtXlLnm3Ud+Mabnma5y1EdVswd0 HrHx9Rl9J1w2x6hGLa6a3W/s5L4z7uhaeH/5zJtv6LcYtmA4J9LB74M95Ge8Oo6Z/u4jj55VliVZ +tUDA/ue+ezMBZecMh6Ki68+xak1I5tNwh1lt1UxtXP5BhD9rlqzeKjRFPa9/u5er//kjAsGmG+z 2+I65jqZx44vfsxVjvrV289fdeYxWUBfc6ZTiode8Nbdr537PmJq2Z1XTF+U1f/ghT+eVpx6qrXG qTMXhq2jjxtrnB1nzEO/mzf9lD0f3HvNyB92nS2dM/CGB5eMyv4azxxWSp5f3jOsDLcOIv1hg6bp pFv09G5pZf+oAhgk3xV6/HfXZek5A2Lx+oZYJpxbzJtOS0k08c6SjhTkSgUPB1xtY7PV0KxrcszL UbYYCMPEcej+tMdEbkvSWFubCuUVRLUSjacWiltzjvJL7MSBA6m8ohxtHV4nHv/WuAVXP/f8RS1j 3RLvH/i3qa6uIZ7KySsqMA95U9pqUIbM9aRV0ftgwLwOtviCeL3skl7B0PNXTQ3y5S36wBZhVtgH bAv6r74xK9JgQkOhyUxQq2mGqmVpoglFI8WclYeXcG7UfCXEW4IhfvtxSBEK2xYk7sCaxeI+2bP8 MHseFcY1t/DQhzuiUiZubX4Wz2gUFx+KEqt4/8ZFZUv+9D8wGVBHGczDttkRNMqqTR0o7mB+wNiq aH8w4ObvUQwxBQTDQRPBDINbGHoKSi7BCGJh8tgcOtAsL3Ar/50C4ayXZJrulBgCa/o72b4ZFuk5 rqr6XPeXN98M/J+0Jlp+jv03Sd+adB7fJef10HzeTmEUmBIEPJE19GiQUdLkgovATHB8UTSLwrcN htffM5oWIzy1pbITI4zXZDH/PSEY+l+ejP9WeuovA252g1343s7bIcBKoQmaWZHQNpjFy9Sq2Rbv hSmuxahplVBZ2WL+7wksbkr2D5P0mUGnkxpH2382BDLTQA1AOwalmUn3ZPvu1b9GZsdQa9rEgwYq yyYl/MBErhqAmGEDg0xBqSZ4Nam9E0ATHrJXwjSFp8ZXPJgsCYIYvCY0iq6UFFS1+iJawWBAqRyI Kx5qNJJxRC9CwSTjqKYSoKYwgOipKWYO3Ic3MNPmtz0MN2b8UYGWQBgEACgBIDDEyBpo/YmbW7JS pymYGKTEXUUZY6KJiVjqiQbU9geBKDIpDWWFFwIa74iQhsYFWgpW0QJGjxWNlOiFwYTg9RKz3KkJ jRWlNyXLY5WWUHjbWZDK3zKgUWhoJVBrSLkioUSGjScx13tMOAa3bt2qIYYdGypYmAD5o6EICoCi YKrR4yu9ajTKDxKL0RxgAkMtE1YrS6BGKSsyRaMjpDRYKZZQJmqQlhyAwNQk73oYDYKlso7okYUR 2GsikLzsQtFoWH6sYmAcELAqDWRMkuVCUwI1MoQEIm1kvW8gG9M3/P8AKZJqnGGnIBCbRG3N5FkZ PUVIBOurTtL8/1YYbhU6rhFn0BEoTIlq9oeV/wtmXbOSc3g1+gAAAABJRU5ErkJggg== --001a1134635a02620d0515733d6e-- From nobody Thu May 7 01:51:50 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861F11A1AA7; Thu, 7 May 2015 01:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzjGJ6j0s-cU; Thu, 7 May 2015 01:51:47 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809C01ACD0D; Thu, 7 May 2015 01:51:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwIAJQmS1WHCzIm/2dsb2JhbABcgmYmgTIGs2ABAQEBAQEGmUwCgSlMAQEBAQEBgQuEIAEBAQECARIoSwQCAQgNAQMEAQEBChQJBzIUCQgBAQQBEggaiAIIAacrnXQBAQEBAQUBAQEBAQEBG4YXhSKEVDgGgxGBFgWSKJI/jlIjYYMVb4FEgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,384,1427774400"; d="scan'208";a="115342765" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 May 2015 04:51:45 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 07 May 2015 04:51:44 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Thu, 7 May 2015 10:51:43 +0200 From: "Romascanu, Dan (Dan)" To: Viktor Dukhovni , "ietf@ietf.org" , "dane@ietf.org" Thread-Topic: Gen-ART review of draft-ietf-dane-smtp-with-dane-16 Thread-Index: AdCIDSOzVVOyqF7nQYCd92xyMPNzuf//5UsA//66qzA= Date: Thu, 7 May 2015 08:51:43 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA254E7@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CA24107@AZ-FFEXMB04.global.avaya.com> <20150506152306.GW17272@mournblade.imrryr.org> In-Reply-To: <20150506152306.GW17272@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dane] Gen-ART review of draft-ietf-dane-smtp-with-dane-16 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 08:51:49 -0000 Hi, Thanks for the quick response and for addressing my comments.=20 See in-line.=20 Regards, Dan > -----Original Message----- > From: Viktor Dukhovni [mailto:ietf-dane@dukhovni.org] > Sent: Wednesday, May 06, 2015 6:23 PM > To: ietf@ietf.org; dane@ietf.org > Cc: Romascanu, Dan (Dan) > Subject: Re: Gen-ART review of draft-ietf-dane-smtp-with-dane-16 >=20 > On Wed, May 06, 2015 at 02:58:42PM +0000, Romascanu, Dan (Dan) wrote: >=20 > > Ready with minor comments. > > > > I liked the operational considerations section and the security > > consideration section - very useful in putting this work in the > > context of other similar contributions. >=20 > Thanks. >=20 > > Minor issues: > > > > As the document uses heavily the term 'downgrade' (downgrade attack, > > downgrade-resistant) it would be nice to either explain or provide a > > reference for what it means in the context of this work. >=20 > In RFC 4949, at the bottom of page 112 we find: >=20 > downgrade attack > (I) A type of man-in-the-middle attack in which the attacker can > cause two parties, at the time they negotiate a security > association, to agree on a lower level of protection than the > highest level that could have been supported by both of them. >=20 > We could add "downgrade attack" to the terminology, and briefly define > "downgrade resistance" under the same heading. Alternatively, since the > primary downgrade at issue is stripping of STARTTLS, some additional text > could be added in 1.3.1 to introduce the terms. >=20 > Any advice on how to proceed? >=20 I personally preferring having all key terms in one place - this makes read= ing easier. So I would go for inserting text in the terminology section wit= h proper reference to RFC 4949.=20 > > Nits/editorial comments: > > > > The last paragraph in section 2.2.1, page 15 has a comment marked > > twice by --. This may be an editorial left-over to be corrected. >=20 > That's what the RFC editor's xml2rfc does with "—". When I run > xml2rfc, it produces "richer" HTML output, in which the mdashes remain as > such. Should I avoid "—"? Yes - and talk with the tools team, this may be a bug >=20 > -- > Viktor. From nobody Thu May 7 06:12:42 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AB51A8AB1 for ; Thu, 7 May 2015 06:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id js_lSPXOBPqw for ; Thu, 7 May 2015 06:12:37 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4191A8AB3 for ; Thu, 7 May 2015 06:12:37 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id DCA2F204AC for ; Thu, 7 May 2015 09:12:36 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Thu, 07 May 2015 09:12:36 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=kqnfIAl3QrLcte+/ZYaTJQm3cmM=; b=WFoQ2c aO09f4+F/MmysZlcHD5xZsgQewm/82X82zURCm/uH7mMUCH3Gvn7uhpmyixkd1jr yMgJlBKyVzwpNFGjZy+QaoN3chlq3a2Q4eA/Tj+R+JU5+c4kClD9dWM1tGjaLihb mj/k4BlhtZ/LSyD0FnXi03pNnCBVn9sYSZ2xs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=kqnfIAl3QrLcte+ /ZYaTJQm3cmM=; b=WKmFFDz/8qRvl8hLVvuQYOVogeiDSwS9ybfxtCzVMSR8FOu Y4QLGICXZTVOFReBBAAa5zacNrPhkn66JfYniRNH+d3OsjsAGhZnaEZAqg4DaNnB m8VDxzca53C3HQJCB5E19nmpftQhVoK6u9t8OwBGnU0+4HFKF0Jwt4EyEghQ= Received: by web6.nyi.internal (Postfix, from userid 99) id AEDEC4B863; Thu, 7 May 2015 09:12:36 -0400 (EDT) Message-Id: <1431004356.252704.263950717.6C0F1FA7@webmail.messagingengine.com> X-Sasl-Enc: ZR52RWNBndlR4qpXvSv/M0KW81tgv3wFG8pOlBNtVRyD 1431004356 From: nudge To: dane@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - html In-Reply-To: <20150504053729.GN17743@mournblade.imrryr.org> References: <20150427180122.GH20186@mournblade.imrryr.org> <20150504053729.GN17743@mournblade.imrryr.org> Date: Thu, 07 May 2015 15:12:36 +0200 Archived-At: Subject: Re: [dane] Feedback please: (WGLC for draft-ietf-dane-ops-07) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 13:12:40 -0000 On Mon, 4 May 2015, at 07:37 AM, Viktor Dukhovni wrote: > > Really, nobody has any comments? Surely the document is not that > perfect. :-) If at all possible, please provide feedback soon! > > -- > Viktor. Hi, Perhaps it's just me, but doesn't this section have a rather obvious error in it ? 2.1. Example TLSA record In the example TLSA record below: _25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 ( E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F5303EBFBB77D022F834C0 ) The TLSA Certificate Usage is DANE-TA(2), the selector is Cert(0) and the matching type is SHA2-256(1). The last field is the Certificate Association Data Field, which in this case contains the SHA2-256 digest of the server certificate. ---- Ian Maddison From nobody Thu May 7 07:52:32 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631011A90CD for ; Thu, 7 May 2015 07:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFDZDsxyTtCb for ; Thu, 7 May 2015 07:52:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13FBB1A6F2A for ; Thu, 7 May 2015 07:52:26 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 327CA283031; Thu, 7 May 2015 14:52:25 +0000 (UTC) Date: Thu, 7 May 2015 14:52:25 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150507145224.GK17272@mournblade.imrryr.org> References: <20150427180122.GH20186@mournblade.imrryr.org> <20150504053729.GN17743@mournblade.imrryr.org> <1431004356.252704.263950717.6C0F1FA7@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1431004356.252704.263950717.6C0F1FA7@webmail.messagingengine.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Feedback please: (WGLC for draft-ietf-dane-ops-07) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 14:52:31 -0000 On Thu, May 07, 2015 at 03:12:36PM +0200, nudge wrote: > Perhaps it's just me, but doesn't this section have a rather obvious error > in it ? > > 2.1. Example TLSA record > > In the example TLSA record below: > > _25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 ( > E8B54E0B4BAA815B06D3462D65FBC7C0 > CF556ECCF9F5303EBFBB77D022F834C0 ) > > The TLSA Certificate Usage is DANE-TA(2), the selector is Cert(0) and > the matching type is SHA2-256(1). The last field is the Certificate > Association Data Field, which in this case contains the SHA2-256 > digest of the server certificate. Thanks, a typo. Likely introduced when the numbers were made symbolic. Are there yet (or expected to be) any DNS zone file parsers that consume the symbolic TLSA paramter names? Similarly any wire DNS record decoders that present the human-readable output with TLSA parameters in symbolic form? That is, should the examples use the symbolic names in the record syntax, and not just in the text? -- Viktor. Patch below: --- a/draft-ietf-dane-ops +++ b/draft-ietf-dane-ops @@ -306,7 +306,7 @@
-_25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 ( +_25._tcp.mail.example.com. IN TLSA DANE-TA Cert SHA2-256 ( E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F5303EBFBB77D022F834C0 ) From nobody Thu May 7 09:23:46 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84F81A0167 for ; Thu, 7 May 2015 09:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ayjeuwmom8GZ for ; Thu, 7 May 2015 09:23:44 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C341ACDB8 for ; Thu, 7 May 2015 09:23:36 -0700 (PDT) Received: by wgiu9 with SMTP id u9so48852354wgi.3 for ; Thu, 07 May 2015 09:23:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=6n6w4jyf8NSFXHm8gLHRlHcTGDWDrzczOcfNbNRhCpE=; b=KY7BviwhwPRdZAgXIp1ZsH7bGo9QRftzSrk8NhK4ef2gsiPEXQGqoFMp2XjWyfD7lU GC1aufBV8EVtb1Byd+9dnX6wbDiPzFEvYgrQkc5xOciU3lZtyia2r0cK1xMQefbzU57A UsukRvIW8qzh/YT2K3K2vyKr7CQXthae18HWrtqZ+J/wKiCZAPQiRuq5spGqEq+Q/uJq 4ysrNewAVFlj9vqfwsMQIZ0ZaBDTI0eQJyG0lQzE7bK1Hn6bvSjD8/orkRsQeUiSEg6/ kYyoZ8iRPyGw5wuhxw1Jy97gGKRWlDE70gao71x694iDlJwAYnNIcdbFNHPkLbFZfqdq E1Kw== X-Gm-Message-State: ALoCoQkyGhly10HAt+TMoqLTLJu2GpOnCElENeeimC3EVIJR0V7df415+NRes9FQdrbUI0H2OCK2 MIME-Version: 1.0 X-Received: by 10.194.60.67 with SMTP id f3mr9230261wjr.28.1431015815659; Thu, 07 May 2015 09:23:35 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Thu, 7 May 2015 09:23:35 -0700 (PDT) Date: Thu, 7 May 2015 12:23:35 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dane] A reminder about RFC 6982 - The Implementation Status Section. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 16:23:45 -0000 Hi all, A quick reminder to the WG about RFC 6982: Improving Awareness of Running Code: The Implementation Status Section. Authors, if you are aware of implementations of your proposal, please include an "Implementation Status" section in your draft. Showing that there are implementations demonstrates interest and shows that your idea actually works in practice. It also makes reviewer's,and document shepherd's, lives easier. W -- 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. ---maf -- 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. ---maf From nobody Thu May 7 09:31:08 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82981A1B6E for ; Thu, 7 May 2015 09:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SleNROuyCQzG for ; Thu, 7 May 2015 09:31:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8501ACDA8 for ; Thu, 7 May 2015 09:31:05 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D83A7283031; Thu, 7 May 2015 16:31:04 +0000 (UTC) Date: Thu, 7 May 2015 16:31:04 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150507163104.GS17272@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] A reminder about RFC 6982 - The Implementation Status Section. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 16:31:07 -0000 On Thu, May 07, 2015 at 12:23:35PM -0400, Warren Kumari wrote: > A quick reminder to the WG about RFC 6982: Improving Awareness of > Running Code: The Implementation Status Section. > > Authors, if you are aware of implementations of your proposal, please > include an "Implementation Status" section in your draft. Showing that > there are implementations demonstrates interest and shows that your > idea actually works in practice. It also makes reviewer's,and document > shepherd's, lives easier. The SMTP draft is in IETF LC. It has no such section, but running code is in Postfix and Exim. Should anything be done at this (late) stage? -- Viktor. From nobody Thu May 7 09:40:39 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC761ACD98 for ; Thu, 7 May 2015 09:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhRfxOyX8NOF for ; Thu, 7 May 2015 09:40:37 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF1B1A09CF for ; Thu, 7 May 2015 09:40:35 -0700 (PDT) Received: by wgic8 with SMTP id c8so22795510wgi.1 for ; Thu, 07 May 2015 09:40:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=IlwG0bBXA2Q8F2IuuF/IScGSblzCx1RKmt00u6YMYV0=; b=DzYGikZT4Ha+fRJRP2Yt9xnY69FIPgEf6zX565g8TbUEkeDaT4J0OrIjRxQ7XWRLKL kt63oUdZJp55yiMimx4yalHgHePyJZy1KwSLjK/4qsjeYlYYaKIfbF3VGg+afP/PM8lv Ht6PgGFWhXXlLcg6Fj7JSuxAdT+j8sbGoYvKzG0zBbqcz1+dRdjXfDX7ybnqoqP9zMF/ VrFV2pWmeUXCShqbLG6znFNx+92v7BW6+LwuWY99V/wtMtJ80NtzU/NaHbjOD+GnoTxx qb9fsatWbgxy5oRNAFe2moNq5Rfkp1BckzBQ6K7iMcVwPtg6F9f8ZJPo119nbDVxFQKn UwGQ== X-Gm-Message-State: ALoCoQl1s+DRAGgkn5DKLZf/WNLsjUFiBNUrJPYLVHqAQIYxe6+7thbFwCenQj43nqW+qCFARJy4 MIME-Version: 1.0 X-Received: by 10.180.83.193 with SMTP id s1mr8240863wiy.22.1431016834178; Thu, 07 May 2015 09:40:34 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Thu, 7 May 2015 09:40:33 -0700 (PDT) In-Reply-To: <20150507163104.GS17272@mournblade.imrryr.org> References: <20150507163104.GS17272@mournblade.imrryr.org> Date: Thu, 7 May 2015 12:40:33 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] A reminder about RFC 6982 - The Implementation Status Section. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 16:40:38 -0000 On Thu, May 7, 2015 at 12:31 PM, Viktor Dukhovni wrote: > On Thu, May 07, 2015 at 12:23:35PM -0400, Warren Kumari wrote: > >> A quick reminder to the WG about RFC 6982: Improving Awareness of >> Running Code: The Implementation Status Section. >> >> Authors, if you are aware of implementations of your proposal, please >> include an "Implementation Status" section in your draft. Showing that >> there are implementations demonstrates interest and shows that your >> idea actually works in practice. It also makes reviewer's,and document >> shepherd's, lives easier. > > The SMTP draft is in IETF LC. It has no such section, but running > code is in Postfix and Exim. Should anything be done at this (late) > stage? Nope. The Implementation Status section is not mandatory, it just (IMO) shows the document in a better light. If you write a new doc (or have an existing doc that is not in LC) I see no downside to including this section. This reminder to the list was precipitated by a reminder that Benoit sent to the WG Chairs list -- it wasn't aimed at anyone in particular... W > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- 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. ---maf From nobody Thu May 7 18:08:09 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D98D1B2D71 for ; Thu, 7 May 2015 18:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UcXNtnO0cpn for ; Thu, 7 May 2015 18:08:06 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88BE11B2D6D for ; Thu, 7 May 2015 18:08:06 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 2DCD33493C3; Fri, 8 May 2015 01:08:04 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id BE446160033; Fri, 8 May 2015 01:08:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8A91616006D; Fri, 8 May 2015 01:08:19 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DkTVQMh1ZBvJ; Fri, 8 May 2015 01:08:19 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 096A5160033; Fri, 8 May 2015 01:08:19 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 559162DEAAE6; Fri, 8 May 2015 11:08:01 +1000 (EST) To: nudge From: Mark Andrews References: <20150427180122.GH20186@mournblade.imrryr.org> <20150504053729.GN17743@mournblade.imrryr.org> <1431004356.252704.263950717.6C0F1FA7@webmail.messagingengine.com> In-reply-to: Your message of "Thu, 07 May 2015 15:12:36 +0200." <1431004356.252704.263950717.6C0F1FA7@webmail.messagingengine.com> Date: Fri, 08 May 2015 11:08:00 +1000 Message-Id: <20150508010801.559162DEAAE6@rock.dv.isc.org> Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Feedback please: (WGLC for draft-ietf-dane-ops-07) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 01:08:08 -0000 In message <1431004356.252704.263950717.6C0F1FA7@webmail.messagingengine.com>, nudge writes: > On Mon, 4 May 2015, at 07:37 AM, Viktor Dukhovni wrote: > > > > Really, nobody has any comments? Surely the document is not that > > perfect. :-) If at all possible, please provide feedback soon! > > > > -- > > Viktor. > > Hi, > > Perhaps it's just me, but doesn't this section have a rather obvious error in > it ? > > > 2.1. Example TLSA record > > In the example TLSA record below: > > _25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 ( > E8B54E0B4BAA815B06D3462D65FBC7C0 > CF556ECCF9F5303EBFBB77D022F834C0 ) Which is a invalid TLSA record. "PKIX-TA", "Cert" and "SHA2-256" should all be numbers. RFC6698 2.2. TLSA RR Presentation Format The presentation format of the RDATA portion (as defined in [RFC1035]) is as follows: o The certificate usage field MUST be represented as an 8-bit unsigned integer. o The selector field MUST be represented as an 8-bit unsigned integer. o The matching type field MUST be represented as an 8-bit unsigned integer. o The certificate association data field MUST be represented as a string of hexadecimal characters. Whitespace is allowed within the string of hexadecimal characters, as described in [RFC1035]. This is how named parses TLSA records. Note there is *no* handling of non numbers. There is *no* intention to change this. /* * Certificate Usage. */ RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number, ISC_FALSE)); if (token.value.as_ulong > 0xffU) RETTOK(ISC_R_RANGE); RETERR(uint8_tobuffer(token.value.as_ulong, target)); /* * Selector. */ RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number, ISC_FALSE)); if (token.value.as_ulong > 0xffU) RETTOK(ISC_R_RANGE); RETERR(uint8_tobuffer(token.value.as_ulong, target)); /* * Matching type. */ RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number, ISC_FALSE)); if (token.value.as_ulong > 0xffU) RETTOK(ISC_R_RANGE); RETERR(uint8_tobuffer(token.value.as_ulong, target)); Now if you want to have descriptions then do something like this: _25._tcp.mail.example.com. IN TLSA ( 0 ; PKIX-TA 0 ; Cert 1 ; SHA2-256 E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F5303EBFBB77D022F834C0 ) Don't have unparsable records. Mark > The TLSA Certificate Usage is DANE-TA(2), the selector is Cert(0) and > the matching type is SHA2-256(1). The last field is the Certificate > Association Data Field, which in this case contains the SHA2-256 > digest of the server certificate. > > > > ---- Ian Maddison > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu May 7 20:49:05 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA5A1A1B2B for ; Thu, 7 May 2015 20:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5vkMZVM7GnF for ; Thu, 7 May 2015 20:49:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67F561A1AE8 for ; Thu, 7 May 2015 20:49:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F1703283032; Fri, 8 May 2015 03:49:00 +0000 (UTC) Date: Fri, 8 May 2015 03:49:00 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150508034900.GF17272@mournblade.imrryr.org> References: <20150427180122.GH20186@mournblade.imrryr.org> <20150504053729.GN17743@mournblade.imrryr.org> <1431004356.252704.263950717.6C0F1FA7@webmail.messagingengine.com> <20150508010801.559162DEAAE6@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150508010801.559162DEAAE6@rock.dv.isc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Feedback please: (WGLC for draft-ietf-dane-ops-07) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 03:49:04 -0000 On Fri, May 08, 2015 at 11:08:00AM +1000, Mark Andrews wrote: > > 2.1. Example TLSA record > > > > In the example TLSA record below: > > > > _25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 ( > > E8B54E0B4BAA815B06D3462D65FBC7C0 > > CF556ECCF9F5303EBFBB77D022F834C0 ) > > Which is a invalid TLSA record. "PKIX-TA", "Cert" and "SHA2-256" > should all be numbers. I have no problem with that. What do we make of the text in RFC 7218: https://tools.ietf.org/html/rfc7218#section-1 It is expected that DANE parsers in applications and DNS software can adopt parsing the acronyms for each field. > This is how named parses TLSA records. Note there is *no* handling of > non numbers. There is *no* intention to change this. Should 7218 have an erratum filed to clarify that the acronyms are not intended to be used in zone files? Given that DNS software does not support non-numbers today, I am fine with numbers in the document, so I'm just curious about the apparent conflict with 7218. -- Viktor. From nobody Thu May 7 23:30:34 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06CC51ACC82 for ; Thu, 7 May 2015 23:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eZiwKAiQTU6 for ; Thu, 7 May 2015 23:30:31 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52CC81A6FFA for ; Thu, 7 May 2015 23:30:31 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id CD74A1FCADA for ; Fri, 8 May 2015 06:30:27 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 77F1916004E for ; Fri, 8 May 2015 06:30:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 39015160083 for ; Fri, 8 May 2015 06:30:42 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8N7EJ55373Sb for ; Fri, 8 May 2015 06:30:42 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id AFDB216004E for ; Fri, 8 May 2015 06:30:41 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 225A32DF1742 for ; Fri, 8 May 2015 16:30:24 +1000 (EST) To: dane@ietf.org From: Mark Andrews References: <20150427180122.GH20186@mournblade.imrryr.org> <20150504053729.GN17743@mournblade.imrryr.org> <1431004356.252704.263950717.6C0F1FA7@webmail.messagingengine.com> <20150508010801.559162DEAAE6@rock.dv.isc.org> <20150508034900.GF17272@mournblade.imrryr.org> In-reply-to: Your message of "Fri, 08 May 2015 03:49:00 +0000." <20150508034900.GF17272@mournblade.imrryr.org> Date: Fri, 08 May 2015 16:30:22 +1000 Message-Id: <20150508063024.225A32DF1742@rock.dv.isc.org> Archived-At: Subject: Re: [dane] Feedback please: (WGLC for draft-ietf-dane-ops-07) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 06:30:33 -0000 In message <20150508034900.GF17272@mournblade.imrryr.org>, Viktor Dukhovni writ es: > On Fri, May 08, 2015 at 11:08:00AM +1000, Mark Andrews wrote: > > > > 2.1. Example TLSA record > > > > > > In the example TLSA record below: > > > > > > _25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 ( > > > E8B54E0B4BAA815B06D3462D65FBC7C0 > > > CF556ECCF9F5303EBFBB77D022F834C0 ) > > > > Which is a invalid TLSA record. "PKIX-TA", "Cert" and "SHA2-256" > > should all be numbers. > > I have no problem with that. What do we make of the text in RFC > 7218: > > https://tools.ietf.org/html/rfc7218#section-1 > > It is expected that DANE parsers in applications and DNS > software can adopt parsing the acronyms for each field. > > > This is how named parses TLSA records. Note there is *no* handling of > > non numbers. There is *no* intention to change this. > > Should 7218 have an erratum filed to clarify that the acronyms are > not intended to be used in zone files? Acronyms are not portable at the record level. Additionally almost no one constructs TLSA records by hand. They all use tools. Emitting acronyms just means the records are not maximally readable. > Given that DNS software does not support non-numbers today, I am > fine with numbers in the document, so I'm just curious about the > apparent conflict with 7218. > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue May 12 00:36:35 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA961A8A3C for ; Tue, 12 May 2015 00:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVqUlXBMAWsy for ; Tue, 12 May 2015 00:36:32 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC72C1A1BF8 for ; Tue, 12 May 2015 00:35:16 -0700 (PDT) Received: by widdi4 with SMTP id di4so2447443wid.0 for ; Tue, 12 May 2015 00:35:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=qK86cciGe49evlEKm+Nx7QI1Dc7hZ3VJfgBBPCAJWLU=; b=IodRElv9Nz0dCPDvnIherKyufO4oN1mUJCo3F5U/Lfm3Iu6wi8WvfIJUyHB+4szcvi qkSpeMHaNdn1s3bicXWx9I8iV5W31r6fZzw1Ed5JVrHV9WzeP1Hszz+WlSg5Adi41AEk cRO/JmYqZAC7Q26A5YCNO1e/Ux/9pykNADwnG4MHmMjP8sO6bhe52Fm5KnvocZRy3UOG SEgVFVBordPBdCsFXifZwkGPFsP9Vr2Na6beMXEZodSuMmKhSWRQRYPsW3t2ZMpeQY83 f0shv44EERJbEUb0moGB6yDMUQOIUwkC/vobHEDe2vxCxRC/1FpFB3B/70axYQHLfeFT Ydrw== X-Gm-Message-State: ALoCoQnMHIURQjKyaSRt2XeHMIbdK1jMvahkAvuF+b0qTsG4eIk72HNcR+XfyXzD/f3aQR8WZu61 MIME-Version: 1.0 X-Received: by 10.180.101.65 with SMTP id fe1mr27009267wib.22.1431416115248; Tue, 12 May 2015 00:35:15 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Tue, 12 May 2015 00:35:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 May 2015 09:35:15 +0200 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] WGLC for draft-ietf-dane-ops-07 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2015 07:36:33 -0000 On Mon, Apr 27, 2015 at 6:14 PM, Warren Kumari wrote: > Dear DANE WG, > > The authors of draft-ietf-dane-ops have indicated that they believe > that the document is ready, and have asked for Working Group Last Call > (actually, they requested this a while back, we'd delayed while doing > toe other docs...) > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ > > Please review this draft to see if you think it is ready for > publication and send comments to the list, clearly stating your view. > > This WGLC ends Mon 11-May-2015. > > ... and this WGLC ended yesterday. Olafur and I are at RIPE this week, and will meet to discuss / call consensus.... W > In addition, to satisfy RFC 6702 ("Promoting Compliance with > Intellectual Property Rights (IPR)"): > Are you personally aware of any IPR that applies to > draft-ietf-dane-ops? If so, has this IPR been disclosed in compliance > with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more > details.) > > Thanks, > Warren Kumari > (as DANE WG co-chair) > > -- > 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. > ---maf -- 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. ---maf From nobody Tue May 12 05:46:59 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2884E1B2C21 for ; Tue, 12 May 2015 05:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y63igZT8OQVr for ; Tue, 12 May 2015 05:46:56 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93371B2C1F for ; Tue, 12 May 2015 05:46:55 -0700 (PDT) Received: by wgin8 with SMTP id n8so8474247wgi.0 for ; Tue, 12 May 2015 05:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=YOXKjWpu+MauCVLpnEt44w35gFqqKxgGdSs63gyPQ8k=; b=obYITorXSDFw3qrQDH44CEkOLAF7ZoWm/wiiwMLpoffMdMQA0xGyeXdL4VUsZhG154 r9cWO5zMuQC1Vws9oASQLqUhtxhiE2Bv4R6ZW4OT3Y2KaTP8gOAXoZTa2DIZWAjuV/NS Gr2Rk8VEXnaabw81yxvzhcJnlJgC9cNzgFpBQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=YOXKjWpu+MauCVLpnEt44w35gFqqKxgGdSs63gyPQ8k=; b=YqmUyBKDDTGtQDcW5ylT8cmXNySZ8asmnqzXbjegnzc02ax3bCXAlinAGHwheVqz/9 hIpiw77bI53sWlXbqE9lzj1fG+w6yVvyypQrTdCMCSstYTD8l1rGzeEiR8i8QfBcvqzV E/4qB09ww9WNnML6OEJKOJab9x0g4wg2E/hqfPb91TzfnaBxDLm3cx/YzP0yGMiQJP3d w/fivi07loAkmmXGYDfn/ud2yfYXpRlN5y8WtdMjD3w3LnmzJU2Lm9YoAMYTXEawQq5o 251573M8t1QG88xZkkMra4KmVKhU6oeVRkIs71wn/3pL9CwL3pbbYU6CVEaoF4tUGlS5 PlyA== X-Gm-Message-State: ALoCoQk+KV+OWSHlyFUKgUOFpKalG/q8BBRVCiKVL4lj0xClGUTA9gmogaj5gbpMUTzZK8VKXTGG MIME-Version: 1.0 X-Received: by 10.180.97.129 with SMTP id ea1mr30426587wib.24.1431434814378; Tue, 12 May 2015 05:46:54 -0700 (PDT) Received: by 10.28.142.143 with HTTP; Tue, 12 May 2015 05:46:54 -0700 (PDT) X-Originating-IP: [207.172.212.184] Date: Tue, 12 May 2015 08:46:54 -0400 Message-ID: From: Kyle Rose To: dane@ietf.org Content-Type: multipart/alternative; boundary=f46d04426f18a167100515e1e38d Archived-At: Subject: [dane] "need not change across certificate renewals with the same key" X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2015 12:46:57 -0000 --f46d04426f18a167100515e1e38d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I wasn't able to find anything in the archives addressing this, so apologies in advance if this has been discussed. The draft statement that the record "need not change across certificate renewals with the same key" seems misleading. If anything in the certificate changes=E2=80=94and typically the expiration date will change i= f a certificate is regenerated using common tools, whether or not it is likely to be honored by a client=E2=80=94the certificate digest will change. Since presumably the TLSA record digest is of the entire certificate and not simply of the public key, as the authenticity of much of the metadata within the certificate is still of interest to clients, this means the digest in the TLSA record will change. It seems in fact that any renewal of the certificate producing anything other than a bit-identical output would necessitate a record change. Or what am I missing? Kyle --f46d04426f18a167100515e1e38d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I wasn't able to find anything in the a= rchives addressing this, so apologies in advance if this has been discussed= .

The draft statement that the record "need not change ac= ross certificate renewals with the same key" seems misleading. If anyt= hing in the certificate changes=E2=80=94and typically the expiration date w= ill change if a certificate is regenerated using common tools, whether or n= ot it is likely to be honored by a client=E2=80=94the certificate digest wi= ll change. Since presumably the TLSA record digest is of the entire certifi= cate and not simply of the public key, as the authenticity of much of the m= etadata within the certificate is still of interest to clients, this means = the digest in the TLSA record will change.

It seems in fa= ct that any renewal of the certificate producing anything other than a bit-= identical output would necessitate a record change.

Or what am I missing?

Kyle

--f46d04426f18a167100515e1e38d-- From nobody Tue May 12 05:53:08 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B861B2C36 for ; Tue, 12 May 2015 05:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yqCBKIAg6Av for ; Tue, 12 May 2015 05:52:59 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65D41B2C2C for ; Tue, 12 May 2015 05:52:59 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lmJvY17W3z1Hn; Tue, 12 May 2015 14:52:57 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=cv6Yfchg X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id hYu5tCDkLcNg; Tue, 12 May 2015 14:52:54 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 12 May 2015 14:52:54 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 832338002E; Tue, 12 May 2015 08:52:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1431435171; bh=WbCbmAjDnjoYmN3l/+uFXhgP9uOOfzJz6R2azXlYb5s=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cv6YfchgL5bcOg3x0htlW9Akd7u1i1LY7ch/b96ZUV20x7/7fd54ZjT1HAMXlNKGK db95gvvo8FvaYmmciuYNfSySgrzWgurDVGPJYfq1TyGy2ByrXWbUpCco8/b4W+8Wm6 D5YnXHcp4MK9AEXagWCS324IDNNScYclQK2L8xUE= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t4CCqpOj009529; Tue, 12 May 2015 08:52:51 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 12 May 2015 08:52:51 -0400 (EDT) From: Paul Wouters To: Kyle Rose In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: dane@ietf.org Subject: Re: [dane] "need not change across certificate renewals with the same key" X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2015 12:53:02 -0000 On Tue, 12 May 2015, Kyle Rose wrote: > The draft statement that the record "need not change across certificate renewals with the same key" seems misleading. If > anything in the certificate changes—and typically the expiration date will change if a certificate is regenerated using > common tools, whether or not it is likely to be honored by a client—the certificate digest will change. Since presumably the > TLSA record digest is of the entire certificate and not simply of the public key, as the authenticity of much of the > metadata within the certificate is still of interest to clients, this means the digest in the TLSA record will change. > > It seems in fact that any renewal of the certificate producing anything other than a bit-identical output would necessitate > a record change. > > Or what am I missing? https://tools.ietf.org/html/rfc6698#section-2.1.2 There are two main pubishers of TLSA records. Those who want an addotional non-CA third party certificate validator, and those who want to replace the CA. For those replacing the CA, the only item of interest in the certificate is the public key part. These people likely will need to allow for CA's for the next little while, so they will do the regular "renewing" of the certificate, but they won't care to put any of that under TLSA verification, as it is just a CA/PKIX place holder. Paul From nobody Tue May 12 06:26:30 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9531A1F00 for ; Tue, 12 May 2015 06:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKu2GY_jxgmU for ; Tue, 12 May 2015 06:26:28 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C971B2C64 for ; Tue, 12 May 2015 06:26:25 -0700 (PDT) Received: by wizk4 with SMTP id k4so153702465wiz.1 for ; Tue, 12 May 2015 06:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xGNBncVODGHGQ/yF2f2tKSSSkCAlTkVg7N7n8l7+rAM=; b=PipZC7cLBPGxed3ALWAPIkqOlU6JoBtzNLVH09OB3wZeAnu6FJdDifntobmo9n8UIL rtoqF7cmdfWYOoMJMyj+1aNB0zylH7A5EB4t+1eMoOrH1+gVG8lhxykYkGOjJerl36/z 9mlztmeq215+BK8XyjIrmLdWbPGYWi8pAiovE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xGNBncVODGHGQ/yF2f2tKSSSkCAlTkVg7N7n8l7+rAM=; b=FjfoATmg7Eb3TqBF1D49S9Lc09CPKx2LJuS2HVQXmeP/YZcwG59V9hrAvmSeYRxkzM SRkfG40H0Bqf7yYusUy6O6rCk21eNzo63w4uFUv8OCfuGYEWxe8XHp8yuKHryzChKT89 4YRcLTY7vA3pgdar8dpyubs+G8kQYQWQX/p3P1IusIRdrPTL//Tcb2GEcBNix/kbTSXT rTR7hfxhtLBBh+c3MBqIdUcg6AnplgmdafFyCOppJriu7xrlgY4PaelTqpJ3SHEJyPGK GGlE7ZCc/HZJ5xV8MJBZyLR/LBF+IbASLQB5HHRkD+RTnuGAM2wyaLlvV8lROmLwc/au oSrQ== X-Gm-Message-State: ALoCoQl5SFl/xfrdGx/s+hrI6+lUpI+qvbGsd4wO2hLr91CQyErModA4SWS9n3OITZZMMAE80xr7 MIME-Version: 1.0 X-Received: by 10.180.93.7 with SMTP id cq7mr5436828wib.24.1431437184652; Tue, 12 May 2015 06:26:24 -0700 (PDT) Received: by 10.28.142.143 with HTTP; Tue, 12 May 2015 06:26:24 -0700 (PDT) X-Originating-IP: [207.172.212.184] In-Reply-To: References: Date: Tue, 12 May 2015 09:26:24 -0400 Message-ID: From: Kyle Rose To: Paul Wouters Content-Type: multipart/alternative; boundary=f46d043892ade8e9e70515e270b6 Archived-At: Cc: dane@ietf.org Subject: Re: [dane] "need not change across certificate renewals with the same key" X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2015 13:26:29 -0000 --f46d043892ade8e9e70515e270b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If the DANE-EE entry has a SubjectPublicKeyInfo hash, then the metadata within the certificate can be trusted only if the certificate signature is validated against a trust anchor: a self-signed certificate is sufficient (and probably ideal) here, since the client has already trusted the public key via DANE. Absent signature verification, the client should probably throw away the rest of the certificate to avoid the temptation of trusting any of it: it's simply unclear to me what are the security implications to the universe of clients of having unauthenticated data present in the certificate or associated client context. What I mean is, what data from certificates other than the public key modify clients' behaviors? It may be "nothing" (i.e., that "the only item of interest in the certificate is the public key part"), but it's not clear to me that this is the case. Kyle On Tue, May 12, 2015 at 8:52 AM, Paul Wouters wrote: > On Tue, 12 May 2015, Kyle Rose wrote: > > The draft statement that the record "need not change across certificate >> renewals with the same key" seems misleading. If >> anything in the certificate changes=E2=80=94and typically the expiration= date >> will change if a certificate is regenerated using >> common tools, whether or not it is likely to be honored by a client=E2= =80=94the >> certificate digest will change. Since presumably the >> TLSA record digest is of the entire certificate and not simply of the >> public key, as the authenticity of much of the >> metadata within the certificate is still of interest to clients, this >> means the digest in the TLSA record will change. >> >> It seems in fact that any renewal of the certificate producing anything >> other than a bit-identical output would necessitate >> a record change. >> >> Or what am I missing? >> > > https://tools.ietf.org/html/rfc6698#section-2.1.2 > > There are two main pubishers of TLSA records. Those who want an addotiona= l > non-CA third party certificate validator, and those who want to replace > the CA. > > For those replacing the CA, the only item of interest in the > certificate is the public key part. These people likely will > need to allow for CA's for the next little while, so they > will do the regular "renewing" of the certificate, but they > won't care to put any of that under TLSA verification, as > it is just a CA/PKIX place holder. > > Paul > --f46d043892ade8e9e70515e270b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If the DANE-EE entry has a SubjectPublicKeyInfo hash,= then the metadata within the certificate can be trusted only if the certif= icate signature is validated against a trust anchor: a self-signed certific= ate is sufficient (and probably ideal) here, since the client has already t= rusted the public key via DANE.

Absent signature verification, the c= lient should probably throw away the rest of the certificate to avoid the t= emptation of trusting any of it: it's simply unclear to me what are the= security=20 implications to the universe of clients of having unauthenticated data pres= ent=20 in the certificate or associated client context. What I mean is, what data = from certificates other than the public key modify clients' behaviors? = It may be "nothing" (i.e., that "the only item of interest i= n the certificate is the public key part"), but it's not clear to = me that this is the case.

Kyle

On Tue, May 12, 2015 at 8:52 AM, Paul W= outers <paul@nohats.ca> wrote:
On Tue, 12 May 2015, Kyle Rose wrote:

The draft statement that the record "need not change across certificat= e renewals with the same key" seems misleading. If
anything in the certificate changes=E2=80=94and typically the expiration da= te will change if a certificate is regenerated using
common tools, whether or not it is likely to be honored by a client=E2=80= =94the certificate digest will change. Since presumably the
TLSA record digest is of the entire certificate and not simply of the publi= c key, as the authenticity of much of the
metadata within the certificate is still of interest to clients, this means= the digest in the TLSA record will change.

It seems in fact that any renewal of the certificate producing anything oth= er than a bit-identical output would necessitate
a record change.

Or what am I missing?

https://tools.ietf.org/html/rfc6698#section-2.1.2

There are two main pubishers of TLSA records. Those who want an addotional<= br> non-CA third party certificate validator, and those who want to replace
the CA.

For those replacing the CA, the only item of interest in the
certificate is the public key part. These people likely will
need to allow for CA's for the next little while, so they
will do the regular "renewing" of the certificate, but they
won't care to put any of that under TLSA verification, as
it is just a CA/PKIX place holder.

Paul

--f46d043892ade8e9e70515e270b6-- From nobody Tue May 12 07:21:33 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061841B2D8C for ; Tue, 12 May 2015 07:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iy8h-C3ISAfF for ; Tue, 12 May 2015 07:21:31 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301581B2D88 for ; Tue, 12 May 2015 07:21:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lmLsh6XTTz568; Tue, 12 May 2015 16:21:28 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=MPmQ9+B5 X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id quZ5bCf2d8Id; Tue, 12 May 2015 16:21:22 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 12 May 2015 16:21:22 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8E69780043; Tue, 12 May 2015 10:21:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1431440481; bh=GxEeHX0nvthYK42wAWz5V0yKzMMe6Tq4YzXTwR8GsZI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MPmQ9+B5t7JrqSyJIB2MDlN0Bg5DDFFuG8SdkJjGVMDk1MxK7UNPdiAW9np2+SC2f aviNSK415ducL7KYDnG5pu5IPyXAb2OCiFAieUlK5rvcvDgrwavAyr8TI+tW2PgI2t vNu6GryXEv6/zYiWeoaqiLnkiq1RHs4Mjm4fDsxI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t4CELLn9015920; Tue, 12 May 2015 10:21:21 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 12 May 2015 10:21:21 -0400 (EDT) From: Paul Wouters To: Kyle Rose In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] "need not change across certificate renewals with the same key" X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2015 14:21:33 -0000 On Tue, 12 May 2015, Kyle Rose wrote: > If the DANE-EE entry has a SubjectPublicKeyInfo hash, then the metadata within the certificate can be trusted only if the certificate signature is validated against a trust anchor: a self-signed certificate is > sufficient (and probably ideal) here, since the client has already trusted the public key via DANE. None of the meta-data would be used and does not need to be trusted. > Absent signature verification, the client should probably throw away the rest of the certificate to avoid the temptation of trusting any of it: it's simply unclear to me what are the security implications to > the universe of clients of having unauthenticated data present in the certificate or associated client context. What I mean is, what data from certificates other than the public key modify clients' behaviors? > It may be "nothing" (i.e., that "the only item of interest in the certificate is the public key part"), but it's not clear to me that this is the case. Right. It should not be used and software needs to be updated to not use or display any of that information not covered by any assurance of PKIX or DANE. Paul From nobody Tue May 12 08:06:09 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E851B2E5A for ; Tue, 12 May 2015 08:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6F7rSba6CPy for ; Tue, 12 May 2015 08:06:05 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200131A895B for ; Tue, 12 May 2015 08:05:57 -0700 (PDT) Received: by wggj6 with SMTP id j6so13359024wgg.3 for ; Tue, 12 May 2015 08:05:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Bm7ah+BEMC2oLFWrdMHSNLkibmrr7OjdBkyObDFDMqY=; b=PJdeC1QpH0lICPuoJ4qHgnCkf9ANzp6b20a/dgjfjnzTCHgrOq8orPqyU+dZPds+LR Eg/s+xiGGRT7lDoqfQb7srTew9IkzxQyzfWS+AIilizZ+WSJd1Cr8CyQEktrl+h994lL waoBfJ2OMoEC2Q8e8ryYGidmK0HyJB65zJU8OolRZj/YI9VfvBqiSjpB6yhoo55N5JdR mvjdp682PfH31NbXkPHiMiQAkUyPDzB1fVyeXrb7F1AUocKWMZAgFREYhqLBj8UUHGdX hCMqkjU3ZyTTlzW2CxGWUjCVdAQbfzs3iAia8ZRTGMTR5eWOEbc0b2O1My0t7MJJSHg0 Vd+w== X-Gm-Message-State: ALoCoQl5zJ9Bdjz/+aLgd+hMAzUSBNR+4XIQSVW49ztYnag+VLWhOBlVqyiouq9Y3t64c6ZW3cqO MIME-Version: 1.0 X-Received: by 10.194.216.196 with SMTP id os4mr31541127wjc.117.1431443155620; Tue, 12 May 2015 08:05:55 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Tue, 12 May 2015 08:05:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 May 2015 17:05:55 +0200 Message-ID: From: Warren Kumari To: Jigar Joshi Content-Type: multipart/related; boundary=001a11c2902acf0bf40515e3d405 Archived-At: Cc: "" Subject: Re: [dane] trying to understand dane better X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2015 15:06:07 -0000 --001a11c2902acf0bf40515e3d405 Content-Type: multipart/alternative; boundary=001a11c2902acf0bf10515e3d404 --001a11c2902acf0bf10515e3d404 Content-Type: text/plain; charset=UTF-8 On Thu, May 7, 2015 at 2:45 AM, Jigar Joshi wrote: > I was using this https://www.dnssec-validator.cz/ > > > I got this icon > > [image: Inline image 2] > > for a local network url which is over http (no https support for that url) > however hovering over still says secured by dnssec > > my understanding is it compares the fingerprint of certificate with one > dnssec says to check identify of host > > https://www.dnssec-validator.cz/pages/documentation.html > > doesn't list this icon (in orange color specifically and hovering over > says secured by dnssec) > > if it is not using https how can it compare fingerprint ? > It isn't / it doesn't. I'm not 100% sure what the orange color means (and I don't have the plugin installed at the moment), but the first / "key" icon is only about DNSSEC. DNSSEC simply proves that the *DNS* data hasn't been changed ( actually that is a huge oversimplification, see : http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) The second icon (://, changes to a padlock) is the "DANE" icon. :// means: "For an existing domain name this means that no HTTPS secured connection to the remote server was established. Therefore, you can not perform TLSA record validation. The authenticity of TLS/SSL remote server certificate for the domain name could not be verified by DANE protocol because the connection to the remote server is not realized via HTTPS protocol." W > > > -- > -- > Jigar > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > -- 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. ---maf --001a11c2902acf0bf10515e3d404 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 7, 2015 at 2:45 AM, Jigar Joshi <jigarjm@gmail.com>= wrote:
I got this icon

3D"Inline

for a local network url which is over http (no https support for that = url) however hovering over still says secured by dnssec

my understanding is it compares the fingerprint of certifi= cate with one dnssec says to check identify of host

http= s://www.dnssec-validator.cz/pages/documentation.html

doesn't list this icon (in orange color specifically = and hovering over says secured by dnssec)

if it is not using https = how can it compare fingerprint ?

It isn't / it doesn't.=C2=A0

I'= m not 100% sure what the orange color means (and I don't have the plugi= n installed at the moment), but the first / "key" icon is only ab= out DNSSEC. DNSSEC simply proves that the *DNS* data hasn't been change= d ( actually that is a huge oversimplification, see : http://en.wikipe= dia.org/wiki/Domain_Name_System_Security_Extensions)=C2=A0

The second icon (://, changes to a padlock) is = the "DANE" icon. :// =C2=A0means:
"For an existing= domain name this means that no HTTPS secured connection to the remote serv= er was established. Therefore, you can not perform TLSA record validation. = The authenticity of TLS/SSL remote server certificate for the domain name c= ould not be verified by DANE protocol because the connection to the remote = server is not realized via HTTPS protocol."
=C2=A0
W


--
<= span style=3D"color:rgb(102,102,102);font-family:'courier new',mono= space">--
Jigar

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




--
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 p= articular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf
--001a11c2902acf0bf10515e3d404-- --001a11c2902acf0bf40515e3d405 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_14d2bd58a2dbe278 iVBORw0KGgoAAAANSUhEUgAAAIUAAAA9CAIAAAAMIT1zAAAKyWlDQ1BJQ0MgUHJvZmlsZQAASA2t lndU08kWx+f3S2+0hAhICb0J0gkgvYYiSAdRCUkgocQYCM2GyOIKrCgqImADF0UUXJUia0EsWFgE FLAvyKKgrosFUVF5P2CJe955+9+bnJn55Dt37tzfnDvnXADInWyRKBmWAyBFmCYO9nZjREZFM3C/ AwhgAAGoASs2J1XkGhTkD/61fehHrJF2x2TG17+a/e8FeS4vlQMAFIQsx3FTOSkIn0H6KY5InAYA io/o2hlpohkuQpgmRgJE+OAMJ8wxYg9ocXN8fdYmNNgdsXkEAJ7MZosTACCNIjojnZOA+CHjETYT cgVChJkIO3H4bC7CmQgvSklZPcOHETaI+4efhH8wmx0n9clmJ0h57luQncjBHoJUUTI7a/bP/3NI SZYg9zXbNJGRzBf7BCMzHbmzyqTVflIWxi0NnNcFyBfNM1/iEzbPnFR35C7n9nLZHn7zLEkKc51n thihv20EaazQeRavDpb6FyYvncmP2Rj4PJaUeameIfN6vMCLNc/Z/NCIeU4XhC+d59SkEGkM2Xx3 qS6WBEtjjhd7Sb8xJRXZ+fe5HPb3s9L4oT7zOpfn4TnPPGGYNB5RmpvUjyh5Nr9n4+cle0v11PQQ 6d40cahUT2T7zuTrrL0oLUh6J8ADeAJ/5McAYcACWAFzZAwAII2XieQdAO6rRVliQQI/jeGKvBQe gyXkmC5iWJiZWwMw8+5mbAB4d2/2PUF0/HdNhJxl54HkdPV3LU4FgGYkF5QJ3zWdIwDIRgLQlMOR iNPn/KFnJgwgAllAA8pAHWgDA2CCRGYDHIALErEvCAShIAqsBBzABylADDLAOrAJ5INCsB3sBuXg AKgGR8EJcAo0g3PgErgGboFu0AcegkEwAl6CcfABTEEQhIMoEBVShjQgXcgYsoCYkBPkCflDwVAU FAslQEJIAq2DNkOFUAlUDh2CaqFfoLPQJegG1APdh4agMegt9BlGwWSYBqvBevBimAm7wn5wKLwC ToDXwNlwHrwNLoOr4ONwE3wJvgX3wYPwS3gCBVAkFB2liTJBMVHuqEBUNCoeJUZtQBWgSlFVqHpU K6oDdQc1iHqF+oTGoqloBtoE7YD2QYehOeg16A3oInQ5+ii6CX0FfQc9hB5Hf8NQMKoYY4w9hoWJ xCRgMjD5mFJMDaYRcxXThxnBfMBisXSsPtYW64ONwiZi12KLsPuwDdg2bA92GDuBw+GUccY4R1wg jo1Lw+Xj9uKO4y7ienEjuI94El4Db4H3wkfjhfhcfCn+GP4Cvhf/HD9FkCPoEuwJgQQuIYtQTDhM aCXcJowQpojyRH2iIzGUmEjcRCwj1hOvEh8R35FIJC2SHWkZSUDKIZWRTpKuk4ZIn8gKZCOyOzmG LCFvIx8ht5Hvk99RKBQ9igslmpJG2UappVymPKF8lKHKmMqwZLgyG2UqZJpkemVeyxJkdWVdZVfK ZsuWyp6WvS37So4gpyfnLseW2yBXIXdWbkBuQp4qby4fKJ8iXyR/TP6G/KgCTkFPwVOBq5CnUK1w WWGYiqJqU92pHOpm6mHqVeoIDUvTp7FoibRC2glaF21cUUHRSjFcMVOxQvG84iAdRdejs+jJ9GL6 KXo//fMCtQWuC3gLti6oX9C7YFJpoZKLEk+pQKlBqU/pszJD2VM5SXmHcrPyYxW0ipHKMpUMlf0q V1VeLaQtdFjIWViw8NTCB6qwqpFqsOpa1WrVTtUJNXU1bzWR2l61y2qv1OnqLuqJ6rvUL6iPaVA1 nDQEGrs0Lmq8YCgyXBnJjDLGFca4pqqmj6ZE85Bml+aUlr5WmFauVoPWY22iNlM7XnuXdrv2uI6G ToDOOp06nQe6BF2mLl93j26H7qSevl6E3ha9Zr1RfSV9ln62fp3+IwOKgbPBGoMqg7uGWEOmYZLh PsNuI9jI2ohvVGF02xg2tjEWGO8z7lmEWWS3SLioatGACdnE1STdpM5kyJRu6m+aa9ps+nqxzuLo xTsWdyz+ZmZtlmx22OyhuYK5r3mueav5WwsjC45FhcVdS4qll+VGyxbLN1bGVjyr/Vb3rKnWAdZb rNutv9rY2oht6m3GbHVsY20rbQeYNGYQs4h53Q5j52a30e6c3Sd7G/s0+1P2fzmYOCQ5HHMYXaK/ hLfk8JJhRy1HtuMhx0EnhlOs00GnQWdNZ7ZzlfNTF20XrkuNy3NXQ9dE1+Our93M3MRujW6T7vbu 693bPFAe3h4FHl2eCp5hnuWeT7y0vBK86rzGva2913q3+WB8/Hx2+Ayw1FgcVi1r3NfWd73vFT+y X4hfud9TfyN/sX9rABzgG7Az4NFS3aXCpc2BIJAVuDPwcZB+0JqgX5dhlwUtq1j2LNg8eF1wRwg1 ZFXIsZAPoW6hxaEPwwzCJGHt4bLhMeG14ZMRHhElEYORiyPXR96KUokSRLVE46LDo2uiJ5Z7Lt+9 fCTGOiY/pn+F/orMFTdWqqxMXnl+lewq9qrTsZjYiNhjsV/Ygewq9kQcK64ybpzjztnDecl14e7i jvEceSW85/GO8SXxowmOCTsTxvjO/FL+K4G7oFzwJtEn8UDiZFJg0pGk6eSI5IYUfEpsylmhgjBJ eGW1+urM1T0iY1G+aHCN/Zrda8bFfuKaVCh1RWpLGg0pcDolBpIfJEPpTukV6R8zwjNOZ8pnCjM7 s4yytmY9z/bK/nktei1nbfs6zXWb1g2td11/aAO0IW5D+0btjXkbR3K8c45uIm5K2vRbrlluSe77 zRGbW/PU8nLyhn/w/qEuXyZfnD+wxWHLgR/RPwp+7NpquXXv1m8F3IKbhWaFpYVfijhFN38y/6ns p+lt8du6im2K92/Hbhdu79/hvONoiXxJdsnwzoCdTbsYuwp2vd+9aveNUqvSA3uIeyR7Bsv8y1r2 6uzdvvdLOb+8r8KtoqFStXJr5eQ+7r7e/S776w+oHSg88Pmg4OC9Q96Hmqr0qkqrsdXp1c8Ohx/u +Jn5c22NSk1hzdcjwiODR4OPXqm1ra09pnqsuA6uk9SNHY853n3C40RLvUn9oQZ6Q+FJcFJy8sUv sb/0n/I71X6aebr+jO6ZykZqY0ET1JTVNN7Mbx5siWrpOet7tr3VobXxV9Nfj5zTPFdxXvF88QXi hbwL0xezL060idpeXUq4NNy+qv3h5cjLd68su9J11e/q9Wte1y53uHZcvO54/dwN+xtnbzJvNt+y udXUad3Z+Jv1b41dNl1Nt21vt3Tbdbf2LOm50Ovce+mOx51rd1l3b/Ut7evpD+u/NxAzMHiPe2/0 fvL9Nw/SH0w9zHmEeVTwWO5x6RPVJ1W/G/7eMGgzeH7IY6jzacjTh8Oc4Zd/pP7xZSTvGeVZ6XON 57WjFqPnxrzGul8sfzHyUvRy6lX+n/J/Vr42eH3mL5e/Oscjx0feiN9Mvy16p/zuyHur9+0TQRNP PqR8mJos+Kj88egn5qeOzxGfn09lfMF9Kftq+LX1m9+3R9Mp09Mitpg9WwugkBGOjwfgLVInUKIA oHYDQJSZq4tnLaC5Wh5h6O8+I/8Xz9XOMwtIDQGq2wAIzQHAH5n3IrMe0mVdAAhCeqgLgC0tpR3M tdR4S4tZgkjNSGlSOj39DqkHcYYAfB2Ynp5qnp7+WoPUOg8AaPswV4/PWMsdB+BgtlmQnf+tgv45 R/8Y/wOOHgAVn32irQAAAn9pVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADx4OnhtcG1ldGEgeG1s bnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IlhNUCBDb3JlIDUuNC4wIj4KICAgPHJkZjpS REYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMj Ij4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6 ZXhpZj0iaHR0cDovL25zLmFkb2JlLmNvbS9leGlmLzEuMC8iCiAgICAgICAgICAgIHhtbG5zOnRp ZmY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vdGlmZi8xLjAvIj4KICAgICAgICAgPGV4aWY6UGl4ZWxZ RGltZW5zaW9uPjYxPC9leGlmOlBpeGVsWURpbWVuc2lvbj4KICAgICAgICAgPGV4aWY6UGl4ZWxY RGltZW5zaW9uPjEzMzwvZXhpZjpQaXhlbFhEaW1lbnNpb24+CiAgICAgICAgIDx0aWZmOkNvbXBy ZXNzaW9uPjE8L3RpZmY6Q29tcHJlc3Npb24+CiAgICAgICAgIDx0aWZmOk9yaWVudGF0aW9uPjE8 L3RpZmY6T3JpZW50YXRpb24+CiAgICAgICAgIDx0aWZmOlBob3RvbWV0cmljSW50ZXJwcmV0YXRp b24+MjwvdGlmZjpQaG90b21ldHJpY0ludGVycHJldGF0aW9uPgogICAgICA8L3JkZjpEZXNjcmlw dGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KKKF5aQAAJgdJREFUeAHtnHmYlNWVxr9a u6o3ugWkm0WhARdABGRRFlsRAyqgDGKiIupoRB01ipGYqBijRiRqnpiJycQoMcbdjHGJCgoKKCKE HcRGFkFoxG6g6bWqa5vf/d7qy0c3mkyeeeaPmdzHXM495z3vOXf97lddFd/dd98dCAQcx0m7xefz Iav4/f5UKkWNJRgMIlurXGhmMhlkAHKhCd66o5cXGEwUXJLJJE0xCwlMplAohFUMABQFkxdmqSQA pjQ3N1MrH1HRxAsMhOgpREGpVGkiy6QM0YCXHoyNAgwAnIwAegAI1CjVFKdqhUYvQcxQwSwNMlaK eoQXBVMikYAWwc8QoFIekmkqM9zQyxlq5WF8WnqOSWGAKQBNkCpYKYBVQw6MIQBJrfDIpEihKQAy ycGg0JYBAQ0FEzKOxKJGo2GlScEdDXqKYLZ3hEAJxrC4PNReWpcgIw2cQopEtMJLT7YoRS69ZLlj JRYAwAiYKBoWNGCkQZYePFaDRCUtDamyBr/fJkE8ivS2V/KiZm1SA7AZIBNSw6T88KUJwBC5SwwN XhSU1EpLTWT1RHqmBxdgUFGTAE0wsqpvShUlYDSY4FeTuMpc0eUIABLp0QgMCQWYamWO1WrQh8Nh mrjLahxcFymFxKTO0mSgFRElSDnSBWGIy+ghKxOsZo/gpqQlkygFmWJlTYN1w0QYxZASEqUuF5q4 kAFWClE1jugB4CiwrCjRoGc0Tf9cL5pEAUAtL3UMPU2rFJVqwPKlBkORC7VdDV6ZlIgIFXitaMmw 5eTkUMOAhogUb0RkNYmoKNRK1WaCRmmgJxB4BKJDJS8ALrE5ALEi4xv89NNPaSAJh4NkCTaYBJAU mSxSJm8wTAoGGDZkrCRHCDRKQnrVyhs9SDS4mzAtW0d4mqIF4xrNJNET9c0yi4HaC1ZThPBbQmmI LiUCbEoDE82CgoLS0lKoNJ2WE0F5ogeJTAi5wFBTU1NbWxuLxUSrWrFsYnKh6c3cNDdv3sw/rYoX BJGarTDf3FSvwNg8/ibnN0T5OpPlVJI2HONlNfRcTWv1Zg6DtylZOe/bt+/dd989cOBA+/btmRub gyZDixpywBQmhrJ3715OguOPP/64447r3Lkz08m2w3rEKN64FuPbtWuXTcKGlNCKRT7U4JUTAIo0 rQSawDBRJHvDW9nCBLa0amKlWBIE9NLYIbZU3kDCqLYA64veq2wli4dljsD4zp07t2vXrsh2SgiN CzUToA3KoVdfXw94wIABZ511Vn5+PlaiUATGXVHQWNnGRak9hMbcaqzh64RMOlW/4e30tkW+RBPM cJr/eWJkHVFlyMCXCUX9ZeX5/cb5/IeuesbmelGDb2pqos/0xBuU7pGPnpk2dSt4kZLbmkRukQpK 0wqSqS3Sa5IjGg10x44d0TATaEiMbPHShtMtRuPIZHBGTZ06tWfPnsCYAxW8bCBF8WoUy0ZUPuaR KxVt+dD0OtOsWfdm/o53fEEfaWbSGTOcbVaYocs47F4fK8Npznw+v85xigdOtGwIKkwDxytx8/Ly CESXKOoAJI2NjXV1dex0NDQp6oPNrYXm0L8yCUmNQRpqinDSt8UQGoCsltE6Kiv0TA8TQOaaG5oC g2RhsVGuvfbao446isnAhFIwaMWsGhebj40lk/TI5u74dSDLEqt4pzDqpNLZuwR4uVhfBDpGbSaF I5U15ffHK951Bk40KrfDAtCr6urqDh06xONxeiIeOyiag2g0WlVVBYbuyQsGTLYPVsBd/FYjwSrx UggvUrIwFkCzpQvZhIEpH7tkLbllY8ccPHjwwgsvVLbgKV9++WVFRcX+/fvBM0knnHBCSUkJss3K ypZHzNRmni3OCtYsIROvS4Ry/D765qTZA+6awpRdey2CbWLi2pGO1UNoQ5Io2VdWVvJ4ZH+gl0lr imXV0NDAQqOJO1tn9+7dHNxaiUpMeKWkWnqbthVaWeXoBaMBYzVr1649+eSTydA6YtIqoZaAC8kw N5jYKAJwTPXr169Hjx6csWYq/P4NGzZs3LgRa25uLrCv3NKnT5+TTjrJRlSUtk002X1nERKgs51H MOcQmyPgpFNxf9o8PRx/kJ1gLC1FLrQ40AJBc4N0T68sACS5fv755+RNH+TE0HPNp16xYgWPzZtv vpmbyWuvvfaXv/zl9ttvLyoq2rZtGxrAIofB8Lc8h0RiNV7B5m9SdENTA2BTrl69misM27SwsLBT p04MEzf+TZs2MR+WUFRq4qjnNpx0ivnQ9DDWLC9Mo0aNoguapz179nzyySfMxPDhw9kx+HIYLFu2 DCWrkBuXN0RbmRDmvGprgMh2iVHImEFIJuONvtyjnFA0E6t14rUIXsfs1DBX7glhkvYdtvM4glau XMn+5ThiVpiJo48+ms0O/xtvvLFo0aKZM2fSQ2RWK48QRo2ZAw/M5kNEm5iNbrtgBS/e5O92h8H6 4IMPmBKa+EJO9M8++0xNMVtONSGkIzYiSDKEkMJe4VHHcuFRx2SgAaaXByaDi4BoSZ4m92ZMXbp0 ET8mm2qriNn9IXOrzKzPnsoDifZ53c64Mnr8WU4gnKrdE1vzcmzbEn+As0UTYXYLT0ZmIZlK85FF POGrrmno5nk4bdmyhdXErJABnSkuLqYbO3fuJMq6det69erFecUG4uRlzXKs0VtMW7dupUtKWvkw iOvWrc/Lzwu4lzfbn2Qq2dDQOGjgAK6bQqoGgMCzavHixbyjcbawFdgchJs/fz4Tr15bsCW0QQFQ ADDodIG0pWFuSJvNockAzzODzaFbGXgKSjYKSj1OWpHbEFY4dE+Qs2qFpwZHXVWxrfv0nwT6TGiK 1UdDwUBRt9wzbtlX29C0e0MgFOGDAO5caR73fFBEvvFEKpZo3ldVUxfHHUKxsd7pCRqGhtMpEonM mjWL4eCFi1k59dRTef/Cm/N27NixWpXgeYpYErqN3K5du2O7d+f8hEHZoiQEtCWdSlitaioussqq VauYgLKystNPP1394phialvshkH8VmPJSYPEpNfRRBMrhBxBdjIAQEIRUoLSsLUwYqa2m0/6LfN/ fei8wl9u2Lz+NIu69c4tG7Rs9pU5zQf73/BotH1nnu0lZ89I1O/zBXjdIA+eKuThc5IJ8wISDB3c snrl3PvwpSg8z3DOKLLn5GWU2SLoeUiwFRjK/v37M9BLly4FwG3EdMv9wAcvuasW2zHdum7Zui3q 84fD2Zcnngc8sLp27YKXMAjWBZkppx48eLCsPLE4FQFYmCbDNoEJSW0nA7wKM2QOZHdxoNGU4MtD grdCFhZ7Aj0AlCw4Zo5nFU2K9JIVVHLjxmfPvOqnh57nwlm0FUBHSsqSjbWNGxelM4nYvt3RDryv psLRXP4Tl+pEMhEKhrgUp+Kx9sPG+15/Gj085ITAkDEHZMDD48Ybb+RzIbp0zDHHLFmyhHkaOHAg 5xKXE84xOgOYPjNzHPfeEBovOLt0Lt2z58t27QoFo8NdupinpU1bgsVz+iHrKEMYMmTI0KFDwQsg wQZCaWVLSPKCea1oAFgSPiZhPlhVep5jZW54aCHQU+ojFpchsfbN250TZ2f3hxgtr01CmvrKLUXd ep08fXYqVlfU2ywxntosj+Z4DHHNk7O69Ojt69J/yx/vOe786Vs/eKtdxOfvdlLTjk3i0SpgGjR2 1Aw9+Wnd8fDo3r07G4UTlmdM7969kemVNhBetsPa3eoSF+LcvFyeB9wOGhub8vLyEWz+wpg0W1YD U85bNAcU5NLL5F2hNpDcaVLIVoXFgaBtQY0MDE69uio0T+y+ffty333nnXd4ZqBk64tt/fr1PFcU XZrD6/j2lU6f8cdn9weBMbsJmNkmHona/jfs3la1Yl5p+XcAYAXJNeqvj9+Z3vVpJhBq2rFhx+p5 ST4jidV99sQd2A76fcmVC6Nhd/cAd29wPEJZ9TBAy9GvgWYOuNSOHj2abUE3uAKNGzdOpzMdJha9 pbbpqQ9qlpaUcGrxxymeW8cea1af9Ca9w89eIh577LGMCFfPc845RzBheCbzSJAvGgTbazWZBlaG wBoTNMIz4iTMQUSqmleYuSxwavFw0gMcKyuP0CydhQsX0lPGARiFQHiJmeEPFzifrNt+6LwiBkVm r4DMubTzlV/wQtFh2IRgTrSuek/Fq79pXPpyTiBID/JyGXdfOJPK5OUz8ubhDntuXrzJ/TuS+55C +G7dum3fvp3UmRW2MEfTxIkTmQyWGK9LZPbFF18wEzxITMRwmFEgY7xo2uyVGDXFcHbtsunTij4n niCNrTFJlkA9aNAgxoj9x8sNdweu0VwcPv74Y94PysvLec57XayXSDQmJEMhf6YQADKLHU774oIS JC68xlJsMgjsDCbDTol2iSajBZY/aOxk34zfmfNKRIoqRjTgVKMJR3L86eSul2bvXvh0OpTXXLM3 2LC/oKiIGQLovq6b9w7SwYtLkI//zAdw2c+oFZiDiMsr653+PP/88yAnT57MnkA48cQT6d7y5cux suU5rDhemA+eCpzIdhGBMbl6zmvOqJNO6sdnRpB487dNgWFgVZ533nmvvvoqU0KxYCaezQoAcmrr aMeBCaBgZRuhVA7UKOGkRySpK6842zKgZ/ezM7xTgga9IuJC6T35Bz/5cGi2J7TdnmZ7q6YNwK4K 5oT8Pt489jL+EY7OwnY80rOfRPLi7il4sXt5uvDRo+VBYI0wJTzfGPRLLrmEztANHrCTJk1iDvDi WnXxxRdzCJAlA00qPPN1lxc9GgSQakpmMpSnrKoxWbDVsNWmTZvGO+mOHTu4Z0NOYTuSD3g7NJYH QYWhx8oc6BFiOuiepTTJ9v333x8/fjwAwEpMQqsme4IpWbBgAbuEKyXzYQHycoJdrnp0t8/ewTF7 u6qmfJbMOLUownxwszX95BMRhiXL0vLPYe7cgH3OwXhy5MMfYYdW/WFnkBBrn+GmJ2TGlNA3PfTQ Q8JyQ48Xxxp/SwDQEiH7r1JqpVRTE9O2bgsWRnplbmmticOTTO6///7u3bsz9NKTD72gO7qMMJe8 ePNJOy+GdEQkIrTkNjoMfCjAZHAe2HDWKs2h9w8MXiKc0SiJYF67SLCZz9LRmFkxtsPmQ458qoXA A5aapRIImOe5K2Z5GHFexzi1ucUy3PSKDkOm5YZSYPpMb0Hay1Wr3CwtgjJE0EliTaKipghjkWAE s3orePXW1yrtNIBHpiZPtt2LL744ffp0runeKcELAEUJiIRdws5AtgUAssVkP9G0ZiVBMATVmDqO uIivkASCfj4opHe+ALdAvgJi/nM/8TRAs6eDZrJC4RBI3l+PHvltSLzMDBn3VD6A43GKXhuFvcK4 I3OOU8iPjEeOHMlRZnrj9kc8yk21TLJCZWFejGSsCLZGkGx9vTCLFD9IdoZOKjTIagKjzxTWEPlz qD777LMcg0wPMDdCtrKEVvBakdFbE0Lr+5XQNlc1y86+fLvPObDi1VTTQT4k5KlGTI00FMrgkIa5 yCkoHnZ+jzHT5K54ik3N8ufU5q2VvxNQc1hpadMxboo8YzRbdr1/XQ+VpKxKw8qK+3W1HLFawWYo F/QUEuD2hUZzIBNKbV9d/6jJn2ch6+mll17ikzdWEmsOQu0VeNqSQ9VKKXKj5wFrG0cU8IRUJq/s 1Vj914UBLBLVgslLsrVaBgQ7JTZWWx4c5UJtZeG99RFNR1QqBCYm4+233+ayx07VicrEMAHyomY3 8ywRHgzbhcHkHC4rK+NxwpsHnwDZE8ybTCsZKpHQBd+MGTMUgM5TIEVJYIioWQso0aiW0tIJJjyO 6C1MnNYR/aGQ7sCBlxIMMjsdAQwh0NNt7X2RoxQhtQRcNBaYbD5yV1DlIxi1hhLBBkWAChdiiYEm QSGkBgkPxz0LnyEWM7U1MTIAaMKDgBc8PN7JijcqPnbjKINQbOL3RkeDozS4kx4yJci7mBihBoRN OASlCyOC1WOliSdgWKxeTWrwKElOJvAqaMSDniJyK0AoNtdorBQ0sFEjI8ADPwUwsmpM8lVcWVFa AUJkkSOo4IJehICFwYRehGgYWS57HEfI6GVFoKChMGIKikYTw18TmCeujkyMRgAYjnBSAFOjUY1e IyMBPTxBXlOtljZ5Y9bY0RSU2vC5jNZZvDQR1FsACCwoCJWNNGAosKHXsKJHRgmMGpm9T81KhA2N AEpR/IyOOk/PbWJoAKNRwjQR4MEdLx30ACgoyQ1HTNTAqNVZrAokGIG4X4BHKUL4MeFIjUk81ABQ UiwtANzRyEpTiSEoAZr0UR2hBqxsAdA0eEVFS0Npwa5I1BJkoqYQjFpcAhAbdwXWsCo/+YLHRGBg DBACegSaFJriJEtIMCEoBBhpaErAytCgR8BXERHUPZRQgdRA08RRLtQU9BQpicK6kd4ON1bYhKFG LxlOYslkawUiIiRSoiET+G3BnQ5SY6JAIrzypBY/DLhAAiD7/qF4+IBQABA4UBDQIBBMKcpfGpuK GFEqKnr1Ew05wSxBgaAiEBq8lBN4RRRAJgJBogQ06CxPTAIrDdVgAGCiKQC0+CqQZPRmVFr6SBMv qHABJlmxwGClaHGQEnqadET7g6YtkIOHwXYTE02iU/BFT60cqAlHUAFAQotVEU1u/A839dCiESgo qXHAGR/lTY0LRYyCwQsYJMXKYABTwLCoKbhISURgmOgeWwoZPTCiiASTlHKhxgqGKBSa0igraqxo 8EWgxp0QCKpxUXSs0KIXlZDWRanSBI+JgowjgsIBwNHEdgvJKzSC8rcdkS/uJAAWK75SIlAIIQEG vMBQgzfTRYNaMgJu+FsQVpyZZNFRo5ESDE0V0cFOBrjjAgZOZAoYZDAU9DSBgWEBUgRwgQYJiXJl LNQfavl6Y4kEvZKHBw2c1HJXJjTlq2QYOwQ7lDIRGiWFJnjiihY2EYpEtcIBpqkaMDC5UFNESE1n wVslGrJCIz01sRSOGkLzhSJ6AgJGoARgOGx4aRRYmQFAiZdCohS1YtOEikIGeGkWBUaDLyYlRFOB +MgEvayQyFFNarIEj6BMQIIhCgWlAhEFQTlLqShatsgkgLvCeUOgUUrUuKsAQBCzarmIwasnB5r4 kgAhaMpR+ShhfOWixFAqCkpcbL9ogoQqyDUZiYIKKClaH5ogKDKBQQOFGNFLsGkJAIPyU0KaDMDA kKESGzVUKK2XNNRoxEkNhqKhhFAYsSErBwBkYsmBwYASd/TIglHjgtWmhAwAJHpFpAlMhDYWeEZJ XmQCIY5iE0a0+CIoeZaRkGhgRkZQGgCgUlBq4RHAQGsOL1RAlRBNCtSiU7rUEiCVlS2FC440UWJV fghMhgilhBYTkUBaFwSaGg45Wio1seJo8nMvNjTFhkDBRI0GgdrVmTQEllJ69Rxy9RYlMIp8cZQs NlkBo6SmSTKwKSXV4hEADTBCIAAWCSblQ/I6iGgiAxM/AIZIbJjkSxQFMhtW/uAoeFKrG/irWCVN 3JQxAo7kJyUu6CkiREAjDBpggFFSS4+SQGgUFACCMCitIxqboQS5UxMXpDKkSaEJBg1eYtPRgVJn MgACUWMFJjCxaCpDNBRplAy06j5NDkBMFJsVYEJwJQGmUUawDCDxpUlEXIhIIBVkl8lMNoJe2lCa azUUMgOV2dsxGxuBggk8XiD1ZTIbT75gEBQbGaSeAXSYjE1I99TWSNGEkJoCmLQQGDu8lAxNABSN l1UCJg31FgE9GJFIpql+gcQXpADkRtEQC4AeFzCWBFlg8cOACXIBaCJDQk1RJkoYQhwt/sI/vCAM tfFvqSVYDbTIpYHgb6+9wgRWf6ghVXIEE68E5UGtVDApG/APzJ7iBvpndYQRCN113hG0R1Kt6z2N PykxquZ+BUCjz3BTkBlo9JhpUqtJjYxeAOojMf9T94+MAEPp7jrHbGQGHQ6/P9Kx9Ggexw2NNfv2 1Wn/5rQvaV/gr9+7s6bRvBIKafaXu1fki/yPpPBPH88ImPlwz8DgZQPzf7u06ujBE6+ZfFqhRcQ3 3fuD5869855TOhgV07B92R9++af1fMrPrEhT2H/S1L6RcKiuOdHyCsbLTcCXTqLIPrss3xEFaP9f zCVfqeVjHvccOsI4sB94I3a3B8/U4BOLtsV6XXjL5NMylR/fO/uXG/dFj+k35IwBBQ2J5NZV8z/6 +J3VXxw8+/o5Fw0765inPqoMBpkSSN0jy72H+AP+TJIHInuMP9fWVdc0JZKhgvzcUHbTtBp07TCl pU1mU/TOjRcGQCYpvbBE9ebnFiQuvKiP/ekD1qo1H37Y0OuCEdnvy3oTOJzWxy8VSZ7vf9sQNpm/ JSSqqxsCgUh+caTl+xZtNS4HkxGJ0AEz4OaETx2oriNeTk4eP77lUOJ6w3U2nZefjpkXQX9NzBl5 xmkBp/KhWx5Zu5erW7pm5+o33lwai8SXzpu3pcb8eXLp6l18dbiknfnmh64cPEviSOb6D5v7nI/v nXPB0HYdx5R0Hte+4KYNMS6HpuSEQ8bMbPGKZP7/DbhDoePnPGTIiJgmhT+6ZwfLF2CYXBV1OOBO qy8QNFQtMMuW3LvumstXp+ENmp/2CL9rwe1TF+0Pmp+FUtixZn/73fAoXRTfleEXRabmn4rnH4hG RkRyhrv/3fDA0+v45SOlbuNraP74SfYLn07dJ1O+9dIBvp+/dfmUnPKuXc4tLRldOPgVwG01dRvf xjdQUB7IHeX3D/nViv2ZhsbaNUsuDQ5vXzL26JKx7YpHBke/XNvYxAdHzFbw2qvZIuYtsthfckK3 nGTFkqXNzfx9ke8SkLG98PH0DgSOv3Fqn8yuhfO+SEWPMh86MY0sQ1/Qn2r6PJXuxpccMslE1Yo3 f/T6lM0Nt5X5Dq5fu7tzTioR59IaiISDAT93bU4wfm0bSCf5+4CfUfI7LEt+NcCsJh1GmzHlpyOY mIJ0Mt6c9AfdWWMs+Xg+4IeuOe2P8HMqRHOTMGzREPfjNN+f4LteCf6uEOIrwn4ncnI/f4iYsVgi EMIhmIqbezYOfKuPj/PNNy78TnOCd7QQmlRDneO7euNX327XUL999YJRk6595YtHP/yR+zVlx7l6 0G+H13+vzBzS/L7DfLl7+W9uffOmn1X9bESkrnrz1lTEcZa20cQcPkzr+dbGR4eX5vJ8zuGnKntW jRz8/dBt9+29bVSHaKqueu/azXHzQObDKl4ATh3CdxLMumlmjQT5uZ/pIsuJVxsKE+UurnCm+OTv P/jdYw6uuueup/lFHCauWMwF1lQzHxvUMz3sEL55Eqva62RqqmtSTjBy3Mk9CnxpXzCz/PcP+X2D g+Fpzyw/yA08k2z+/MO3p4SHoQxH7l1dm9701JxrntrJQec4seeuvOmJTXGfE3tx+syf/3nR9aGh p8zZxNvIsrk/Ax8KT3t5db3ZLT5nxwevDvAP9vu+PeWG2b7T+QSeQyeuz6iRQ6y35h1zZ1yWGx0Z /ZfH1+xLL3/sh2PvW57IJGPxRMMn8wec+ftK84BjRVKz2eqcvkUdC3I7lHYacu4ln71y8bp7fr9G e8TYX/jOnL/yr1uIldhfzd/Wq+qSTqigQ98BnUJH0AjMj0PyC4oLitvlRYPO+nlPbfBNe20Wk4E1 UNCh88jhPYxovhvi8ELIUWNusInA/s0745EThg9z26x9dgQTZUDRgTNuuiB3w5+vuO1XX7h/hmTr MB+saJ485lZsljIr3xzEvSdeeX/5/OFdht3wqw8r00GOjq/e+c0Z1+ZuTvz1wJpLvlv+i81JJ1P5 Ya8z7un0+BP7GpdWbr+uV364uXHXuhre/sxqqF6/qraZhZyp2rvkRxc/OWrZy+9e12vP/P8YfV3u lsSK/aunXn7aQxt5Ou39+IQxD16+5I2mxkenlQ/E0RYzW5ScTqtn3VU54s7dlS/ce/Dxwd97r9fw 0967+5G/7qdTqYVzfhw4ZxA/TXC7KAdTs8jU6Hbm2HJn1YqtdVw1feV3rFz4/XX33PTEmrhjBo9V Hxp354Ojnp1TlnfZY29WmH13BI2Yljx019P33fvY/U+ubvLHl89bc8rPTidu6+I+5xOfbeW0wOQv DGcWL1zpOMf+4N+/3yfPfFXQX1A2esywUCwz/orxxc6eF19Y2qWs7Ljex+a7n0Jrqsx88IMo8yBM JZlh1n746Jvfemf5n275zS0ze+fPXnsgsfxPzziZDU/OeuzBJxc5zpZ9Tc7Wj/m64vk3X9a3OBrq UNq+XZgh4Mgyxx9EHD18kch8Jfhz54fz/n3q0O7FBc7K116E5Hezfj1n7nuQ7K1P71m13PHdfPXI klCoaPSkMZnFjJHZNC0D6svEvjx59pN3TD6hfVHnS2dclH7uK9+A4bOcrb+d/yXPhCnPZR74V/OV 7ZYZyU6DOc/MNuUvAaaK5gQdPnRf3NBz1IX/eVPg306du60uWHCU+fgg2nPEvJpXnvtp7xmTrmz3 b/N5orTVKJn+p/UdPqz/8P4lIR7pdb7DvgdngnAyBXwRw9m0YCGzwdgG77y6/IaH/nDvi/4ZF42Y +egIF+Wkqj6a3xAoNN8vLL3qJw+Cy2Tq//zTO5c3mQ9wCGZuArw5JhgHfhLFWc8HX6zx6KB/uTS5 t89lnb77zPLLh3JeTzz7wstO8cWSky73HRdxvmpucnyFOoqhNmcde6sgmMONwPHFNzgc+hzrHNId OubyY16+GMxg+yaMueDSQaHmMVOuifQqzvmy9qDTt5u7mHz8NkQJmwlpKUlE/kDk+MPRKPvUVXe4 +JmJfR74zzO37/BNuHskl3jzECWBNI8eHjCGhi/7BflFS2LPR+8vckb9sneeU+G6BoPn3/fUxY9O /faMr44q1ETS0U6Tbp2156wBpcN+/NGdZ51bGmilOd24jvrWuYP68cflaIR71MDJQ6753rI9tw44 whbhi6mvv5kOhjl4gjc+PI9TaNf7f7j+7ae79CiJ+hMN+3dV1ZFl6Oe3XsdXVyicUXzHi5Kfn/19 OJraNc/+/M3KZ4bf6svw1yqnuuLTvYU9+pZmnFSmnh8hRCNDJ0xJT1ha8/NxI8pCzbV1yXis2/Az nczMJ/88/o7ze8Sq9ztF7clg1XsVlVeUbnr83lsd5yF6kTaf1jXHGxPpaE4gdOrEizITP2r4xTmn 9Qwn6+v4Rm3HE/s7Gx58bXX5Bd0aH79rju/022KxOJdOVkkq0czDM5RTsPbX7234Trfjj2p696mn /Tc8zC9wis4eP/7Sa65Y7zy87Ef8jYFzBjyJx1JccKKZDY3762MBJ7Hz478MmPD78x+b2zuQoheU Zr7aGu7x8OIZnU9/xFfeP+gkKpZ/XnhiWWlBwN1IPYsj6Yrl2w7XmI88HKdyX1WsKT+drG0IFhb2 P+87zk0zJvyw5+t3lHeOBpoOVC5bceDUs/tEWJQJs5bdx3kmyLcCuU3xVsFd9mBV1VfxuN/P953D zAeDznObaTC7Aa37BQAGS/uDJlZkN7ZTtfSZIde/L7l85v3XDmtXlLnm3Ud+Mabnma5y1EdVswd0 HrHx9Rl9J1w2x6hGLa6a3W/s5L4z7uhaeH/5zJtv6LcYtmA4J9LB74M95Ge8Oo6Z/u4jj55VliVZ +tUDA/ue+ezMBZecMh6Ki68+xak1I5tNwh1lt1UxtXP5BhD9rlqzeKjRFPa9/u5er//kjAsGmG+z 2+I65jqZx44vfsxVjvrV289fdeYxWUBfc6ZTiode8Nbdr537PmJq2Z1XTF+U1f/ghT+eVpx6qrXG qTMXhq2jjxtrnB1nzEO/mzf9lD0f3HvNyB92nS2dM/CGB5eMyv4azxxWSp5f3jOsDLcOIv1hg6bp pFv09G5pZf+oAhgk3xV6/HfXZek5A2Lx+oZYJpxbzJtOS0k08c6SjhTkSgUPB1xtY7PV0KxrcszL UbYYCMPEcej+tMdEbkvSWFubCuUVRLUSjacWiltzjvJL7MSBA6m8ohxtHV4nHv/WuAVXP/f8RS1j 3RLvH/i3qa6uIZ7KySsqMA95U9pqUIbM9aRV0ftgwLwOtviCeL3skl7B0PNXTQ3y5S36wBZhVtgH bAv6r74xK9JgQkOhyUxQq2mGqmVpoglFI8WclYeXcG7UfCXEW4IhfvtxSBEK2xYk7sCaxeI+2bP8 MHseFcY1t/DQhzuiUiZubX4Wz2gUFx+KEqt4/8ZFZUv+9D8wGVBHGczDttkRNMqqTR0o7mB+wNiq aH8w4ObvUQwxBQTDQRPBDINbGHoKSi7BCGJh8tgcOtAsL3Ar/50C4ayXZJrulBgCa/o72b4ZFuk5 rqr6XPeXN98M/J+0Jlp+jv03Sd+adB7fJef10HzeTmEUmBIEPJE19GiQUdLkgovATHB8UTSLwrcN htffM5oWIzy1pbITI4zXZDH/PSEY+l+ejP9WeuovA252g1343s7bIcBKoQmaWZHQNpjFy9Sq2Rbv hSmuxahplVBZ2WL+7wksbkr2D5P0mUGnkxpH2382BDLTQA1AOwalmUn3ZPvu1b9GZsdQa9rEgwYq yyYl/MBErhqAmGEDg0xBqSZ4Nam9E0ATHrJXwjSFp8ZXPJgsCYIYvCY0iq6UFFS1+iJawWBAqRyI Kx5qNJJxRC9CwSTjqKYSoKYwgOipKWYO3Ic3MNPmtz0MN2b8UYGWQBgEACgBIDDEyBpo/YmbW7JS pymYGKTEXUUZY6KJiVjqiQbU9geBKDIpDWWFFwIa74iQhsYFWgpW0QJGjxWNlOiFwYTg9RKz3KkJ jRWlNyXLY5WWUHjbWZDK3zKgUWhoJVBrSLkioUSGjScx13tMOAa3bt2qIYYdGypYmAD5o6EICoCi YKrR4yu9ajTKDxKL0RxgAkMtE1YrS6BGKSsyRaMjpDRYKZZQJmqQlhyAwNQk73oYDYKlso7okYUR 2GsikLzsQtFoWH6sYmAcELAqDWRMkuVCUwI1MoQEIm1kvW8gG9M3/P8AKZJqnGGnIBCbRG3N5FkZ PUVIBOurTtL8/1YYbhU6rhFn0BEoTIlq9oeV/wtmXbOSc3g1+gAAAABJRU5ErkJggg== --001a11c2902acf0bf40515e3d405-- From nobody Tue May 12 09:29:38 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9111A9077 for ; Tue, 12 May 2015 09:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIo1-7fuuv94 for ; Tue, 12 May 2015 09:29:36 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFAF1A8FD6 for ; Tue, 12 May 2015 09:29:36 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 493D2283031; Tue, 12 May 2015 16:29:35 +0000 (UTC) Date: Tue, 12 May 2015 16:29:35 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150512162935.GN17272@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] "need not change across certificate renewals with the same key" X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 16:29:37 -0000 On Tue, May 12, 2015 at 08:46:54AM -0400, Kyle Rose wrote: > The draft statement that the record "need not change across certificate > renewals with the same key" seems misleading. This is taken out of context. The full text in Section 5.1 of draft-ietf-dane-ops is: TLSA records published for DANE servers SHOULD, as a best practice, be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE implementations are required to support SHA2-256, this record type works for all clients and need not change across certificate renewals with the same key. Thus the statement in question is specifically about "3 1 1" records, which bind *only* the key and not the rest of the certificate. > It seems in fact that any renewal of the certificate producing anything > other than a bit-identical output would necessitate a record change. > > Or what am I missing? With "3 1 1" the digest is a key digest, not a full certificate digest. -- Viktor. From nobody Tue May 12 22:48:02 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C882D1AC3D1 for ; Tue, 12 May 2015 22:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Bo-iooy906Z for ; Tue, 12 May 2015 22:47:59 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159111A0377 for ; Tue, 12 May 2015 22:47:59 -0700 (PDT) Received: by lagv1 with SMTP id v1so21428921lag.3 for ; Tue, 12 May 2015 22:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aNqjCe0ZVXCx6HnzCpZAXe4DMMC7XTugpifNXlXGqd0=; b=dqJyJ4mMYv3ek58LnvFew27qEjL9vW12CFK1DfEeEtWugKucPlv3NbETHk/2TI3KWD xR1txhVmAPj7UL3ase2ERwXy+L74O+YdVnNq+q8Dn+iA2wA1zTmuBkteoBP2WLpbnu0j /RwQ04Jo/AHOP7aZCDvIUr0fKHLjMKqWjjxefzL+O8fr5crLPb/FhaPGf6CRJYyRSlvQ MReJOhmyj73nP3EbrQJUR6u2l4uwa2TC4SYL61VqYsyHEgSefRA5kaeaptgvfyBCUb9o djaWswFs17Q122wbqygR+OEFnIIRS+5hFheHQq3NQmVxCb2OepuPnAwmevh4UyefAIJH bs/A== X-Received: by 10.152.116.49 with SMTP id jt17mr14613359lab.82.1431496077444; Tue, 12 May 2015 22:47:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.235.228 with HTTP; Tue, 12 May 2015 22:47:33 -0700 (PDT) In-Reply-To: References: From: Jigar Joshi Date: Tue, 12 May 2015 22:47:33 -0700 Message-ID: To: Warren Kumari Content-Type: multipart/related; boundary=001a11c3677e320a300515f02778 Archived-At: Cc: "" Subject: Re: [dane] trying to understand dane better X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 13 May 2015 05:48:02 -0000 --001a11c3677e320a300515f02778 Content-Type: multipart/alternative; boundary=001a11c3677e320a2c0515f02777 --001a11c3677e320a2c0515f02777 Content-Type: text/plain; charset=UTF-8 Hi Warren, How can it validate that dns data hasn't been modified if it doesn't have ssl certificate, what I understood was it checks finger print you get against the fingerprint it has published at dns to validate, however if the domain doesn't have ssl support at all how does it work ? please clarify if I totally misudnerstood this Thanks! Jigar On Tue, May 12, 2015 at 8:05 AM, Warren Kumari wrote: > > > On Thu, May 7, 2015 at 2:45 AM, Jigar Joshi wrote: > >> I was using this https://www.dnssec-validator.cz/ >> >> >> I got this icon >> >> [image: Inline image 2] >> >> for a local network url which is over http (no https support for that >> url) however hovering over still says secured by dnssec >> >> my understanding is it compares the fingerprint of certificate with one >> dnssec says to check identify of host >> >> https://www.dnssec-validator.cz/pages/documentation.html >> >> doesn't list this icon (in orange color specifically and hovering over >> says secured by dnssec) >> >> if it is not using https how can it compare fingerprint ? >> > > It isn't / it doesn't. > > I'm not 100% sure what the orange color means (and I don't have the plugin > installed at the moment), but the first / "key" icon is only about DNSSEC. > DNSSEC simply proves that the *DNS* data hasn't been changed ( actually > that is a huge oversimplification, see : > http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) > > > The second icon (://, changes to a padlock) is the "DANE" icon. :// means: > "For an existing domain name this means that no HTTPS secured connection > to the remote server was established. Therefore, you can not perform TLSA > record validation. The authenticity of TLS/SSL remote server certificate > for the domain name could not be verified by DANE protocol because the > connection to the remote server is not realized via HTTPS protocol." > > W > >> >> >> -- >> -- >> Jigar >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >> >> > > > -- > 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. > ---maf > -- -- Jigar --001a11c3677e320a2c0515f02777 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Warren,

How can it validate that dns data hasn't been modified if it doesn'= ;t have ssl certificate, what I understood was it checks finger print you g= et against the fingerprint it has published at dns to validate, however if = the domain doesn't have ssl support at all how does it work ? please cl= arify if I totally misudnerstood this

Thanks!
Jigar



On Tue, May 12, 2015 at 8:0= 5 AM, Warren Kumari <warren@kumari.net> wrote:


On Thu, May 7, 2015 at 2:45= AM, Jigar Joshi <jigarjm@gmail.com> wrote:
I got this icon

<= img alt=3D"Inline image 2" src=3D"cid:ii_14d2bd58a2dbe278" height=3D"61" wi= dth=3D"133">

for a local network url wh= ich is over http (no https support for that url) however hovering over stil= l says secured by dnssec

my understandi= ng is it compares the fingerprint of certificate with one dnssec says to ch= eck identify of host

https://www.dnssec-validator.cz/pag= es/documentation.html

doesn't l= ist this icon (in orange color specifically and hovering over says secured = by dnssec)

if it is not using https how can it compare fingerprint = ?

It isn't= / it doesn't.=C2=A0

I'm not 100% sure wha= t the orange color means (and I don't have the plugin installed at the = moment), but the first / "key" icon is only about DNSSEC. DNSSEC = simply proves that the *DNS* data hasn't been changed ( actually that i= s a huge oversimplification, see : http://en.wikiped= ia.org/wiki/Domain_Name_System_Security_Extensions)=C2=A0

The second icon (://, changes to a padlock) is t= he "DANE" icon. :// =C2=A0means:
"For an existing = domain name this means that no HTTPS secured connection to the remote serve= r was established. Therefore, you can not perform TLSA record validation. T= he authenticity of TLS/SSL remote server certificate for the domain name co= uld not be verified by DANE protocol because the connection to the remote s= erver is not realized via HTTPS protocol."
=C2=A0
= W


--
--
Jigar

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




--
I don't think= the execution is relevant when it was obviously a bad idea in the first pl= ace.
This is like putting rabid weasels in your pants, and later express= ing regret at having chosen those particular rabid weasels and that pair of= pants.
=C2=A0 =C2=A0---maf



--
--
Jigar
--001a11c3677e320a2c0515f02777-- --001a11c3677e320a300515f02778 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_14d2bd58a2dbe278 iVBORw0KGgoAAAANSUhEUgAAAIUAAAA9CAIAAAAMIT1zAAAKyWlDQ1BJQ0MgUHJvZmlsZQAASA2t lndU08kWx+f3S2+0hAhICb0J0gkgvYYiSAdRCUkgocQYCM2GyOIKrCgqImADF0UUXJUia0EsWFgE FLAvyKKgrosFUVF5P2CJe955+9+bnJn55Dt37tzfnDvnXADInWyRKBmWAyBFmCYO9nZjREZFM3C/ AwhgAAGoASs2J1XkGhTkD/61fehHrJF2x2TG17+a/e8FeS4vlQMAFIQsx3FTOSkIn0H6KY5InAYA io/o2hlpohkuQpgmRgJE+OAMJ8wxYg9ocXN8fdYmNNgdsXkEAJ7MZosTACCNIjojnZOA+CHjETYT cgVChJkIO3H4bC7CmQgvSklZPcOHETaI+4efhH8wmx0n9clmJ0h57luQncjBHoJUUTI7a/bP/3NI SZYg9zXbNJGRzBf7BCMzHbmzyqTVflIWxi0NnNcFyBfNM1/iEzbPnFR35C7n9nLZHn7zLEkKc51n thihv20EaazQeRavDpb6FyYvncmP2Rj4PJaUeameIfN6vMCLNc/Z/NCIeU4XhC+d59SkEGkM2Xx3 qS6WBEtjjhd7Sb8xJRXZ+fe5HPb3s9L4oT7zOpfn4TnPPGGYNB5RmpvUjyh5Nr9n4+cle0v11PQQ 6d40cahUT2T7zuTrrL0oLUh6J8ADeAJ/5McAYcACWAFzZAwAII2XieQdAO6rRVliQQI/jeGKvBQe gyXkmC5iWJiZWwMw8+5mbAB4d2/2PUF0/HdNhJxl54HkdPV3LU4FgGYkF5QJ3zWdIwDIRgLQlMOR iNPn/KFnJgwgAllAA8pAHWgDA2CCRGYDHIALErEvCAShIAqsBBzABylADDLAOrAJ5INCsB3sBuXg AKgGR8EJcAo0g3PgErgGboFu0AcegkEwAl6CcfABTEEQhIMoEBVShjQgXcgYsoCYkBPkCflDwVAU FAslQEJIAq2DNkOFUAlUDh2CaqFfoLPQJegG1APdh4agMegt9BlGwWSYBqvBevBimAm7wn5wKLwC ToDXwNlwHrwNLoOr4ONwE3wJvgX3wYPwS3gCBVAkFB2liTJBMVHuqEBUNCoeJUZtQBWgSlFVqHpU K6oDdQc1iHqF+oTGoqloBtoE7YD2QYehOeg16A3oInQ5+ii6CX0FfQc9hB5Hf8NQMKoYY4w9hoWJ xCRgMjD5mFJMDaYRcxXThxnBfMBisXSsPtYW64ONwiZi12KLsPuwDdg2bA92GDuBw+GUccY4R1wg jo1Lw+Xj9uKO4y7ienEjuI94El4Db4H3wkfjhfhcfCn+GP4Cvhf/HD9FkCPoEuwJgQQuIYtQTDhM aCXcJowQpojyRH2iIzGUmEjcRCwj1hOvEh8R35FIJC2SHWkZSUDKIZWRTpKuk4ZIn8gKZCOyOzmG LCFvIx8ht5Hvk99RKBQ9igslmpJG2UappVymPKF8lKHKmMqwZLgyG2UqZJpkemVeyxJkdWVdZVfK ZsuWyp6WvS37So4gpyfnLseW2yBXIXdWbkBuQp4qby4fKJ8iXyR/TP6G/KgCTkFPwVOBq5CnUK1w WWGYiqJqU92pHOpm6mHqVeoIDUvTp7FoibRC2glaF21cUUHRSjFcMVOxQvG84iAdRdejs+jJ9GL6 KXo//fMCtQWuC3gLti6oX9C7YFJpoZKLEk+pQKlBqU/pszJD2VM5SXmHcrPyYxW0ipHKMpUMlf0q V1VeLaQtdFjIWViw8NTCB6qwqpFqsOpa1WrVTtUJNXU1bzWR2l61y2qv1OnqLuqJ6rvUL6iPaVA1 nDQEGrs0Lmq8YCgyXBnJjDLGFca4pqqmj6ZE85Bml+aUlr5WmFauVoPWY22iNlM7XnuXdrv2uI6G ToDOOp06nQe6BF2mLl93j26H7qSevl6E3ha9Zr1RfSV9ln62fp3+IwOKgbPBGoMqg7uGWEOmYZLh PsNuI9jI2ohvVGF02xg2tjEWGO8z7lmEWWS3SLioatGACdnE1STdpM5kyJRu6m+aa9ps+nqxzuLo xTsWdyz+ZmZtlmx22OyhuYK5r3mueav5WwsjC45FhcVdS4qll+VGyxbLN1bGVjyr/Vb3rKnWAdZb rNutv9rY2oht6m3GbHVsY20rbQeYNGYQs4h53Q5j52a30e6c3Sd7G/s0+1P2fzmYOCQ5HHMYXaK/ hLfk8JJhRy1HtuMhx0EnhlOs00GnQWdNZ7ZzlfNTF20XrkuNy3NXQ9dE1+Our93M3MRujW6T7vbu 693bPFAe3h4FHl2eCp5hnuWeT7y0vBK86rzGva2913q3+WB8/Hx2+Ayw1FgcVi1r3NfWd73vFT+y X4hfud9TfyN/sX9rABzgG7Az4NFS3aXCpc2BIJAVuDPwcZB+0JqgX5dhlwUtq1j2LNg8eF1wRwg1 ZFXIsZAPoW6hxaEPwwzCJGHt4bLhMeG14ZMRHhElEYORiyPXR96KUokSRLVE46LDo2uiJ5Z7Lt+9 fCTGOiY/pn+F/orMFTdWqqxMXnl+lewq9qrTsZjYiNhjsV/Ygewq9kQcK64ybpzjztnDecl14e7i jvEceSW85/GO8SXxowmOCTsTxvjO/FL+K4G7oFzwJtEn8UDiZFJg0pGk6eSI5IYUfEpsylmhgjBJ eGW1+urM1T0iY1G+aHCN/Zrda8bFfuKaVCh1RWpLGg0pcDolBpIfJEPpTukV6R8zwjNOZ8pnCjM7 s4yytmY9z/bK/nktei1nbfs6zXWb1g2td11/aAO0IW5D+0btjXkbR3K8c45uIm5K2vRbrlluSe77 zRGbW/PU8nLyhn/w/qEuXyZfnD+wxWHLgR/RPwp+7NpquXXv1m8F3IKbhWaFpYVfijhFN38y/6ns p+lt8du6im2K92/Hbhdu79/hvONoiXxJdsnwzoCdTbsYuwp2vd+9aveNUqvSA3uIeyR7Bsv8y1r2 6uzdvvdLOb+8r8KtoqFStXJr5eQ+7r7e/S776w+oHSg88Pmg4OC9Q96Hmqr0qkqrsdXp1c8Ohx/u +Jn5c22NSk1hzdcjwiODR4OPXqm1ra09pnqsuA6uk9SNHY853n3C40RLvUn9oQZ6Q+FJcFJy8sUv sb/0n/I71X6aebr+jO6ZykZqY0ET1JTVNN7Mbx5siWrpOet7tr3VobXxV9Nfj5zTPFdxXvF88QXi hbwL0xezL060idpeXUq4NNy+qv3h5cjLd68su9J11e/q9Wte1y53uHZcvO54/dwN+xtnbzJvNt+y udXUad3Z+Jv1b41dNl1Nt21vt3Tbdbf2LOm50Ovce+mOx51rd1l3b/Ut7evpD+u/NxAzMHiPe2/0 fvL9Nw/SH0w9zHmEeVTwWO5x6RPVJ1W/G/7eMGgzeH7IY6jzacjTh8Oc4Zd/pP7xZSTvGeVZ6XON 57WjFqPnxrzGul8sfzHyUvRy6lX+n/J/Vr42eH3mL5e/Oscjx0feiN9Mvy16p/zuyHur9+0TQRNP PqR8mJos+Kj88egn5qeOzxGfn09lfMF9Kftq+LX1m9+3R9Mp09Mitpg9WwugkBGOjwfgLVInUKIA oHYDQJSZq4tnLaC5Wh5h6O8+I/8Xz9XOMwtIDQGq2wAIzQHAH5n3IrMe0mVdAAhCeqgLgC0tpR3M tdR4S4tZgkjNSGlSOj39DqkHcYYAfB2Ynp5qnp7+WoPUOg8AaPswV4/PWMsdB+BgtlmQnf+tgv45 R/8Y/wOOHgAVn32irQAAAn9pVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADx4OnhtcG1ldGEgeG1s bnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IlhNUCBDb3JlIDUuNC4wIj4KICAgPHJkZjpS REYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMj Ij4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6 ZXhpZj0iaHR0cDovL25zLmFkb2JlLmNvbS9leGlmLzEuMC8iCiAgICAgICAgICAgIHhtbG5zOnRp ZmY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vdGlmZi8xLjAvIj4KICAgICAgICAgPGV4aWY6UGl4ZWxZ RGltZW5zaW9uPjYxPC9leGlmOlBpeGVsWURpbWVuc2lvbj4KICAgICAgICAgPGV4aWY6UGl4ZWxY RGltZW5zaW9uPjEzMzwvZXhpZjpQaXhlbFhEaW1lbnNpb24+CiAgICAgICAgIDx0aWZmOkNvbXBy ZXNzaW9uPjE8L3RpZmY6Q29tcHJlc3Npb24+CiAgICAgICAgIDx0aWZmOk9yaWVudGF0aW9uPjE8 L3RpZmY6T3JpZW50YXRpb24+CiAgICAgICAgIDx0aWZmOlBob3RvbWV0cmljSW50ZXJwcmV0YXRp b24+MjwvdGlmZjpQaG90b21ldHJpY0ludGVycHJldGF0aW9uPgogICAgICA8L3JkZjpEZXNjcmlw dGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KKKF5aQAAJgdJREFUeAHtnHmYlNWVxr9a u6o3ugWkm0WhARdABGRRFlsRAyqgDGKiIupoRB01ipGYqBijRiRqnpiJycQoMcbdjHGJCgoKKCKE HcRGFkFoxG6g6bWqa5vf/d7qy0c3mkyeeeaPmdzHXM495z3vOXf97lddFd/dd98dCAQcx0m7xefz Iav4/f5UKkWNJRgMIlurXGhmMhlkAHKhCd66o5cXGEwUXJLJJE0xCwlMplAohFUMABQFkxdmqSQA pjQ3N1MrH1HRxAsMhOgpREGpVGkiy6QM0YCXHoyNAgwAnIwAegAI1CjVFKdqhUYvQcxQwSwNMlaK eoQXBVMikYAWwc8QoFIekmkqM9zQyxlq5WF8WnqOSWGAKQBNkCpYKYBVQw6MIQBJrfDIpEihKQAy ycGg0JYBAQ0FEzKOxKJGo2GlScEdDXqKYLZ3hEAJxrC4PNReWpcgIw2cQopEtMJLT7YoRS69ZLlj JRYAwAiYKBoWNGCkQZYePFaDRCUtDamyBr/fJkE8ivS2V/KiZm1SA7AZIBNSw6T88KUJwBC5SwwN XhSU1EpLTWT1RHqmBxdgUFGTAE0wsqpvShUlYDSY4FeTuMpc0eUIABLp0QgMCQWYamWO1WrQh8Nh mrjLahxcFymFxKTO0mSgFRElSDnSBWGIy+ghKxOsZo/gpqQlkygFmWJlTYN1w0QYxZASEqUuF5q4 kAFWClE1jugB4CiwrCjRoGc0Tf9cL5pEAUAtL3UMPU2rFJVqwPKlBkORC7VdDV6ZlIgIFXitaMmw 5eTkUMOAhogUb0RkNYmoKNRK1WaCRmmgJxB4BKJDJS8ALrE5ALEi4xv89NNPaSAJh4NkCTaYBJAU mSxSJm8wTAoGGDZkrCRHCDRKQnrVyhs9SDS4mzAtW0d4mqIF4xrNJNET9c0yi4HaC1ZThPBbQmmI LiUCbEoDE82CgoLS0lKoNJ2WE0F5ogeJTAi5wFBTU1NbWxuLxUSrWrFsYnKh6c3cNDdv3sw/rYoX BJGarTDf3FSvwNg8/ibnN0T5OpPlVJI2HONlNfRcTWv1Zg6DtylZOe/bt+/dd989cOBA+/btmRub gyZDixpywBQmhrJ3715OguOPP/64447r3Lkz08m2w3rEKN64FuPbtWuXTcKGlNCKRT7U4JUTAIo0 rQSawDBRJHvDW9nCBLa0amKlWBIE9NLYIbZU3kDCqLYA64veq2wli4dljsD4zp07t2vXrsh2SgiN CzUToA3KoVdfXw94wIABZ511Vn5+PlaiUATGXVHQWNnGRak9hMbcaqzh64RMOlW/4e30tkW+RBPM cJr/eWJkHVFlyMCXCUX9ZeX5/cb5/IeuesbmelGDb2pqos/0xBuU7pGPnpk2dSt4kZLbmkRukQpK 0wqSqS3Sa5IjGg10x44d0TATaEiMbPHShtMtRuPIZHBGTZ06tWfPnsCYAxW8bCBF8WoUy0ZUPuaR KxVt+dD0OtOsWfdm/o53fEEfaWbSGTOcbVaYocs47F4fK8Npznw+v85xigdOtGwIKkwDxytx8/Ly CESXKOoAJI2NjXV1dex0NDQp6oPNrYXm0L8yCUmNQRpqinDSt8UQGoCsltE6Kiv0TA8TQOaaG5oC g2RhsVGuvfbao446isnAhFIwaMWsGhebj40lk/TI5u74dSDLEqt4pzDqpNLZuwR4uVhfBDpGbSaF I5U15ffHK951Bk40KrfDAtCr6urqDh06xONxeiIeOyiag2g0WlVVBYbuyQsGTLYPVsBd/FYjwSrx UggvUrIwFkCzpQvZhIEpH7tkLbllY8ccPHjwwgsvVLbgKV9++WVFRcX+/fvBM0knnHBCSUkJss3K ypZHzNRmni3OCtYsIROvS4Ry/D765qTZA+6awpRdey2CbWLi2pGO1UNoQ5Io2VdWVvJ4ZH+gl0lr imXV0NDAQqOJO1tn9+7dHNxaiUpMeKWkWnqbthVaWeXoBaMBYzVr1649+eSTydA6YtIqoZaAC8kw N5jYKAJwTPXr169Hjx6csWYq/P4NGzZs3LgRa25uLrCv3NKnT5+TTjrJRlSUtk002X1nERKgs51H MOcQmyPgpFNxf9o8PRx/kJ1gLC1FLrQ40AJBc4N0T68sACS5fv755+RNH+TE0HPNp16xYgWPzZtv vpmbyWuvvfaXv/zl9ttvLyoq2rZtGxrAIofB8Lc8h0RiNV7B5m9SdENTA2BTrl69misM27SwsLBT p04MEzf+TZs2MR+WUFRq4qjnNpx0ivnQ9DDWLC9Mo0aNoguapz179nzyySfMxPDhw9kx+HIYLFu2 DCWrkBuXN0RbmRDmvGprgMh2iVHImEFIJuONvtyjnFA0E6t14rUIXsfs1DBX7glhkvYdtvM4glau XMn+5ThiVpiJo48+ms0O/xtvvLFo0aKZM2fSQ2RWK48QRo2ZAw/M5kNEm5iNbrtgBS/e5O92h8H6 4IMPmBKa+EJO9M8++0xNMVtONSGkIzYiSDKEkMJe4VHHcuFRx2SgAaaXByaDi4BoSZ4m92ZMXbp0 ET8mm2qriNn9IXOrzKzPnsoDifZ53c64Mnr8WU4gnKrdE1vzcmzbEn+As0UTYXYLT0ZmIZlK85FF POGrrmno5nk4bdmyhdXErJABnSkuLqYbO3fuJMq6det69erFecUG4uRlzXKs0VtMW7dupUtKWvkw iOvWrc/Lzwu4lzfbn2Qq2dDQOGjgAK6bQqoGgMCzavHixbyjcbawFdgchJs/fz4Tr15bsCW0QQFQ ADDodIG0pWFuSJvNockAzzODzaFbGXgKSjYKSj1OWpHbEFY4dE+Qs2qFpwZHXVWxrfv0nwT6TGiK 1UdDwUBRt9wzbtlX29C0e0MgFOGDAO5caR73fFBEvvFEKpZo3ldVUxfHHUKxsd7pCRqGhtMpEonM mjWL4eCFi1k59dRTef/Cm/N27NixWpXgeYpYErqN3K5du2O7d+f8hEHZoiQEtCWdSlitaioussqq VauYgLKystNPP1394phialvshkH8VmPJSYPEpNfRRBMrhBxBdjIAQEIRUoLSsLUwYqa2m0/6LfN/ fei8wl9u2Lz+NIu69c4tG7Rs9pU5zQf73/BotH1nnu0lZ89I1O/zBXjdIA+eKuThc5IJ8wISDB3c snrl3PvwpSg8z3DOKLLn5GWU2SLoeUiwFRjK/v37M9BLly4FwG3EdMv9wAcvuasW2zHdum7Zui3q 84fD2Zcnngc8sLp27YKXMAjWBZkppx48eLCsPLE4FQFYmCbDNoEJSW0nA7wKM2QOZHdxoNGU4MtD grdCFhZ7Aj0AlCw4Zo5nFU2K9JIVVHLjxmfPvOqnh57nwlm0FUBHSsqSjbWNGxelM4nYvt3RDryv psLRXP4Tl+pEMhEKhrgUp+Kx9sPG+15/Gj085ITAkDEHZMDD48Ybb+RzIbp0zDHHLFmyhHkaOHAg 5xKXE84xOgOYPjNzHPfeEBovOLt0Lt2z58t27QoFo8NdupinpU1bgsVz+iHrKEMYMmTI0KFDwQsg wQZCaWVLSPKCea1oAFgSPiZhPlhVep5jZW54aCHQU+ojFpchsfbN250TZ2f3hxgtr01CmvrKLUXd ep08fXYqVlfU2ywxntosj+Z4DHHNk7O69Ojt69J/yx/vOe786Vs/eKtdxOfvdlLTjk3i0SpgGjR2 1Aw9+Wnd8fDo3r07G4UTlmdM7969kemVNhBetsPa3eoSF+LcvFyeB9wOGhub8vLyEWz+wpg0W1YD U85bNAcU5NLL5F2hNpDcaVLIVoXFgaBtQY0MDE69uio0T+y+ffty333nnXd4ZqBk64tt/fr1PFcU XZrD6/j2lU6f8cdn9weBMbsJmNkmHona/jfs3la1Yl5p+XcAYAXJNeqvj9+Z3vVpJhBq2rFhx+p5 ST4jidV99sQd2A76fcmVC6Nhd/cAd29wPEJZ9TBAy9GvgWYOuNSOHj2abUE3uAKNGzdOpzMdJha9 pbbpqQ9qlpaUcGrxxymeW8cea1af9Ca9w89eIh577LGMCFfPc845RzBheCbzSJAvGgTbazWZBlaG wBoTNMIz4iTMQUSqmleYuSxwavFw0gMcKyuP0CydhQsX0lPGARiFQHiJmeEPFzifrNt+6LwiBkVm r4DMubTzlV/wQtFh2IRgTrSuek/Fq79pXPpyTiBID/JyGXdfOJPK5OUz8ubhDntuXrzJ/TuS+55C +G7dum3fvp3UmRW2MEfTxIkTmQyWGK9LZPbFF18wEzxITMRwmFEgY7xo2uyVGDXFcHbtsunTij4n niCNrTFJlkA9aNAgxoj9x8sNdweu0VwcPv74Y94PysvLec57XayXSDQmJEMhf6YQADKLHU774oIS JC68xlJsMgjsDCbDTol2iSajBZY/aOxk34zfmfNKRIoqRjTgVKMJR3L86eSul2bvXvh0OpTXXLM3 2LC/oKiIGQLovq6b9w7SwYtLkI//zAdw2c+oFZiDiMsr653+PP/88yAnT57MnkA48cQT6d7y5cux suU5rDhemA+eCpzIdhGBMbl6zmvOqJNO6sdnRpB487dNgWFgVZ533nmvvvoqU0KxYCaezQoAcmrr aMeBCaBgZRuhVA7UKOGkRySpK6842zKgZ/ezM7xTgga9IuJC6T35Bz/5cGi2J7TdnmZ7q6YNwK4K 5oT8Pt489jL+EY7OwnY80rOfRPLi7il4sXt5uvDRo+VBYI0wJTzfGPRLLrmEztANHrCTJk1iDvDi WnXxxRdzCJAlA00qPPN1lxc9GgSQakpmMpSnrKoxWbDVsNWmTZvGO+mOHTu4Z0NOYTuSD3g7NJYH QYWhx8oc6BFiOuiepTTJ9v333x8/fjwAwEpMQqsme4IpWbBgAbuEKyXzYQHycoJdrnp0t8/ewTF7 u6qmfJbMOLUownxwszX95BMRhiXL0vLPYe7cgH3OwXhy5MMfYYdW/WFnkBBrn+GmJ2TGlNA3PfTQ Q8JyQ48Xxxp/SwDQEiH7r1JqpVRTE9O2bgsWRnplbmmticOTTO6///7u3bsz9NKTD72gO7qMMJe8 ePNJOy+GdEQkIrTkNjoMfCjAZHAe2HDWKs2h9w8MXiKc0SiJYF67SLCZz9LRmFkxtsPmQ458qoXA A5aapRIImOe5K2Z5GHFexzi1ucUy3PSKDkOm5YZSYPpMb0Hay1Wr3CwtgjJE0EliTaKipghjkWAE s3orePXW1yrtNIBHpiZPtt2LL744ffp0runeKcELAEUJiIRdws5AtgUAssVkP9G0ZiVBMATVmDqO uIivkASCfj4opHe+ALdAvgJi/nM/8TRAs6eDZrJC4RBI3l+PHvltSLzMDBn3VD6A43GKXhuFvcK4 I3OOU8iPjEeOHMlRZnrj9kc8yk21TLJCZWFejGSsCLZGkGx9vTCLFD9IdoZOKjTIagKjzxTWEPlz qD777LMcg0wPMDdCtrKEVvBakdFbE0Lr+5XQNlc1y86+fLvPObDi1VTTQT4k5KlGTI00FMrgkIa5 yCkoHnZ+jzHT5K54ik3N8ufU5q2VvxNQc1hpadMxboo8YzRbdr1/XQ+VpKxKw8qK+3W1HLFawWYo F/QUEuD2hUZzIBNKbV9d/6jJn2ch6+mll17ikzdWEmsOQu0VeNqSQ9VKKXKj5wFrG0cU8IRUJq/s 1Vj914UBLBLVgslLsrVaBgQ7JTZWWx4c5UJtZeG99RFNR1QqBCYm4+233+ayx07VicrEMAHyomY3 8ywRHgzbhcHkHC4rK+NxwpsHnwDZE8ybTCsZKpHQBd+MGTMUgM5TIEVJYIioWQso0aiW0tIJJjyO 6C1MnNYR/aGQ7sCBlxIMMjsdAQwh0NNt7X2RoxQhtQRcNBaYbD5yV1DlIxi1hhLBBkWAChdiiYEm QSGkBgkPxz0LnyEWM7U1MTIAaMKDgBc8PN7JijcqPnbjKINQbOL3RkeDozS4kx4yJci7mBihBoRN OASlCyOC1WOliSdgWKxeTWrwKElOJvAqaMSDniJyK0AoNtdorBQ0sFEjI8ADPwUwsmpM8lVcWVFa AUJkkSOo4IJehICFwYRehGgYWS57HEfI6GVFoKChMGIKikYTw18TmCeujkyMRgAYjnBSAFOjUY1e IyMBPTxBXlOtljZ5Y9bY0RSU2vC5jNZZvDQR1FsACCwoCJWNNGAosKHXsKJHRgmMGpm9T81KhA2N AEpR/IyOOk/PbWJoAKNRwjQR4MEdLx30ACgoyQ1HTNTAqNVZrAokGIG4X4BHKUL4MeFIjUk81ABQ UiwtANzRyEpTiSEoAZr0UR2hBqxsAdA0eEVFS0Npwa5I1BJkoqYQjFpcAhAbdwXWsCo/+YLHRGBg DBACegSaFJriJEtIMCEoBBhpaErAytCgR8BXERHUPZRQgdRA08RRLtQU9BQpicK6kd4ON1bYhKFG LxlOYslkawUiIiRSoiET+G3BnQ5SY6JAIrzypBY/DLhAAiD7/qF4+IBQABA4UBDQIBBMKcpfGpuK GFEqKnr1Ew05wSxBgaAiEBq8lBN4RRRAJgJBogQ06CxPTAIrDdVgAGCiKQC0+CqQZPRmVFr6SBMv qHABJlmxwGClaHGQEnqadET7g6YtkIOHwXYTE02iU/BFT60cqAlHUAFAQotVEU1u/A839dCiESgo qXHAGR/lTY0LRYyCwQsYJMXKYABTwLCoKbhISURgmOgeWwoZPTCiiASTlHKhxgqGKBSa0igraqxo 8EWgxp0QCKpxUXSs0KIXlZDWRanSBI+JgowjgsIBwNHEdgvJKzSC8rcdkS/uJAAWK75SIlAIIQEG vMBQgzfTRYNaMgJu+FsQVpyZZNFRo5ESDE0V0cFOBrjjAgZOZAoYZDAU9DSBgWEBUgRwgQYJiXJl LNQfavl6Y4kEvZKHBw2c1HJXJjTlq2QYOwQ7lDIRGiWFJnjiihY2EYpEtcIBpqkaMDC5UFNESE1n wVslGrJCIz01sRSOGkLzhSJ6AgJGoARgOGx4aRRYmQFAiZdCohS1YtOEikIGeGkWBUaDLyYlRFOB +MgEvayQyFFNarIEj6BMQIIhCgWlAhEFQTlLqShatsgkgLvCeUOgUUrUuKsAQBCzarmIwasnB5r4 kgAhaMpR+ShhfOWixFAqCkpcbL9ogoQqyDUZiYIKKClaH5ogKDKBQQOFGNFLsGkJAIPyU0KaDMDA kKESGzVUKK2XNNRoxEkNhqKhhFAYsSErBwBkYsmBwYASd/TIglHjgtWmhAwAJHpFpAlMhDYWeEZJ XmQCIY5iE0a0+CIoeZaRkGhgRkZQGgCgUlBq4RHAQGsOL1RAlRBNCtSiU7rUEiCVlS2FC440UWJV fghMhgilhBYTkUBaFwSaGg45Wio1seJo8nMvNjTFhkDBRI0GgdrVmTQEllJ69Rxy9RYlMIp8cZQs NlkBo6SmSTKwKSXV4hEADTBCIAAWCSblQ/I6iGgiAxM/AIZIbJjkSxQFMhtW/uAoeFKrG/irWCVN 3JQxAo7kJyUu6CkiREAjDBpggFFSS4+SQGgUFACCMCitIxqboQS5UxMXpDKkSaEJBg1eYtPRgVJn MgACUWMFJjCxaCpDNBRplAy06j5NDkBMFJsVYEJwJQGmUUawDCDxpUlEXIhIIBVkl8lMNoJe2lCa azUUMgOV2dsxGxuBggk8XiD1ZTIbT75gEBQbGaSeAXSYjE1I99TWSNGEkJoCmLQQGDu8lAxNABSN l1UCJg31FgE9GJFIpql+gcQXpADkRtEQC4AeFzCWBFlg8cOACXIBaCJDQk1RJkoYQhwt/sI/vCAM tfFvqSVYDbTIpYHgb6+9wgRWf6ghVXIEE68E5UGtVDApG/APzJ7iBvpndYQRCN113hG0R1Kt6z2N PykxquZ+BUCjz3BTkBlo9JhpUqtJjYxeAOojMf9T94+MAEPp7jrHbGQGHQ6/P9Kx9Ggexw2NNfv2 1Wn/5rQvaV/gr9+7s6bRvBIKafaXu1fki/yPpPBPH88ImPlwz8DgZQPzf7u06ujBE6+ZfFqhRcQ3 3fuD5869855TOhgV07B92R9++af1fMrPrEhT2H/S1L6RcKiuOdHyCsbLTcCXTqLIPrss3xEFaP9f zCVfqeVjHvccOsI4sB94I3a3B8/U4BOLtsV6XXjL5NMylR/fO/uXG/dFj+k35IwBBQ2J5NZV8z/6 +J3VXxw8+/o5Fw0765inPqoMBpkSSN0jy72H+AP+TJIHInuMP9fWVdc0JZKhgvzcUHbTtBp07TCl pU1mU/TOjRcGQCYpvbBE9ebnFiQuvKiP/ekD1qo1H37Y0OuCEdnvy3oTOJzWxy8VSZ7vf9sQNpm/ JSSqqxsCgUh+caTl+xZtNS4HkxGJ0AEz4OaETx2oriNeTk4eP77lUOJ6w3U2nZefjpkXQX9NzBl5 xmkBp/KhWx5Zu5erW7pm5+o33lwai8SXzpu3pcb8eXLp6l18dbiknfnmh64cPEviSOb6D5v7nI/v nXPB0HYdx5R0Hte+4KYNMS6HpuSEQ8bMbPGKZP7/DbhDoePnPGTIiJgmhT+6ZwfLF2CYXBV1OOBO qy8QNFQtMMuW3LvumstXp+ENmp/2CL9rwe1TF+0Pmp+FUtixZn/73fAoXRTfleEXRabmn4rnH4hG RkRyhrv/3fDA0+v45SOlbuNraP74SfYLn07dJ1O+9dIBvp+/dfmUnPKuXc4tLRldOPgVwG01dRvf xjdQUB7IHeX3D/nViv2ZhsbaNUsuDQ5vXzL26JKx7YpHBke/XNvYxAdHzFbw2qvZIuYtsthfckK3 nGTFkqXNzfx9ke8SkLG98PH0DgSOv3Fqn8yuhfO+SEWPMh86MY0sQ1/Qn2r6PJXuxpccMslE1Yo3 f/T6lM0Nt5X5Dq5fu7tzTioR59IaiISDAT93bU4wfm0bSCf5+4CfUfI7LEt+NcCsJh1GmzHlpyOY mIJ0Mt6c9AfdWWMs+Xg+4IeuOe2P8HMqRHOTMGzREPfjNN+f4LteCf6uEOIrwn4ncnI/f4iYsVgi EMIhmIqbezYOfKuPj/PNNy78TnOCd7QQmlRDneO7euNX327XUL999YJRk6595YtHP/yR+zVlx7l6 0G+H13+vzBzS/L7DfLl7+W9uffOmn1X9bESkrnrz1lTEcZa20cQcPkzr+dbGR4eX5vJ8zuGnKntW jRz8/dBt9+29bVSHaKqueu/azXHzQObDKl4ATh3CdxLMumlmjQT5uZ/pIsuJVxsKE+UurnCm+OTv P/jdYw6uuueup/lFHCauWMwF1lQzHxvUMz3sEL55Eqva62RqqmtSTjBy3Mk9CnxpXzCz/PcP+X2D g+Fpzyw/yA08k2z+/MO3p4SHoQxH7l1dm9701JxrntrJQec4seeuvOmJTXGfE3tx+syf/3nR9aGh p8zZxNvIsrk/Ax8KT3t5db3ZLT5nxwevDvAP9vu+PeWG2b7T+QSeQyeuz6iRQ6y35h1zZ1yWGx0Z /ZfH1+xLL3/sh2PvW57IJGPxRMMn8wec+ftK84BjRVKz2eqcvkUdC3I7lHYacu4ln71y8bp7fr9G e8TYX/jOnL/yr1uIldhfzd/Wq+qSTqigQ98BnUJH0AjMj0PyC4oLitvlRYPO+nlPbfBNe20Wk4E1 UNCh88jhPYxovhvi8ELIUWNusInA/s0745EThg9z26x9dgQTZUDRgTNuuiB3w5+vuO1XX7h/hmTr MB+saJ485lZsljIr3xzEvSdeeX/5/OFdht3wqw8r00GOjq/e+c0Z1+ZuTvz1wJpLvlv+i81JJ1P5 Ya8z7un0+BP7GpdWbr+uV364uXHXuhre/sxqqF6/qraZhZyp2rvkRxc/OWrZy+9e12vP/P8YfV3u lsSK/aunXn7aQxt5Ou39+IQxD16+5I2mxkenlQ/E0RYzW5ScTqtn3VU54s7dlS/ce/Dxwd97r9fw 0967+5G/7qdTqYVzfhw4ZxA/TXC7KAdTs8jU6Hbm2HJn1YqtdVw1feV3rFz4/XX33PTEmrhjBo9V Hxp354Ojnp1TlnfZY29WmH13BI2Yljx019P33fvY/U+ubvLHl89bc8rPTidu6+I+5xOfbeW0wOQv DGcWL1zpOMf+4N+/3yfPfFXQX1A2esywUCwz/orxxc6eF19Y2qWs7Ljex+a7n0Jrqsx88IMo8yBM JZlh1n746Jvfemf5n275zS0ze+fPXnsgsfxPzziZDU/OeuzBJxc5zpZ9Tc7Wj/m64vk3X9a3OBrq UNq+XZgh4Mgyxx9EHD18kch8Jfhz54fz/n3q0O7FBc7K116E5Hezfj1n7nuQ7K1P71m13PHdfPXI klCoaPSkMZnFjJHZNC0D6svEvjx59pN3TD6hfVHnS2dclH7uK9+A4bOcrb+d/yXPhCnPZR74V/OV 7ZYZyU6DOc/MNuUvAaaK5gQdPnRf3NBz1IX/eVPg306du60uWHCU+fgg2nPEvJpXnvtp7xmTrmz3 b/N5orTVKJn+p/UdPqz/8P4lIR7pdb7DvgdngnAyBXwRw9m0YCGzwdgG77y6/IaH/nDvi/4ZF42Y +egIF+Wkqj6a3xAoNN8vLL3qJw+Cy2Tq//zTO5c3mQ9wCGZuArw5JhgHfhLFWc8HX6zx6KB/uTS5 t89lnb77zPLLh3JeTzz7wstO8cWSky73HRdxvmpucnyFOoqhNmcde6sgmMONwPHFNzgc+hzrHNId OubyY16+GMxg+yaMueDSQaHmMVOuifQqzvmy9qDTt5u7mHz8NkQJmwlpKUlE/kDk+MPRKPvUVXe4 +JmJfR74zzO37/BNuHskl3jzECWBNI8eHjCGhi/7BflFS2LPR+8vckb9sneeU+G6BoPn3/fUxY9O /faMr44q1ETS0U6Tbp2156wBpcN+/NGdZ51bGmilOd24jvrWuYP68cflaIR71MDJQ6753rI9tw44 whbhi6mvv5kOhjl4gjc+PI9TaNf7f7j+7ae79CiJ+hMN+3dV1ZFl6Oe3XsdXVyicUXzHi5Kfn/19 OJraNc/+/M3KZ4bf6svw1yqnuuLTvYU9+pZmnFSmnh8hRCNDJ0xJT1ha8/NxI8pCzbV1yXis2/Az nczMJ/88/o7ze8Sq9ztF7clg1XsVlVeUbnr83lsd5yF6kTaf1jXHGxPpaE4gdOrEizITP2r4xTmn 9Qwn6+v4Rm3HE/s7Gx58bXX5Bd0aH79rju/022KxOJdOVkkq0czDM5RTsPbX7234Trfjj2p696mn /Tc8zC9wis4eP/7Sa65Y7zy87Ef8jYFzBjyJx1JccKKZDY3762MBJ7Hz478MmPD78x+b2zuQoheU Zr7aGu7x8OIZnU9/xFfeP+gkKpZ/XnhiWWlBwN1IPYsj6Yrl2w7XmI88HKdyX1WsKT+drG0IFhb2 P+87zk0zJvyw5+t3lHeOBpoOVC5bceDUs/tEWJQJs5bdx3kmyLcCuU3xVsFd9mBV1VfxuN/P953D zAeDznObaTC7Aa37BQAGS/uDJlZkN7ZTtfSZIde/L7l85v3XDmtXlLnm3Ud+Mabnma5y1EdVswd0 HrHx9Rl9J1w2x6hGLa6a3W/s5L4z7uhaeH/5zJtv6LcYtmA4J9LB74M95Ge8Oo6Z/u4jj55VliVZ +tUDA/ue+ezMBZecMh6Ki68+xak1I5tNwh1lt1UxtXP5BhD9rlqzeKjRFPa9/u5er//kjAsGmG+z 2+I65jqZx44vfsxVjvrV289fdeYxWUBfc6ZTiode8Nbdr537PmJq2Z1XTF+U1f/ghT+eVpx6qrXG qTMXhq2jjxtrnB1nzEO/mzf9lD0f3HvNyB92nS2dM/CGB5eMyv4azxxWSp5f3jOsDLcOIv1hg6bp pFv09G5pZf+oAhgk3xV6/HfXZek5A2Lx+oZYJpxbzJtOS0k08c6SjhTkSgUPB1xtY7PV0KxrcszL UbYYCMPEcej+tMdEbkvSWFubCuUVRLUSjacWiltzjvJL7MSBA6m8ohxtHV4nHv/WuAVXP/f8RS1j 3RLvH/i3qa6uIZ7KySsqMA95U9pqUIbM9aRV0ftgwLwOtviCeL3skl7B0PNXTQ3y5S36wBZhVtgH bAv6r74xK9JgQkOhyUxQq2mGqmVpoglFI8WclYeXcG7UfCXEW4IhfvtxSBEK2xYk7sCaxeI+2bP8 MHseFcY1t/DQhzuiUiZubX4Wz2gUFx+KEqt4/8ZFZUv+9D8wGVBHGczDttkRNMqqTR0o7mB+wNiq aH8w4ObvUQwxBQTDQRPBDINbGHoKSi7BCGJh8tgcOtAsL3Ar/50C4ayXZJrulBgCa/o72b4ZFuk5 rqr6XPeXN98M/J+0Jlp+jv03Sd+adB7fJef10HzeTmEUmBIEPJE19GiQUdLkgovATHB8UTSLwrcN htffM5oWIzy1pbITI4zXZDH/PSEY+l+ejP9WeuovA252g1343s7bIcBKoQmaWZHQNpjFy9Sq2Rbv hSmuxahplVBZ2WL+7wksbkr2D5P0mUGnkxpH2382BDLTQA1AOwalmUn3ZPvu1b9GZsdQa9rEgwYq yyYl/MBErhqAmGEDg0xBqSZ4Nam9E0ATHrJXwjSFp8ZXPJgsCYIYvCY0iq6UFFS1+iJawWBAqRyI Kx5qNJJxRC9CwSTjqKYSoKYwgOipKWYO3Ic3MNPmtz0MN2b8UYGWQBgEACgBIDDEyBpo/YmbW7JS pymYGKTEXUUZY6KJiVjqiQbU9geBKDIpDWWFFwIa74iQhsYFWgpW0QJGjxWNlOiFwYTg9RKz3KkJ jRWlNyXLY5WWUHjbWZDK3zKgUWhoJVBrSLkioUSGjScx13tMOAa3bt2qIYYdGypYmAD5o6EICoCi YKrR4yu9ajTKDxKL0RxgAkMtE1YrS6BGKSsyRaMjpDRYKZZQJmqQlhyAwNQk73oYDYKlso7okYUR 2GsikLzsQtFoWH6sYmAcELAqDWRMkuVCUwI1MoQEIm1kvW8gG9M3/P8AKZJqnGGnIBCbRG3N5FkZ PUVIBOurTtL8/1YYbhU6rhFn0BEoTIlq9oeV/wtmXbOSc3g1+gAAAABJRU5ErkJggg== --001a11c3677e320a300515f02778-- From nobody Wed May 13 01:14:57 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B72D1A1BB4 for ; Wed, 13 May 2015 01:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40m6Y6_3D_25 for ; Wed, 13 May 2015 01:14:44 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40A91A1B9C for ; Wed, 13 May 2015 01:14:43 -0700 (PDT) Received: by wgbhc8 with SMTP id hc8so1512359wgb.3 for ; Wed, 13 May 2015 01:14:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IKpYDDF0xdnWNjJcUI8X/fhJPi/xYGOs/VfY099RXxo=; b=DxrYK63sSEzgLyj5tg4cunCM9AMguZhO4G3l9Eo50tHA2L0XfG9qntSishNPJsz8eg qnNRg38/10cUqwpgpMp1QSMO2JMCIIE7FFN1uCglZmiaagwcGN4KhsbN8eRuRpX0LctN i+sqrNQYOz0D4SHi87D3QnXX9LVpm7xGHlNxLw6KpZmdFyFRijYFNda0l/J40jMUOCWm rn5I+DJxj2auDMbdVQYr1o7p6iTfIYc7Je8nQbi92ieN6eLcqj7vxJSIscHQgpNfe0aq 7NFtff6z55VhlIBxjGIDmvg1AO0W/24rN0sbHmSKBxET/IVmsdtrE/Q2/Y3TIGLN3Gj9 qzDA== X-Gm-Message-State: ALoCoQlCKrWnRxn19U3elmFgAto0nU2mTlSEDcM5rbWTpFX6cH4+niUw5lzJzPtxj0JcXCFAllnt MIME-Version: 1.0 X-Received: by 10.180.210.171 with SMTP id mv11mr36249322wic.61.1431504882428; Wed, 13 May 2015 01:14:42 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Wed, 13 May 2015 01:14:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 May 2015 10:14:42 +0200 Message-ID: From: Warren Kumari To: Jigar Joshi Content-Type: multipart/related; boundary=001a11c25d360328c60515f23486 Archived-At: Cc: "" Subject: Re: [dane] trying to understand dane better X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 13 May 2015 08:14:47 -0000 --001a11c25d360328c60515f23486 Content-Type: multipart/alternative; boundary=001a11c25d360328c50515f23485 --001a11c25d360328c50515f23485 Content-Type: text/plain; charset=UTF-8 On Wed, May 13, 2015 at 7:47 AM, Jigar Joshi wrote: > Hi Warren, > > > How can it validate that dns data hasn't been modified if it doesn't have > ssl certificate, what I understood was it checks finger print you get > against the fingerprint it has published at dns to validate, however if the > domain doesn't have ssl support at all how does it work ? please clarify if > I totally misudnerstood this > > Thanks! > Jigar > Yup, you have completely misunderstood -- this has nothing do to with DANE (or SSL / TLS), it is all DNSSEC. I'd suggest you read some of the DNSSEC background information. Some examples: http://www.internetsociety.org/deploy360/dnssec/ http://archive.icann.org/meetings/buenosaires2013/en/schedule/mon-dnssec-everybody/presentation-dnssec-everybody-18nov13-en.html This list is probably not the right place for these questions. W > > > > On Tue, May 12, 2015 at 8:05 AM, Warren Kumari wrote: > >> >> >> On Thu, May 7, 2015 at 2:45 AM, Jigar Joshi wrote: >> >>> I was using this https://www.dnssec-validator.cz/ >>> >>> >>> I got this icon >>> >>> [image: Inline image 2] >>> >>> for a local network url which is over http (no https support for that >>> url) however hovering over still says secured by dnssec >>> >>> my understanding is it compares the fingerprint of certificate with one >>> dnssec says to check identify of host >>> >>> https://www.dnssec-validator.cz/pages/documentation.html >>> >>> doesn't list this icon (in orange color specifically and hovering over >>> says secured by dnssec) >>> >>> if it is not using https how can it compare fingerprint ? >>> >> >> It isn't / it doesn't. >> >> I'm not 100% sure what the orange color means (and I don't have the >> plugin installed at the moment), but the first / "key" icon is only about >> DNSSEC. DNSSEC simply proves that the *DNS* data hasn't been changed ( >> actually that is a huge oversimplification, see : >> http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) >> >> >> The second icon (://, changes to a padlock) is the "DANE" icon. :// >> means: >> "For an existing domain name this means that no HTTPS secured connection >> to the remote server was established. Therefore, you can not perform TLSA >> record validation. The authenticity of TLS/SSL remote server certificate >> for the domain name could not be verified by DANE protocol because the >> connection to the remote server is not realized via HTTPS protocol." >> >> W >> >>> >>> >>> -- >>> -- >>> Jigar >>> >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>> >>> >> >> >> -- >> 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. >> ---maf >> > > > > -- > -- > Jigar > -- 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. ---maf --001a11c25d360328c50515f23485 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 13, 2015 at 7:47 AM, Jigar Joshi <jigarjm@gmail.com>= ; wrote:
Hi Warren,


How can it validate that dns data hasn't been mo= dified if it doesn't have ssl certificate, what I understood was it che= cks finger print you get against the fingerprint it has published at dns to= validate, however if the domain doesn't have ssl support at all how do= es it work ? please clarify if I totally misudnerstood this

Thanks!
Jigar

Yup, you have completely misunderst= ood -- this has nothing do to with DANE (or SSL / TLS), it is all DNSSEC.

I'd suggest you read some of the DNSSEC backgro= und information. Some examples:
http://archive.icann.org/meetings/buenosaires2013/en/schedule/mo= n-dnssec-everybody/presentation-dnssec-everybody-18nov13-en.html

This list is probably not the right place for these = questions.
W

=C2=A0

=

On Tue, May 12, 2015 at 8:05 AM, Warren Kumari <warr= en@kumari.net> wrote:

On Th= u, May 7, 2015 at 2:45 AM, Jigar Joshi <jigarjm@gmail.com> w= rote:
I = got this icon

3D"Inline

for = a local network url which is over http (no https support for that url) howe= ver hovering over still says secured by dnssec

my understanding is it compares the fingerprint of certificate with= one dnssec says to check identify of host

https://www.d= nssec-validator.cz/pages/documentation.html

doesn't list this icon (in orange color specifically and hover= ing over says secured by dnssec)

if it is not using https how can i= t compare fingerprint ?

<= /div>
It isn't / it doesn't.=C2=A0

I&#= 39;m not 100% sure what the orange color means (and I don't have the pl= ugin installed at the moment), but the first / "key" icon is only= about DNSSEC. DNSSEC simply proves that the *DNS* data hasn't been cha= nged ( actually that is a huge oversimplification, see : http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions)=C2=A0


=
=C2=A0
W


--
--
Jigar=

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




--
I don't think the execution is= relevant when it was obviously a bad idea in the first place.
This is l= ike putting rabid weasels in your pants, and later expressing regret at hav= ing chosen those particular rabid weasels and that pair of pants.
=C2=A0= =C2=A0---maf



<= font color=3D"#888888">--
--
Jigar



--
I don't think the execution is relevant when it wa= s obviously a bad idea in the first place.
This is like putting rabid we= asels in your pants, and later expressing regret at having chosen those par= ticular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf
--001a11c25d360328c50515f23485-- --001a11c25d360328c60515f23486 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_14d2bd58a2dbe278 iVBORw0KGgoAAAANSUhEUgAAAIUAAAA9CAIAAAAMIT1zAAAKyWlDQ1BJQ0MgUHJvZmlsZQAASA2t lndU08kWx+f3S2+0hAhICb0J0gkgvYYiSAdRCUkgocQYCM2GyOIKrCgqImADF0UUXJUia0EsWFgE FLAvyKKgrosFUVF5P2CJe955+9+bnJn55Dt37tzfnDvnXADInWyRKBmWAyBFmCYO9nZjREZFM3C/ AwhgAAGoASs2J1XkGhTkD/61fehHrJF2x2TG17+a/e8FeS4vlQMAFIQsx3FTOSkIn0H6KY5InAYA io/o2hlpohkuQpgmRgJE+OAMJ8wxYg9ocXN8fdYmNNgdsXkEAJ7MZosTACCNIjojnZOA+CHjETYT cgVChJkIO3H4bC7CmQgvSklZPcOHETaI+4efhH8wmx0n9clmJ0h57luQncjBHoJUUTI7a/bP/3NI SZYg9zXbNJGRzBf7BCMzHbmzyqTVflIWxi0NnNcFyBfNM1/iEzbPnFR35C7n9nLZHn7zLEkKc51n thihv20EaazQeRavDpb6FyYvncmP2Rj4PJaUeameIfN6vMCLNc/Z/NCIeU4XhC+d59SkEGkM2Xx3 qS6WBEtjjhd7Sb8xJRXZ+fe5HPb3s9L4oT7zOpfn4TnPPGGYNB5RmpvUjyh5Nr9n4+cle0v11PQQ 6d40cahUT2T7zuTrrL0oLUh6J8ADeAJ/5McAYcACWAFzZAwAII2XieQdAO6rRVliQQI/jeGKvBQe gyXkmC5iWJiZWwMw8+5mbAB4d2/2PUF0/HdNhJxl54HkdPV3LU4FgGYkF5QJ3zWdIwDIRgLQlMOR iNPn/KFnJgwgAllAA8pAHWgDA2CCRGYDHIALErEvCAShIAqsBBzABylADDLAOrAJ5INCsB3sBuXg AKgGR8EJcAo0g3PgErgGboFu0AcegkEwAl6CcfABTEEQhIMoEBVShjQgXcgYsoCYkBPkCflDwVAU FAslQEJIAq2DNkOFUAlUDh2CaqFfoLPQJegG1APdh4agMegt9BlGwWSYBqvBevBimAm7wn5wKLwC ToDXwNlwHrwNLoOr4ONwE3wJvgX3wYPwS3gCBVAkFB2liTJBMVHuqEBUNCoeJUZtQBWgSlFVqHpU K6oDdQc1iHqF+oTGoqloBtoE7YD2QYehOeg16A3oInQ5+ii6CX0FfQc9hB5Hf8NQMKoYY4w9hoWJ xCRgMjD5mFJMDaYRcxXThxnBfMBisXSsPtYW64ONwiZi12KLsPuwDdg2bA92GDuBw+GUccY4R1wg jo1Lw+Xj9uKO4y7ienEjuI94El4Db4H3wkfjhfhcfCn+GP4Cvhf/HD9FkCPoEuwJgQQuIYtQTDhM aCXcJowQpojyRH2iIzGUmEjcRCwj1hOvEh8R35FIJC2SHWkZSUDKIZWRTpKuk4ZIn8gKZCOyOzmG LCFvIx8ht5Hvk99RKBQ9igslmpJG2UappVymPKF8lKHKmMqwZLgyG2UqZJpkemVeyxJkdWVdZVfK ZsuWyp6WvS37So4gpyfnLseW2yBXIXdWbkBuQp4qby4fKJ8iXyR/TP6G/KgCTkFPwVOBq5CnUK1w WWGYiqJqU92pHOpm6mHqVeoIDUvTp7FoibRC2glaF21cUUHRSjFcMVOxQvG84iAdRdejs+jJ9GL6 KXo//fMCtQWuC3gLti6oX9C7YFJpoZKLEk+pQKlBqU/pszJD2VM5SXmHcrPyYxW0ipHKMpUMlf0q V1VeLaQtdFjIWViw8NTCB6qwqpFqsOpa1WrVTtUJNXU1bzWR2l61y2qv1OnqLuqJ6rvUL6iPaVA1 nDQEGrs0Lmq8YCgyXBnJjDLGFca4pqqmj6ZE85Bml+aUlr5WmFauVoPWY22iNlM7XnuXdrv2uI6G ToDOOp06nQe6BF2mLl93j26H7qSevl6E3ha9Zr1RfSV9ln62fp3+IwOKgbPBGoMqg7uGWEOmYZLh PsNuI9jI2ohvVGF02xg2tjEWGO8z7lmEWWS3SLioatGACdnE1STdpM5kyJRu6m+aa9ps+nqxzuLo xTsWdyz+ZmZtlmx22OyhuYK5r3mueav5WwsjC45FhcVdS4qll+VGyxbLN1bGVjyr/Vb3rKnWAdZb rNutv9rY2oht6m3GbHVsY20rbQeYNGYQs4h53Q5j52a30e6c3Sd7G/s0+1P2fzmYOCQ5HHMYXaK/ hLfk8JJhRy1HtuMhx0EnhlOs00GnQWdNZ7ZzlfNTF20XrkuNy3NXQ9dE1+Our93M3MRujW6T7vbu 693bPFAe3h4FHl2eCp5hnuWeT7y0vBK86rzGva2913q3+WB8/Hx2+Ayw1FgcVi1r3NfWd73vFT+y X4hfud9TfyN/sX9rABzgG7Az4NFS3aXCpc2BIJAVuDPwcZB+0JqgX5dhlwUtq1j2LNg8eF1wRwg1 ZFXIsZAPoW6hxaEPwwzCJGHt4bLhMeG14ZMRHhElEYORiyPXR96KUokSRLVE46LDo2uiJ5Z7Lt+9 fCTGOiY/pn+F/orMFTdWqqxMXnl+lewq9qrTsZjYiNhjsV/Ygewq9kQcK64ybpzjztnDecl14e7i jvEceSW85/GO8SXxowmOCTsTxvjO/FL+K4G7oFzwJtEn8UDiZFJg0pGk6eSI5IYUfEpsylmhgjBJ eGW1+urM1T0iY1G+aHCN/Zrda8bFfuKaVCh1RWpLGg0pcDolBpIfJEPpTukV6R8zwjNOZ8pnCjM7 s4yytmY9z/bK/nktei1nbfs6zXWb1g2td11/aAO0IW5D+0btjXkbR3K8c45uIm5K2vRbrlluSe77 zRGbW/PU8nLyhn/w/qEuXyZfnD+wxWHLgR/RPwp+7NpquXXv1m8F3IKbhWaFpYVfijhFN38y/6ns p+lt8du6im2K92/Hbhdu79/hvONoiXxJdsnwzoCdTbsYuwp2vd+9aveNUqvSA3uIeyR7Bsv8y1r2 6uzdvvdLOb+8r8KtoqFStXJr5eQ+7r7e/S776w+oHSg88Pmg4OC9Q96Hmqr0qkqrsdXp1c8Ohx/u +Jn5c22NSk1hzdcjwiODR4OPXqm1ra09pnqsuA6uk9SNHY853n3C40RLvUn9oQZ6Q+FJcFJy8sUv sb/0n/I71X6aebr+jO6ZykZqY0ET1JTVNN7Mbx5siWrpOet7tr3VobXxV9Nfj5zTPFdxXvF88QXi hbwL0xezL060idpeXUq4NNy+qv3h5cjLd68su9J11e/q9Wte1y53uHZcvO54/dwN+xtnbzJvNt+y udXUad3Z+Jv1b41dNl1Nt21vt3Tbdbf2LOm50Ovce+mOx51rd1l3b/Ut7evpD+u/NxAzMHiPe2/0 fvL9Nw/SH0w9zHmEeVTwWO5x6RPVJ1W/G/7eMGgzeH7IY6jzacjTh8Oc4Zd/pP7xZSTvGeVZ6XON 57WjFqPnxrzGul8sfzHyUvRy6lX+n/J/Vr42eH3mL5e/Oscjx0feiN9Mvy16p/zuyHur9+0TQRNP PqR8mJos+Kj88egn5qeOzxGfn09lfMF9Kftq+LX1m9+3R9Mp09Mitpg9WwugkBGOjwfgLVInUKIA oHYDQJSZq4tnLaC5Wh5h6O8+I/8Xz9XOMwtIDQGq2wAIzQHAH5n3IrMe0mVdAAhCeqgLgC0tpR3M tdR4S4tZgkjNSGlSOj39DqkHcYYAfB2Ynp5qnp7+WoPUOg8AaPswV4/PWMsdB+BgtlmQnf+tgv45 R/8Y/wOOHgAVn32irQAAAn9pVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADx4OnhtcG1ldGEgeG1s bnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IlhNUCBDb3JlIDUuNC4wIj4KICAgPHJkZjpS REYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMj Ij4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6 ZXhpZj0iaHR0cDovL25zLmFkb2JlLmNvbS9leGlmLzEuMC8iCiAgICAgICAgICAgIHhtbG5zOnRp ZmY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vdGlmZi8xLjAvIj4KICAgICAgICAgPGV4aWY6UGl4ZWxZ RGltZW5zaW9uPjYxPC9leGlmOlBpeGVsWURpbWVuc2lvbj4KICAgICAgICAgPGV4aWY6UGl4ZWxY RGltZW5zaW9uPjEzMzwvZXhpZjpQaXhlbFhEaW1lbnNpb24+CiAgICAgICAgIDx0aWZmOkNvbXBy ZXNzaW9uPjE8L3RpZmY6Q29tcHJlc3Npb24+CiAgICAgICAgIDx0aWZmOk9yaWVudGF0aW9uPjE8 L3RpZmY6T3JpZW50YXRpb24+CiAgICAgICAgIDx0aWZmOlBob3RvbWV0cmljSW50ZXJwcmV0YXRp b24+MjwvdGlmZjpQaG90b21ldHJpY0ludGVycHJldGF0aW9uPgogICAgICA8L3JkZjpEZXNjcmlw dGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KKKF5aQAAJgdJREFUeAHtnHmYlNWVxr9a u6o3ugWkm0WhARdABGRRFlsRAyqgDGKiIupoRB01ipGYqBijRiRqnpiJycQoMcbdjHGJCgoKKCKE HcRGFkFoxG6g6bWqa5vf/d7qy0c3mkyeeeaPmdzHXM495z3vOXf97lddFd/dd98dCAQcx0m7xefz Iav4/f5UKkWNJRgMIlurXGhmMhlkAHKhCd66o5cXGEwUXJLJJE0xCwlMplAohFUMABQFkxdmqSQA pjQ3N1MrH1HRxAsMhOgpREGpVGkiy6QM0YCXHoyNAgwAnIwAegAI1CjVFKdqhUYvQcxQwSwNMlaK eoQXBVMikYAWwc8QoFIekmkqM9zQyxlq5WF8WnqOSWGAKQBNkCpYKYBVQw6MIQBJrfDIpEihKQAy ycGg0JYBAQ0FEzKOxKJGo2GlScEdDXqKYLZ3hEAJxrC4PNReWpcgIw2cQopEtMJLT7YoRS69ZLlj JRYAwAiYKBoWNGCkQZYePFaDRCUtDamyBr/fJkE8ivS2V/KiZm1SA7AZIBNSw6T88KUJwBC5SwwN XhSU1EpLTWT1RHqmBxdgUFGTAE0wsqpvShUlYDSY4FeTuMpc0eUIABLp0QgMCQWYamWO1WrQh8Nh mrjLahxcFymFxKTO0mSgFRElSDnSBWGIy+ghKxOsZo/gpqQlkygFmWJlTYN1w0QYxZASEqUuF5q4 kAFWClE1jugB4CiwrCjRoGc0Tf9cL5pEAUAtL3UMPU2rFJVqwPKlBkORC7VdDV6ZlIgIFXitaMmw 5eTkUMOAhogUb0RkNYmoKNRK1WaCRmmgJxB4BKJDJS8ALrE5ALEi4xv89NNPaSAJh4NkCTaYBJAU mSxSJm8wTAoGGDZkrCRHCDRKQnrVyhs9SDS4mzAtW0d4mqIF4xrNJNET9c0yi4HaC1ZThPBbQmmI LiUCbEoDE82CgoLS0lKoNJ2WE0F5ogeJTAi5wFBTU1NbWxuLxUSrWrFsYnKh6c3cNDdv3sw/rYoX BJGarTDf3FSvwNg8/ibnN0T5OpPlVJI2HONlNfRcTWv1Zg6DtylZOe/bt+/dd989cOBA+/btmRub gyZDixpywBQmhrJ3715OguOPP/64447r3Lkz08m2w3rEKN64FuPbtWuXTcKGlNCKRT7U4JUTAIo0 rQSawDBRJHvDW9nCBLa0amKlWBIE9NLYIbZU3kDCqLYA64veq2wli4dljsD4zp07t2vXrsh2SgiN CzUToA3KoVdfXw94wIABZ511Vn5+PlaiUATGXVHQWNnGRak9hMbcaqzh64RMOlW/4e30tkW+RBPM cJr/eWJkHVFlyMCXCUX9ZeX5/cb5/IeuesbmelGDb2pqos/0xBuU7pGPnpk2dSt4kZLbmkRukQpK 0wqSqS3Sa5IjGg10x44d0TATaEiMbPHShtMtRuPIZHBGTZ06tWfPnsCYAxW8bCBF8WoUy0ZUPuaR KxVt+dD0OtOsWfdm/o53fEEfaWbSGTOcbVaYocs47F4fK8Npznw+v85xigdOtGwIKkwDxytx8/Ly CESXKOoAJI2NjXV1dex0NDQp6oPNrYXm0L8yCUmNQRpqinDSt8UQGoCsltE6Kiv0TA8TQOaaG5oC g2RhsVGuvfbao446isnAhFIwaMWsGhebj40lk/TI5u74dSDLEqt4pzDqpNLZuwR4uVhfBDpGbSaF I5U15ffHK951Bk40KrfDAtCr6urqDh06xONxeiIeOyiag2g0WlVVBYbuyQsGTLYPVsBd/FYjwSrx UggvUrIwFkCzpQvZhIEpH7tkLbllY8ccPHjwwgsvVLbgKV9++WVFRcX+/fvBM0knnHBCSUkJss3K ypZHzNRmni3OCtYsIROvS4Ry/D765qTZA+6awpRdey2CbWLi2pGO1UNoQ5Io2VdWVvJ4ZH+gl0lr imXV0NDAQqOJO1tn9+7dHNxaiUpMeKWkWnqbthVaWeXoBaMBYzVr1649+eSTydA6YtIqoZaAC8kw N5jYKAJwTPXr169Hjx6csWYq/P4NGzZs3LgRa25uLrCv3NKnT5+TTjrJRlSUtk002X1nERKgs51H MOcQmyPgpFNxf9o8PRx/kJ1gLC1FLrQ40AJBc4N0T68sACS5fv755+RNH+TE0HPNp16xYgWPzZtv vpmbyWuvvfaXv/zl9ttvLyoq2rZtGxrAIofB8Lc8h0RiNV7B5m9SdENTA2BTrl69misM27SwsLBT p04MEzf+TZs2MR+WUFRq4qjnNpx0ivnQ9DDWLC9Mo0aNoguapz179nzyySfMxPDhw9kx+HIYLFu2 DCWrkBuXN0RbmRDmvGprgMh2iVHImEFIJuONvtyjnFA0E6t14rUIXsfs1DBX7glhkvYdtvM4glau XMn+5ThiVpiJo48+ms0O/xtvvLFo0aKZM2fSQ2RWK48QRo2ZAw/M5kNEm5iNbrtgBS/e5O92h8H6 4IMPmBKa+EJO9M8++0xNMVtONSGkIzYiSDKEkMJe4VHHcuFRx2SgAaaXByaDi4BoSZ4m92ZMXbp0 ET8mm2qriNn9IXOrzKzPnsoDifZ53c64Mnr8WU4gnKrdE1vzcmzbEn+As0UTYXYLT0ZmIZlK85FF POGrrmno5nk4bdmyhdXErJABnSkuLqYbO3fuJMq6det69erFecUG4uRlzXKs0VtMW7dupUtKWvkw iOvWrc/Lzwu4lzfbn2Qq2dDQOGjgAK6bQqoGgMCzavHixbyjcbawFdgchJs/fz4Tr15bsCW0QQFQ ADDodIG0pWFuSJvNockAzzODzaFbGXgKSjYKSj1OWpHbEFY4dE+Qs2qFpwZHXVWxrfv0nwT6TGiK 1UdDwUBRt9wzbtlX29C0e0MgFOGDAO5caR73fFBEvvFEKpZo3ldVUxfHHUKxsd7pCRqGhtMpEonM mjWL4eCFi1k59dRTef/Cm/N27NixWpXgeYpYErqN3K5du2O7d+f8hEHZoiQEtCWdSlitaioussqq VauYgLKystNPP1394phialvshkH8VmPJSYPEpNfRRBMrhBxBdjIAQEIRUoLSsLUwYqa2m0/6LfN/ fei8wl9u2Lz+NIu69c4tG7Rs9pU5zQf73/BotH1nnu0lZ89I1O/zBXjdIA+eKuThc5IJ8wISDB3c snrl3PvwpSg8z3DOKLLn5GWU2SLoeUiwFRjK/v37M9BLly4FwG3EdMv9wAcvuasW2zHdum7Zui3q 84fD2Zcnngc8sLp27YKXMAjWBZkppx48eLCsPLE4FQFYmCbDNoEJSW0nA7wKM2QOZHdxoNGU4MtD grdCFhZ7Aj0AlCw4Zo5nFU2K9JIVVHLjxmfPvOqnh57nwlm0FUBHSsqSjbWNGxelM4nYvt3RDryv psLRXP4Tl+pEMhEKhrgUp+Kx9sPG+15/Gj085ITAkDEHZMDD48Ybb+RzIbp0zDHHLFmyhHkaOHAg 5xKXE84xOgOYPjNzHPfeEBovOLt0Lt2z58t27QoFo8NdupinpU1bgsVz+iHrKEMYMmTI0KFDwQsg wQZCaWVLSPKCea1oAFgSPiZhPlhVep5jZW54aCHQU+ojFpchsfbN250TZ2f3hxgtr01CmvrKLUXd ep08fXYqVlfU2ywxntosj+Z4DHHNk7O69Ojt69J/yx/vOe786Vs/eKtdxOfvdlLTjk3i0SpgGjR2 1Aw9+Wnd8fDo3r07G4UTlmdM7969kemVNhBetsPa3eoSF+LcvFyeB9wOGhub8vLyEWz+wpg0W1YD U85bNAcU5NLL5F2hNpDcaVLIVoXFgaBtQY0MDE69uio0T+y+ffty333nnXd4ZqBk64tt/fr1PFcU XZrD6/j2lU6f8cdn9weBMbsJmNkmHona/jfs3la1Yl5p+XcAYAXJNeqvj9+Z3vVpJhBq2rFhx+p5 ST4jidV99sQd2A76fcmVC6Nhd/cAd29wPEJZ9TBAy9GvgWYOuNSOHj2abUE3uAKNGzdOpzMdJha9 pbbpqQ9qlpaUcGrxxymeW8cea1af9Ca9w89eIh577LGMCFfPc845RzBheCbzSJAvGgTbazWZBlaG wBoTNMIz4iTMQUSqmleYuSxwavFw0gMcKyuP0CydhQsX0lPGARiFQHiJmeEPFzifrNt+6LwiBkVm r4DMubTzlV/wQtFh2IRgTrSuek/Fq79pXPpyTiBID/JyGXdfOJPK5OUz8ubhDntuXrzJ/TuS+55C +G7dum3fvp3UmRW2MEfTxIkTmQyWGK9LZPbFF18wEzxITMRwmFEgY7xo2uyVGDXFcHbtsunTij4n niCNrTFJlkA9aNAgxoj9x8sNdweu0VwcPv74Y94PysvLec57XayXSDQmJEMhf6YQADKLHU774oIS JC68xlJsMgjsDCbDTol2iSajBZY/aOxk34zfmfNKRIoqRjTgVKMJR3L86eSul2bvXvh0OpTXXLM3 2LC/oKiIGQLovq6b9w7SwYtLkI//zAdw2c+oFZiDiMsr653+PP/88yAnT57MnkA48cQT6d7y5cux suU5rDhemA+eCpzIdhGBMbl6zmvOqJNO6sdnRpB487dNgWFgVZ533nmvvvoqU0KxYCaezQoAcmrr aMeBCaBgZRuhVA7UKOGkRySpK6842zKgZ/ezM7xTgga9IuJC6T35Bz/5cGi2J7TdnmZ7q6YNwK4K 5oT8Pt489jL+EY7OwnY80rOfRPLi7il4sXt5uvDRo+VBYI0wJTzfGPRLLrmEztANHrCTJk1iDvDi WnXxxRdzCJAlA00qPPN1lxc9GgSQakpmMpSnrKoxWbDVsNWmTZvGO+mOHTu4Z0NOYTuSD3g7NJYH QYWhx8oc6BFiOuiepTTJ9v333x8/fjwAwEpMQqsme4IpWbBgAbuEKyXzYQHycoJdrnp0t8/ewTF7 u6qmfJbMOLUownxwszX95BMRhiXL0vLPYe7cgH3OwXhy5MMfYYdW/WFnkBBrn+GmJ2TGlNA3PfTQ Q8JyQ48Xxxp/SwDQEiH7r1JqpVRTE9O2bgsWRnplbmmticOTTO6///7u3bsz9NKTD72gO7qMMJe8 ePNJOy+GdEQkIrTkNjoMfCjAZHAe2HDWKs2h9w8MXiKc0SiJYF67SLCZz9LRmFkxtsPmQ458qoXA A5aapRIImOe5K2Z5GHFexzi1ucUy3PSKDkOm5YZSYPpMb0Hay1Wr3CwtgjJE0EliTaKipghjkWAE s3orePXW1yrtNIBHpiZPtt2LL744ffp0runeKcELAEUJiIRdws5AtgUAssVkP9G0ZiVBMATVmDqO uIivkASCfj4opHe+ALdAvgJi/nM/8TRAs6eDZrJC4RBI3l+PHvltSLzMDBn3VD6A43GKXhuFvcK4 I3OOU8iPjEeOHMlRZnrj9kc8yk21TLJCZWFejGSsCLZGkGx9vTCLFD9IdoZOKjTIagKjzxTWEPlz qD777LMcg0wPMDdCtrKEVvBakdFbE0Lr+5XQNlc1y86+fLvPObDi1VTTQT4k5KlGTI00FMrgkIa5 yCkoHnZ+jzHT5K54ik3N8ufU5q2VvxNQc1hpadMxboo8YzRbdr1/XQ+VpKxKw8qK+3W1HLFawWYo F/QUEuD2hUZzIBNKbV9d/6jJn2ch6+mll17ikzdWEmsOQu0VeNqSQ9VKKXKj5wFrG0cU8IRUJq/s 1Vj914UBLBLVgslLsrVaBgQ7JTZWWx4c5UJtZeG99RFNR1QqBCYm4+233+ayx07VicrEMAHyomY3 8ywRHgzbhcHkHC4rK+NxwpsHnwDZE8ybTCsZKpHQBd+MGTMUgM5TIEVJYIioWQso0aiW0tIJJjyO 6C1MnNYR/aGQ7sCBlxIMMjsdAQwh0NNt7X2RoxQhtQRcNBaYbD5yV1DlIxi1hhLBBkWAChdiiYEm QSGkBgkPxz0LnyEWM7U1MTIAaMKDgBc8PN7JijcqPnbjKINQbOL3RkeDozS4kx4yJci7mBihBoRN OASlCyOC1WOliSdgWKxeTWrwKElOJvAqaMSDniJyK0AoNtdorBQ0sFEjI8ADPwUwsmpM8lVcWVFa AUJkkSOo4IJehICFwYRehGgYWS57HEfI6GVFoKChMGIKikYTw18TmCeujkyMRgAYjnBSAFOjUY1e IyMBPTxBXlOtljZ5Y9bY0RSU2vC5jNZZvDQR1FsACCwoCJWNNGAosKHXsKJHRgmMGpm9T81KhA2N AEpR/IyOOk/PbWJoAKNRwjQR4MEdLx30ACgoyQ1HTNTAqNVZrAokGIG4X4BHKUL4MeFIjUk81ABQ UiwtANzRyEpTiSEoAZr0UR2hBqxsAdA0eEVFS0Npwa5I1BJkoqYQjFpcAhAbdwXWsCo/+YLHRGBg DBACegSaFJriJEtIMCEoBBhpaErAytCgR8BXERHUPZRQgdRA08RRLtQU9BQpicK6kd4ON1bYhKFG LxlOYslkawUiIiRSoiET+G3BnQ5SY6JAIrzypBY/DLhAAiD7/qF4+IBQABA4UBDQIBBMKcpfGpuK GFEqKnr1Ew05wSxBgaAiEBq8lBN4RRRAJgJBogQ06CxPTAIrDdVgAGCiKQC0+CqQZPRmVFr6SBMv qHABJlmxwGClaHGQEnqadET7g6YtkIOHwXYTE02iU/BFT60cqAlHUAFAQotVEU1u/A839dCiESgo qXHAGR/lTY0LRYyCwQsYJMXKYABTwLCoKbhISURgmOgeWwoZPTCiiASTlHKhxgqGKBSa0igraqxo 8EWgxp0QCKpxUXSs0KIXlZDWRanSBI+JgowjgsIBwNHEdgvJKzSC8rcdkS/uJAAWK75SIlAIIQEG vMBQgzfTRYNaMgJu+FsQVpyZZNFRo5ESDE0V0cFOBrjjAgZOZAoYZDAU9DSBgWEBUgRwgQYJiXJl LNQfavl6Y4kEvZKHBw2c1HJXJjTlq2QYOwQ7lDIRGiWFJnjiihY2EYpEtcIBpqkaMDC5UFNESE1n wVslGrJCIz01sRSOGkLzhSJ6AgJGoARgOGx4aRRYmQFAiZdCohS1YtOEikIGeGkWBUaDLyYlRFOB +MgEvayQyFFNarIEj6BMQIIhCgWlAhEFQTlLqShatsgkgLvCeUOgUUrUuKsAQBCzarmIwasnB5r4 kgAhaMpR+ShhfOWixFAqCkpcbL9ogoQqyDUZiYIKKClaH5ogKDKBQQOFGNFLsGkJAIPyU0KaDMDA kKESGzVUKK2XNNRoxEkNhqKhhFAYsSErBwBkYsmBwYASd/TIglHjgtWmhAwAJHpFpAlMhDYWeEZJ XmQCIY5iE0a0+CIoeZaRkGhgRkZQGgCgUlBq4RHAQGsOL1RAlRBNCtSiU7rUEiCVlS2FC440UWJV fghMhgilhBYTkUBaFwSaGg45Wio1seJo8nMvNjTFhkDBRI0GgdrVmTQEllJ69Rxy9RYlMIp8cZQs NlkBo6SmSTKwKSXV4hEADTBCIAAWCSblQ/I6iGgiAxM/AIZIbJjkSxQFMhtW/uAoeFKrG/irWCVN 3JQxAo7kJyUu6CkiREAjDBpggFFSS4+SQGgUFACCMCitIxqboQS5UxMXpDKkSaEJBg1eYtPRgVJn MgACUWMFJjCxaCpDNBRplAy06j5NDkBMFJsVYEJwJQGmUUawDCDxpUlEXIhIIBVkl8lMNoJe2lCa azUUMgOV2dsxGxuBggk8XiD1ZTIbT75gEBQbGaSeAXSYjE1I99TWSNGEkJoCmLQQGDu8lAxNABSN l1UCJg31FgE9GJFIpql+gcQXpADkRtEQC4AeFzCWBFlg8cOACXIBaCJDQk1RJkoYQhwt/sI/vCAM tfFvqSVYDbTIpYHgb6+9wgRWf6ghVXIEE68E5UGtVDApG/APzJ7iBvpndYQRCN113hG0R1Kt6z2N PykxquZ+BUCjz3BTkBlo9JhpUqtJjYxeAOojMf9T94+MAEPp7jrHbGQGHQ6/P9Kx9Ggexw2NNfv2 1Wn/5rQvaV/gr9+7s6bRvBIKafaXu1fki/yPpPBPH88ImPlwz8DgZQPzf7u06ujBE6+ZfFqhRcQ3 3fuD5869855TOhgV07B92R9++af1fMrPrEhT2H/S1L6RcKiuOdHyCsbLTcCXTqLIPrss3xEFaP9f zCVfqeVjHvccOsI4sB94I3a3B8/U4BOLtsV6XXjL5NMylR/fO/uXG/dFj+k35IwBBQ2J5NZV8z/6 +J3VXxw8+/o5Fw0765inPqoMBpkSSN0jy72H+AP+TJIHInuMP9fWVdc0JZKhgvzcUHbTtBp07TCl pU1mU/TOjRcGQCYpvbBE9ebnFiQuvKiP/ekD1qo1H37Y0OuCEdnvy3oTOJzWxy8VSZ7vf9sQNpm/ JSSqqxsCgUh+caTl+xZtNS4HkxGJ0AEz4OaETx2oriNeTk4eP77lUOJ6w3U2nZefjpkXQX9NzBl5 xmkBp/KhWx5Zu5erW7pm5+o33lwai8SXzpu3pcb8eXLp6l18dbiknfnmh64cPEviSOb6D5v7nI/v nXPB0HYdx5R0Hte+4KYNMS6HpuSEQ8bMbPGKZP7/DbhDoePnPGTIiJgmhT+6ZwfLF2CYXBV1OOBO qy8QNFQtMMuW3LvumstXp+ENmp/2CL9rwe1TF+0Pmp+FUtixZn/73fAoXRTfleEXRabmn4rnH4hG RkRyhrv/3fDA0+v45SOlbuNraP74SfYLn07dJ1O+9dIBvp+/dfmUnPKuXc4tLRldOPgVwG01dRvf xjdQUB7IHeX3D/nViv2ZhsbaNUsuDQ5vXzL26JKx7YpHBke/XNvYxAdHzFbw2qvZIuYtsthfckK3 nGTFkqXNzfx9ke8SkLG98PH0DgSOv3Fqn8yuhfO+SEWPMh86MY0sQ1/Qn2r6PJXuxpccMslE1Yo3 f/T6lM0Nt5X5Dq5fu7tzTioR59IaiISDAT93bU4wfm0bSCf5+4CfUfI7LEt+NcCsJh1GmzHlpyOY mIJ0Mt6c9AfdWWMs+Xg+4IeuOe2P8HMqRHOTMGzREPfjNN+f4LteCf6uEOIrwn4ncnI/f4iYsVgi EMIhmIqbezYOfKuPj/PNNy78TnOCd7QQmlRDneO7euNX327XUL999YJRk6595YtHP/yR+zVlx7l6 0G+H13+vzBzS/L7DfLl7+W9uffOmn1X9bESkrnrz1lTEcZa20cQcPkzr+dbGR4eX5vJ8zuGnKntW jRz8/dBt9+29bVSHaKqueu/azXHzQObDKl4ATh3CdxLMumlmjQT5uZ/pIsuJVxsKE+UurnCm+OTv P/jdYw6uuueup/lFHCauWMwF1lQzHxvUMz3sEL55Eqva62RqqmtSTjBy3Mk9CnxpXzCz/PcP+X2D g+Fpzyw/yA08k2z+/MO3p4SHoQxH7l1dm9701JxrntrJQec4seeuvOmJTXGfE3tx+syf/3nR9aGh p8zZxNvIsrk/Ax8KT3t5db3ZLT5nxwevDvAP9vu+PeWG2b7T+QSeQyeuz6iRQ6y35h1zZ1yWGx0Z /ZfH1+xLL3/sh2PvW57IJGPxRMMn8wec+ftK84BjRVKz2eqcvkUdC3I7lHYacu4ln71y8bp7fr9G e8TYX/jOnL/yr1uIldhfzd/Wq+qSTqigQ98BnUJH0AjMj0PyC4oLitvlRYPO+nlPbfBNe20Wk4E1 UNCh88jhPYxovhvi8ELIUWNusInA/s0745EThg9z26x9dgQTZUDRgTNuuiB3w5+vuO1XX7h/hmTr MB+saJ485lZsljIr3xzEvSdeeX/5/OFdht3wqw8r00GOjq/e+c0Z1+ZuTvz1wJpLvlv+i81JJ1P5 Ya8z7un0+BP7GpdWbr+uV364uXHXuhre/sxqqF6/qraZhZyp2rvkRxc/OWrZy+9e12vP/P8YfV3u lsSK/aunXn7aQxt5Ou39+IQxD16+5I2mxkenlQ/E0RYzW5ScTqtn3VU54s7dlS/ce/Dxwd97r9fw 0967+5G/7qdTqYVzfhw4ZxA/TXC7KAdTs8jU6Hbm2HJn1YqtdVw1feV3rFz4/XX33PTEmrhjBo9V Hxp354Ojnp1TlnfZY29WmH13BI2Yljx019P33fvY/U+ubvLHl89bc8rPTidu6+I+5xOfbeW0wOQv DGcWL1zpOMf+4N+/3yfPfFXQX1A2esywUCwz/orxxc6eF19Y2qWs7Ljex+a7n0Jrqsx88IMo8yBM JZlh1n746Jvfemf5n275zS0ze+fPXnsgsfxPzziZDU/OeuzBJxc5zpZ9Tc7Wj/m64vk3X9a3OBrq UNq+XZgh4Mgyxx9EHD18kch8Jfhz54fz/n3q0O7FBc7K116E5Hezfj1n7nuQ7K1P71m13PHdfPXI klCoaPSkMZnFjJHZNC0D6svEvjx59pN3TD6hfVHnS2dclH7uK9+A4bOcrb+d/yXPhCnPZR74V/OV 7ZYZyU6DOc/MNuUvAaaK5gQdPnRf3NBz1IX/eVPg306du60uWHCU+fgg2nPEvJpXnvtp7xmTrmz3 b/N5orTVKJn+p/UdPqz/8P4lIR7pdb7DvgdngnAyBXwRw9m0YCGzwdgG77y6/IaH/nDvi/4ZF42Y +egIF+Wkqj6a3xAoNN8vLL3qJw+Cy2Tq//zTO5c3mQ9wCGZuArw5JhgHfhLFWc8HX6zx6KB/uTS5 t89lnb77zPLLh3JeTzz7wstO8cWSky73HRdxvmpucnyFOoqhNmcde6sgmMONwPHFNzgc+hzrHNId OubyY16+GMxg+yaMueDSQaHmMVOuifQqzvmy9qDTt5u7mHz8NkQJmwlpKUlE/kDk+MPRKPvUVXe4 +JmJfR74zzO37/BNuHskl3jzECWBNI8eHjCGhi/7BflFS2LPR+8vckb9sneeU+G6BoPn3/fUxY9O /faMr44q1ETS0U6Tbp2156wBpcN+/NGdZ51bGmilOd24jvrWuYP68cflaIR71MDJQ6753rI9tw44 whbhi6mvv5kOhjl4gjc+PI9TaNf7f7j+7ae79CiJ+hMN+3dV1ZFl6Oe3XsdXVyicUXzHi5Kfn/19 OJraNc/+/M3KZ4bf6svw1yqnuuLTvYU9+pZmnFSmnh8hRCNDJ0xJT1ha8/NxI8pCzbV1yXis2/Az nczMJ/88/o7ze8Sq9ztF7clg1XsVlVeUbnr83lsd5yF6kTaf1jXHGxPpaE4gdOrEizITP2r4xTmn 9Qwn6+v4Rm3HE/s7Gx58bXX5Bd0aH79rju/022KxOJdOVkkq0czDM5RTsPbX7234Trfjj2p696mn /Tc8zC9wis4eP/7Sa65Y7zy87Ef8jYFzBjyJx1JccKKZDY3762MBJ7Hz478MmPD78x+b2zuQoheU Zr7aGu7x8OIZnU9/xFfeP+gkKpZ/XnhiWWlBwN1IPYsj6Yrl2w7XmI88HKdyX1WsKT+drG0IFhb2 P+87zk0zJvyw5+t3lHeOBpoOVC5bceDUs/tEWJQJs5bdx3kmyLcCuU3xVsFd9mBV1VfxuN/P953D zAeDznObaTC7Aa37BQAGS/uDJlZkN7ZTtfSZIde/L7l85v3XDmtXlLnm3Ud+Mabnma5y1EdVswd0 HrHx9Rl9J1w2x6hGLa6a3W/s5L4z7uhaeH/5zJtv6LcYtmA4J9LB74M95Ge8Oo6Z/u4jj55VliVZ +tUDA/ue+ezMBZecMh6Ki68+xak1I5tNwh1lt1UxtXP5BhD9rlqzeKjRFPa9/u5er//kjAsGmG+z 2+I65jqZx44vfsxVjvrV289fdeYxWUBfc6ZTiode8Nbdr537PmJq2Z1XTF+U1f/ghT+eVpx6qrXG qTMXhq2jjxtrnB1nzEO/mzf9lD0f3HvNyB92nS2dM/CGB5eMyv4azxxWSp5f3jOsDLcOIv1hg6bp pFv09G5pZf+oAhgk3xV6/HfXZek5A2Lx+oZYJpxbzJtOS0k08c6SjhTkSgUPB1xtY7PV0KxrcszL UbYYCMPEcej+tMdEbkvSWFubCuUVRLUSjacWiltzjvJL7MSBA6m8ohxtHV4nHv/WuAVXP/f8RS1j 3RLvH/i3qa6uIZ7KySsqMA95U9pqUIbM9aRV0ftgwLwOtviCeL3skl7B0PNXTQ3y5S36wBZhVtgH bAv6r74xK9JgQkOhyUxQq2mGqmVpoglFI8WclYeXcG7UfCXEW4IhfvtxSBEK2xYk7sCaxeI+2bP8 MHseFcY1t/DQhzuiUiZubX4Wz2gUFx+KEqt4/8ZFZUv+9D8wGVBHGczDttkRNMqqTR0o7mB+wNiq aH8w4ObvUQwxBQTDQRPBDINbGHoKSi7BCGJh8tgcOtAsL3Ar/50C4ayXZJrulBgCa/o72b4ZFuk5 rqr6XPeXN98M/J+0Jlp+jv03Sd+adB7fJef10HzeTmEUmBIEPJE19GiQUdLkgovATHB8UTSLwrcN htffM5oWIzy1pbITI4zXZDH/PSEY+l+ejP9WeuovA252g1343s7bIcBKoQmaWZHQNpjFy9Sq2Rbv hSmuxahplVBZ2WL+7wksbkr2D5P0mUGnkxpH2382BDLTQA1AOwalmUn3ZPvu1b9GZsdQa9rEgwYq yyYl/MBErhqAmGEDg0xBqSZ4Nam9E0ATHrJXwjSFp8ZXPJgsCYIYvCY0iq6UFFS1+iJawWBAqRyI Kx5qNJJxRC9CwSTjqKYSoKYwgOipKWYO3Ic3MNPmtz0MN2b8UYGWQBgEACgBIDDEyBpo/YmbW7JS pymYGKTEXUUZY6KJiVjqiQbU9geBKDIpDWWFFwIa74iQhsYFWgpW0QJGjxWNlOiFwYTg9RKz3KkJ jRWlNyXLY5WWUHjbWZDK3zKgUWhoJVBrSLkioUSGjScx13tMOAa3bt2qIYYdGypYmAD5o6EICoCi YKrR4yu9ajTKDxKL0RxgAkMtE1YrS6BGKSsyRaMjpDRYKZZQJmqQlhyAwNQk73oYDYKlso7okYUR 2GsikLzsQtFoWH6sYmAcELAqDWRMkuVCUwI1MoQEIm1kvW8gG9M3/P8AKZJqnGGnIBCbRG3N5FkZ PUVIBOurTtL8/1YYbhU6rhFn0BEoTIlq9oeV/wtmXbOSc3g1+gAAAABJRU5ErkJggg== --001a11c25d360328c60515f23486-- From nobody Wed May 13 11:26:31 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2621A908C; Wed, 13 May 2015 11:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7RRzCw4DJlN; Wed, 13 May 2015 11:26:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CFB1A911A; Wed, 13 May 2015 11:26:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 11:26:27 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-ops-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 18:26:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Updates to and Operational Guidance for the DANE Protocol Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-ops-08.txt Pages : 28 Date : 2015-05-13 Abstract: This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification based on subsequent implementation experience. It also contains guidance for implementers, operators and protocol developers who want to make use of DANE records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-ops-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 13 11:36:19 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9411ACD85 for ; Wed, 13 May 2015 11:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDCqxa994GR4 for ; Wed, 13 May 2015 11:36:16 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0F21ACD27 for ; Wed, 13 May 2015 11:36:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D6BD0283032; Wed, 13 May 2015 18:36:14 +0000 (UTC) Date: Wed, 13 May 2015 18:36:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150513183614.GC17272@mournblade.imrryr.org> References: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 18:36:17 -0000 On Wed, May 13, 2015 at 11:26:27AM -0700, internet-drafts@ietf.org wrote: > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dane-ops-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-08 This should contain the various suggested changes from the last call comments. If I've missed anyone's suggested changes, please speak up. I've still not heard anything from Paul Wouters or John Gilmore about any additional text they might want to see in support of Raw Public Keys (RFC 7250). Perhaps the present text is sufficient. -- Viktor. From nobody Wed May 13 17:15:08 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F3F1B323E for ; Wed, 13 May 2015 17:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.239 X-Spam-Level: ** X-Spam-Status: No, score=2.239 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_BRBL_LASTEXT=1.449, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVPxmyKoKZ3U for ; Wed, 13 May 2015 17:15:05 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3A7B1B323B for ; Wed, 13 May 2015 17:15:04 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id t4E0F35B026773 for ; Wed, 13 May 2015 17:15:03 -0700 Message-Id: <201505140015.t4E0F35B026773@new.toad.com> To: dane@ietf.org In-reply-to: <20150513183614.GC17272@mournblade.imrryr.org> References: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> <20150513183614.GC17272@mournblade.imrryr.org> Comments: In-reply-to Viktor Dukhovni message dated "Wed, 13 May 2015 18:36:14 -0000." Date: Wed, 13 May 2015 17:15:03 -0700 From: John Gilmore Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 00:15:06 -0000 > I've still not heard anything from Paul Wouters or John Gilmore > about any additional text they might want to see in support of Raw > Public Keys (RFC 7250). Perhaps the present text is sufficient. I took a brief look at the draft, and I don't think the present text is sufficient. It doesn't explicitly repeal the requirement that TLSA records can only be used with X.509 certificates. When there's a bald statement to that effect prominently in RFC 6698, it's not sufficient for a minor paragraph halfway through minor section 5.1 in the middle of a subsequent document to show a counterexample. As courts are fond of saying, Congress does not hide elephants in mouseholes. Standards committees shouldn't either. The X.509 requirement needs to be plainly, succinctly and obviously repealed. I think the same is true of the RFC 6698 requirement that TLSA only be used with TLS and https. The port number prefix avoids confusion and overhead when authenticating multiple protocols that are used with the same host. There seems to be an entire section of the draft that says it does not represent the consensus of the WG and that maybe it belongs in a separate document. Section 9 is pointed out as not-conensus by Section 12. Why is such a section still sitting in a draft that's supposedly in last call? Section 9 also seems to say that if you have two valid TLSA records, one of which specifies a full key and the other of which uses a digest, a client can't use the one with a full key even if it is identical to the key used in the TLS negotiation? It also seems to say that if the server doesn't publish any TLSA records that use the client's favorite BetterAlg, then the client should not authenticate the server, even if the client supports WorseAlg and the server publishes WorseAlg TLSA records. In general the description in Section 9 seems very muddled. No wonder there is no consensus on it. John From nobody Wed May 13 18:07:47 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437671B3264 for ; Wed, 13 May 2015 18:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPEkaap5bOzn for ; Wed, 13 May 2015 18:07:42 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9521B3263 for ; Wed, 13 May 2015 18:07:42 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8320D283032; Thu, 14 May 2015 01:07:41 +0000 (UTC) Date: Thu, 14 May 2015 01:07:41 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150514010741.GI17272@mournblade.imrryr.org> References: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> <20150513183614.GC17272@mournblade.imrryr.org> <201505140015.t4E0F35B026773@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201505140015.t4E0F35B026773@new.toad.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 01:07:45 -0000 On Wed, May 13, 2015 at 05:15:03PM -0700, John Gilmore wrote: > > I've still not heard anything from Paul Wouters or John Gilmore > > about any additional text they might want to see in support of Raw > > Public Keys (RFC 7250). Perhaps the present text is sufficient. > > I took a brief look at the draft, and I don't think the present > text is sufficient. Thanks for reply. I was hoping you'd chime in! > It doesn't explicitly repeal the requirement that TLSA records can > only be used with X.509 certificates. When there's a bald statement > to that effect prominently in RFC 6698, it's not sufficient for a > minor paragraph halfway through minor section 5.1 in the middle of a > subsequent document to show a counterexample. As courts are fond of > saying, Congress does not hide elephants in mouseholes. Standards > committees shouldn't either. The X.509 requirement needs to be > plainly, succinctly and obviously repealed. Do you have specific suggested language? It might reduce the number of back and forths if you're willing to make the first step in the desired direction. Otherwise, Wes or I will have to give it a go, but I'm leaving on vacation on Sunday, so cycles are very limited. > I think the same is true of the RFC 6698 requirement that TLSA only be > used with TLS and https. The port number prefix avoids confusion and > overhead when authenticating multiple protocols that are used with the > same host. I don't see any HTTPS requirement in 6698, just TLS. Thus, SMTP with STARTTLS on port 25 is using TLSA records, as is XMPP. What additional protocols over TCP that employ certificates, but not TLS did you have in mind? I don't recall much discussion of that possibility in this WG, and it certainly goes beyond RFC 7250 (still TLS) support. I am not opposed if the shoe fits, but I think that's very new, and would probably need a separate draft. > There seems to be an entire section of the draft that says it does not > represent the consensus of the WG and that maybe it belongs in a > separate document. Section 9 is pointed out as not-conensus by > Section 12. Why is such a section still sitting in a draft that's > supposedly in last call? It seems I neglected to remove the weasel words. Perhaps we can have a consensus call on Digest Agility. > Section 9 also seems to say that if you have two valid TLSA records, > one of which specifies a full key and the other of which uses a > digest, a client can't use the one with a full key even if it is > identical to the key used in the TLS negotiation? That's certainly NOT the intention. I guess the language needs to be more clear. Matching type Full(0) keys are not intended to be skipped even in the presence of digests. Rather, section 9 is about agility between digest algoritms (allowing weaker algorithms to be ignored in the presence of records with stronger algorithms). > It also seems to > say that if the server doesn't publish any TLSA records that use the > client's favorite BetterAlg, then the client should not authenticate > the server, even if the client supports WorseAlg and the server > publishes WorseAlg TLSA records. That also NOT the intention. Again the text applies only when BOTH appear in the TLSA record. The client can ignore some of the published records when ones with a more favoured algorithm are *present*. This is what's implemented in Postfix, and I hope to have similar logic in OpenSSL in the not too distant future. I'll put together more clear language for Section 9 promptly. Thanks again. -- Viktor. From nobody Wed May 13 22:09:53 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4E61B3366 for ; Wed, 13 May 2015 22:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXFKKetWy8mI for ; Wed, 13 May 2015 22:09:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163941A89B1 for ; Wed, 13 May 2015 22:09:50 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 72320283031; Thu, 14 May 2015 05:09:48 +0000 (UTC) Date: Thu, 14 May 2015 05:09:48 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150514050948.GL17272@mournblade.imrryr.org> References: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> <20150513183614.GC17272@mournblade.imrryr.org> <201505140015.t4E0F35B026773@new.toad.com> <20150514010741.GI17272@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150514010741.GI17272@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt (chair guidance request) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 05:09:52 -0000 On Thu, May 14, 2015 at 01:07:41AM +0000, Viktor Dukhovni wrote: > I'll put together more clear language for Section 9 promptly. Below my "signature" is a proposed rewording of Section 9. I believe it says the same thing it said (or at least tried to say) all along, only much more clearly. I'd also like to remove the "weasel words" from Section 12 that disclaim consensus on Digest Agility. This passed through last with no objections and has been in the draft for quite some time. I need guidance from the chairs on how to proceed. [Chairs?] -- Viktor. While specifies multiple digest algorithms, it does not specify a protocol by which the TLS client and TLSA record publisher can agree on the strongest shared algorithm. Such a protocol would allow the client and server to avoid exposure to any deprecated weaker algorithms that are published for compatibility with less capable clients, but should be ignored when possible. We specify such a protocol below. This section defines a protocol for avoiding deprecated digest algorithms when these are published in a peer's TLSA RRset along-side stronger algorithms. A mixture of algorithms may be present in server TLSA records to allow for interoperability with legacy or constrained clients. In particular, this protocol never avoids any RRs with DANE matching type Full(0), as these do not employ any potentially tarnished digest algorithm. Suppose a server's TLSA RRset contains RRs with more than one digest matching type. Suppose also that the server adheres to the requirements of and ensures that each combination of TLSA parameters contains at least one record that matches the server's current certificate chain (or raw public keys). Under the above assumptions it suffices for the client to identify a most preferred digest algorithm among those published in the TLSA RRset, and process only records that algorithm in addition to any records with matching type Full(0). To make digest algorithm agility possible, all published DANE TLSA RRsets MUST conform to the requirements of . With servers publishing compliant TLSA RRsets, TLS clients MAY, for each combination of usage and selector, ignore all digest-based RRs except those that employ the strongest digest algorithm. The client then processes only any records with matching type Full(0) and those with the best published digest algorithm. The ordering of digest algorithms by strength is not specified in advance; it is entirely up to the TLS client. TLS client implementations SHOULD make the digest algorithm preference ordering a configurable option. TLS clients SHOULD use digest algorithm agility when processing the DANE TLSA records of an TLS server. Algorithm agility is to be applied after first discarding any unusable or malformed records (unsupported digest algorithm, or incorrect digest length). Thus, for each usage and selector, the client SHOULD process only any usable records with a matching type of Full(0) and the usable records whose digest algorithm is considered by the client to be the strongest among usable records with the given usage and selector. From nobody Thu May 14 02:44:59 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C1F1ACEBB for ; Thu, 14 May 2015 02:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d56wwDXp29GH for ; Thu, 14 May 2015 02:44:56 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2E5A1B2E4C for ; Thu, 14 May 2015 02:44:55 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1CBF1209D8 for ; Thu, 14 May 2015 05:44:55 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute4.internal (MEProxy); Thu, 14 May 2015 05:44:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=PDpzioPrO9//Jiq79UeRHCIQg1o=; b=aeaG2X /xgebY297Y5a62x+0PVVTT+jFRNcHkfvQVcTG97SKLVse5IuQjgWJNQFpn6UqDoB J5fR5U57FAuTctxuYA1xvaPYRA+X20T4lxT9bnbqMfoY0M+AsKkesN+cpTpbHF1/ IqS7vY/N+M5rYEiS2v1uMXS5vCsLm+4PGX9vk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=PDpzioPrO9//Jiq 79UeRHCIQg1o=; b=XINAmWUVnG1NoXiuDT7uXE770BYFTr3jfGD/HTySvOJWoJn IJKlbz/u0R8olvXf1zMpp/syNm9OU8cpG8Smuy+0T4Z+55d5LA5owJg4xhLNL3g4 Lh8k84d1qAMLH0xea4VwbKFWk95XM02eByIWadTnXUuReBZfc+PR0sCvZOng= Received: by web6.nyi.internal (Postfix, from userid 99) id D4E8B4A0F4; Thu, 14 May 2015 05:44:54 -0400 (EDT) Message-Id: <1431596694.3274731.268516193.7C170F5C@webmail.messagingengine.com> X-Sasl-Enc: puXP8bjn3dbrbOSNUZHOul5SejzDrvlFLgiVlLbaBb6A 1431596694 From: nudge To: dane@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-e7ca9928 Date: Thu, 14 May 2015 11:44:54 +0200 In-Reply-To: <20150514050948.GL17272@mournblade.imrryr.org> References: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> <20150513183614.GC17272@mournblade.imrryr.org> <201505140015.t4E0F35B026773@new.toad.com> <20150514010741.GI17272@mournblade.imrryr.org> <20150514050948.GL17272@mournblade.imrryr.org> Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt (chair guidance request) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 09:44:58 -0000 On Thu, 14 May 2015, at 07:09 AM, Viktor Dukhovni wrote: > On Thu, May 14, 2015 at 01:07:41AM +0000, Viktor Dukhovni wrote: > > > I'll put together more clear language for Section 9 promptly. > > Below my "signature" is a proposed rewording of Section 9. I > believe it says the same thing it said (or at least tried to say) > all along, only much more clearly. > > I'd also like to remove the "weasel words" from Section 12 that > disclaim consensus on Digest Agility. This passed through last > with no objections and has been in the draft for quite some time. > > I need guidance from the chairs on how to proceed. [Chairs?] Viktor, I've slightly reworded your text for clarity: While specifies multiple digest algorithms, it does not specify a protocol by which the TLS client and TLSA record publisher can agree on the strongest shared algorithm. Such a protocol MUST allow the client and server to avoid exposure to any deprecated weaker algorithms that are published for compatibility with less capable clients, but SHOULD be ignored when possible. We specify such a protocol below. This section defines a protocol for avoiding deprecated digest algorithms when these are published in a peer's TLSA RRset along-side stronger algorithms. A mixture of algorithms MAY be present in server TLSA records to allow for interoperability with legacy or constrained clients. In particular, this protocol never avoids any RRs with DANE matching type Full(0), as these do not employ any potentially tarnished digest algorithm. If a server's TLSA RRset contains RRs with more than one digest matching type and adheres to the requirements of with each combination of TLSA parameters containing at least one record that matches the server's current certificate chain (or raw public keys) then under these circumstances, a client MAY identify its preferred digest algorithm and only process records for that algorithm, in addition to any records with matching type Full(0). To allow for digest algorithm agility, all published DANE TLSA RRsets MUST conform to the requirements of . With servers publishing compliant TLSA RRsets, TLS clients MAY, for each combination of usage and selector, ignore all digest-based RRs except those that employ the strongest digest algorithm. The client then processes only those RRs plus any records with matching type Full(0) The ordering of digest algorithms by strength is not specified in advance; it is entirely up to the TLS client. TLS client implementations SHOULD make the digest algorithm preference ordering a configurable option. TLS clients SHOULD use digest algorithm agility when processing the DANE TLSA records of a TLS server. Any algorithm agility MUST be applied after first discarding any unusable or malformed records (unsupported digest algorithm, or incorrect digest length). Thus, for each usage and selector, the client SHOULD process only usable records whose digest algorithm is considered to be the strongest, as well as any records with a matching type of Full(0). -- Thanks, Ian Maddison From nobody Thu May 14 03:34:07 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C981A009B for ; Thu, 14 May 2015 03:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvKJESDINF9B for ; Thu, 14 May 2015 03:34:03 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6181A0074 for ; Thu, 14 May 2015 03:34:03 -0700 (PDT) Received: by wgin8 with SMTP id n8so70693104wgi.0 for ; Thu, 14 May 2015 03:34:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ErQy+5z0RpWb9mVJdjKFHo/0yb3Li6ChSkki3aQISJU=; b=UxPXkry2xytxeTmBAjFmc5PQ1FFtJI+oTegNAJ6MEmHCHcIR2C7p9a8LW8EZKztonr nY6NPC5ULD98jTTRj8PpqTPrJg3MbFVVL2bVTeCulsTW+zd/lR2acbSpAbe7SHY6OS/a AtZ9uU9U2IPx/rAmIMMyLOqoDMPzve3202H0r8/TZnS/pHAJ/OlePSgzUFhAylTzFGPb GuyVH2WAtGe4WNVcsSM3wNsB6u7lsJ5gA174712wsgPW8JB5UNI84lN3jJZtrescqhhh oAN76P0K1ivoCNeP5oNF7xlVRpnKxsKqCP+75j2T9PLVFOWtodSCoE2gJzBATR/8TBEk O9pw== X-Gm-Message-State: ALoCoQlvNGsm4kYxJurAkFCWnkaZXScTlBldcs/+Pm22YhoKB81B1ai1eZ8am6ZLme3ubcbnr0bW MIME-Version: 1.0 X-Received: by 10.180.101.65 with SMTP id fe1mr46806021wib.22.1431599641838; Thu, 14 May 2015 03:34:01 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Thu, 14 May 2015 03:34:01 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 May 2015 12:34:01 +0200 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] WGLC for draft-ietf-dane-ops-07 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 10:34:05 -0000 Dear DANE WG, Olafur are at RIPE and had a chance to chat about this. This WGLC has concluded. We think that we have enough review, and see consensus for publishing (after Viktor has had a chance to address the comments). We would have liked to get even more comments, but the document has had significant discussion over its lifecycle. Thank you for your feedback. W On Mon, Apr 27, 2015 at 6:14 PM, Warren Kumari wrote: > Dear DANE WG, > > The authors of draft-ietf-dane-ops have indicated that they believe > that the document is ready, and have asked for Working Group Last Call > (actually, they requested this a while back, we'd delayed while doing > toe other docs...) > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ > > Please review this draft to see if you think it is ready for > publication and send comments to the list, clearly stating your view. > > This WGLC ends Mon 11-May-2015. > > > In addition, to satisfy RFC 6702 ("Promoting Compliance with > Intellectual Property Rights (IPR)"): > Are you personally aware of any IPR that applies to > draft-ietf-dane-ops? If so, has this IPR been disclosed in compliance > with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more > details.) > > Thanks, > Warren Kumari > (as DANE WG co-chair) > > -- > 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. > ---maf -- 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. ---maf From nobody Thu May 14 17:56:52 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F55B1A9145 for ; Thu, 14 May 2015 17:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.461 X-Spam-Level: X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_pIoU_mueag for ; Thu, 14 May 2015 17:56:47 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA2C1A896E for ; Thu, 14 May 2015 17:56:47 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id t4F0uk5B028009; Thu, 14 May 2015 17:56:46 -0700 Message-Id: <201505150056.t4F0uk5B028009@new.toad.com> To: dane@ietf.org, gnu@toad.com In-reply-to: <20150514010741.GI17272@mournblade.imrryr.org> References: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> <20150513183614.GC17272@mournblade.imrryr.org> <201505140015.t4E0F35B026773@new.toad.com> <20150514010741.GI17272@mournblade.imrryr.org> Comments: In-reply-to Viktor Dukhovni message dated "Thu, 14 May 2015 01:07:41 -0000." Date: Thu, 14 May 2015 17:56:46 -0700 From: John Gilmore Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 15 May 2015 00:56:51 -0000 > Do you have specific suggested language? It might reduce the number > of back and forths if you're willing to make the first step in the > desired direction. Sure! I submitted a whole short I-D that had no wording EXCEPT for this issue. It's enclosed below. John INTERNET-DRAFT J. Gilmore DANE Working Group Electronic Frontier Foundation Intended status: Proposed Standard July 3, 2014 Expires: December 31, 2014 Updates: 6698 (if approved) Authenticating Raw Public Keys with DANE TLSA draft-ietf-dane-rawkeys-00 Abstract This document standardizes how the Domain Name System can authenticate Raw Public Keys. Transport Level Security now has the option to use Raw Public Keys, but they require some form of external authentication. The document updates RFC 6698 to allow the Domain Name System to standardize the authentication of more types of keying material. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents J. Gilmore Expires December 31, 2014 [Page 1] INTERNET DRAFT Raw Public Keys with DANE TLSA July 3, 2014 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1 Background and Introduction The Internet uses many kinds of encryption, and many kinds of keying material. These keys are authenticated in an attempt to prove that the public keys used in communication are the correct keys needed to interact with a particular server or client across the Internet. The Domain Name System (DNS) [RFC1034, RFC1035] provides a globally distributed database for brief information about names used in the Internet. The DNS Security Extensions (DNSSEC) [RFC4033, RFC4034, RFC4035] provide authentication for this database, proving whether the information in the DNS was truly published by the owner of the associated domain name. Transport Level Security (TLS) [RFC5246] and Datagram TLS (DTLS) [RFC6347] define a protocol that protects an Internet datastream or a series of datagrams from eavesdropping and modification. They initially used certificates in PKIX [RFC 5280] formats to store their keying material, and authenticated them via a series of trust anchors embedded in client applications. Domain name system Authentication of Named Entities (DANE) provides a way to store application level public keys in the DNS and authenticate them using DNSSEC. The DANE TLS Authentication (TLSA) resource record [RFC6698] initially provided authentication for the PKIX certificates used in TLS and DTLS. 1.1 Summary of Changes This document extends TLSA records to be able to authenticate more kinds of keying material than PKIX certificates. Protocols can then use their keying material with DANE by standardizing new forms of TLSA records. As a first example of such a new form, this document extends DANE to provide authentication for Raw Public Keys. Raw Public Keys are used in place of PKIX certificates in an extension to TLS and DTLS [RFC7250]. Client applications using Raw Public Keys with TLS or DTLS can use DNSSEC to prove whether those public keys were truly published by the owner of the domain name whose server they are J. Gilmore Expires December 31, 2014 [Page 2] INTERNET DRAFT Raw Public Keys with DANE TLSA July 3, 2014 accessing. 1.2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2 Extending TLSA records to support non-PKIX keying material This document relaxes the restriction that TLSA records can only authenticate PKIX certificates (RFC 6698, section 1.3). The DANE protocol and TLSA records can now apply to encryption keying material in general. This protocol and record type continue to apply to PKIX [RFC5280] certificates, but new standards are free to define non-PKIX keying material formats. Wherever the term "certificate" is used in RFC 6698 to refer to fields in the TLSA record, this document extends it to refer more generally to "keying material". Thus the "certificate usage" field can be thought of as a "keying material usage" field, the "certificate association data" can now be used as "keying material association data", etc. In addition, this document relaxes the requirement that certificate usage value 3 can only be used for PKIX format certificates (RFC 6698, section 2.1.1). Certificate usage 3 can now be used with any standardized keying material format. Certificate usages 0, 1 and 2 remain restricted to apply only to PKIX-formatted certificates in DER encoding [X.690]. 3 Supporting Raw Public Keys in TLSA records This document extends the DANE TLSA record definition to allow TLSA records to describe raw public keys as well as PKIX certificates. This extension does not define any new field values; it merely defines how existing fields are processed when being used with raw public keys, such as those provided by TLS and DTLS servers. There are two different ways to use raw public keys in TLSA records. One is to store the public key itself, so that it can be accessed directly from the DNS. The second is to store a hash of the public key, so that a public key obtained in some other way can be authenticated via the DNS. These cases are distinguished by the matching type field in the TLSA record. When a raw public key is to be stored in a TLSA record, the record MUST specify a certificate usage / keying material usage of 3 J. Gilmore Expires December 31, 2014 [Page 3] INTERNET DRAFT Raw Public Keys with DANE TLSA July 3, 2014 (domain-provided), a selector of 1 (SubjectPublicKeyInfo), and a matching type of 0. The SubjectPublicKeyInfo structure that holds the public key is placed in the certificate association / keying material association data field. This SubjectPublicKeyInfo structure MUST be encoded in DER encoding [X.660] of Abstract Syntax Notation One (ASN.1) [X.208]. It is identical to the SubjectPublicKeyInfo structure that is described in RFC 3279 [RFC3279], which is a used as a component of PKIX certificates. It is identical to the SubjectPublicKeyInfo structure that is used in TLSA records that use a selector value of 1 and a matching type of 0 to match PKIX certificates. It contains an algorithm identifier, any optional parameters needed with that algorithm identifier, and the public key itself. When a raw public key (that was obtained in some other way, such as in a TLS or DTLS transaction) is to be merely matched by a TLSA record, matching type 0 MAY be used, or matching types other than 0 MAY also be used, by placing the hash value of the SubjectPublicKeyInfo structure into the certificate association / keying material association data. This document extends the meaning of the certificate usage / keying material usage value of 3 (from RFC 6699 section 2.1.1) by defining how the TLSA record is used by a client communicating with a TLS or DTLS server that uses raw public keys. This extension adds to, rather than replacing, the definition of certificate usage 3 with TLS or DTLS servers that use PKIX certificates. 3 -- Keying material usage 3 is also used to specify a raw public key that MUST match the raw public key presented by the server in TLS or DTLS. When the server provides a raw public key, there is no PKIX certificate and no PKIX validation is done. The server's raw public key MUST match the raw public key provided in the TLSA record. This keying material usage is sometimes referred to as "domain-issued" because it allows a domain administrator to directly certify a domain's public keys. 4 Security Considerations The encoding used in the TLSA resource record for Raw Public Keys is identical to the encoding used to match the public key of a PKIX certificate. This allows a single TLSA record to match both a PKIX certificate used in traditional TLS or DTLS, and to also match a Raw Public Key provided in extended TLS or DTLS. This offers TLS or DTLS servers an easy way to interoperate with both traditional and extended clients. They can use the same public and private key when communicating with either extended or traditional clients. J. Gilmore Expires December 31, 2014 [Page 4] INTERNET DRAFT Raw Public Keys with DANE TLSA July 3, 2014 Since TLSA records use a protocol type and port number as a prefix on the domain name, services that use Raw Public Keys on various ports accessed through the same domain name are free to use different keying material. Using diverse keying material for different services can improve the robustness of the services after a key compromise. For example, email service on port 25 can continue with full security, even after the private key protecting HTTPS service on port 443 has been compromised. This is a tighter binding between public keys and services than that provided by PKIX certificates, which do not distinguish port numbers. When PKIX certificates are authenticated with TLSA usages 0, 1, or 2, a PKIX certificate that was originally used with HTTPS could be used for a man-in-the-middle attack on email service as well, after its corresponding private key has been compromised. This cross-port attack does not work when the domain name uses TLSA usage 3 to authenticate different Raw Public Keys (or PKIX certificates) for the different services on different ports. In the TLS and DTLS protocol, certificate types are often negotiated before the relevant TLSA records are available to the client. Server operators who anticipate using TLSA records to authenticate the server should always ensure that if their server offers support for Raw Public Keys, then their server's domain name(s) SHOULD contain TLSA records that match the public key that the server offers. Failure to publish such TLSA records would otherwise lead to an authentication failure in clients that opt to use Raw Public Keys, even if TLSA records exist that authenticate PKIX certificates with usages 0, 1, or 2. This is not an issue when Raw Public Keys are used with out-of-band non-DANE authentication. When using Raw Public Keys and TLSA records, the security of the domain name system records directly affects the security of the communications protected by TLS or DTLS. If the domain's DNS records are compromised, or the DNS records that delegate name service to this domain are compromised, communications can be blocked, redirected, intercepted, or modified. The DANE TLSA Security Considerations section [RFC6698] provides further details. 5 IANA Considerations In the IANA "TLSA Certificate Usages" registry created by Section 7.2 of RFC 6698, the value "3" ("Domain-issued certificate") should have its short description changed to "Domain-issued keying material", and should have this document added as a reference document. 6 References 6.1 Normative References J. Gilmore Expires December 31, 2014 [Page 5] INTERNET DRAFT Raw Public Keys with DANE TLSA July 3, 2014 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3279] Polk, T., Housley, R., Bassham, L, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6698] Hoffman, P., Schylter, J., "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012. [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., Kivinen, T., "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, May 2014 [X.208] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988. [X.690] "Recommendation ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules J. Gilmore Expires December 31, 2014 [Page 6] INTERNET DRAFT Raw Public Keys with DANE TLSA July 3, 2014 (DER)", July 2002. 6.2 Informative References [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. Authors' Addresses John Gilmore Electronic Frontier Foundation 815 Eddy Street San Francisco, CA 94117 United States EMail: gnu@ietf.toad.com J. Gilmore Expires December 31, 2014 [Page 7] From nobody Thu May 14 18:28:53 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E841B2EC6 for ; Thu, 14 May 2015 18:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.239 X-Spam-Level: ** X-Spam-Status: No, score=2.239 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_BRBL_LASTEXT=1.449, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5kKwh-GPImJ for ; Thu, 14 May 2015 18:28:51 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6611B2EC3 for ; Thu, 14 May 2015 18:28:50 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id t4F1Sn5B029469 for ; Thu, 14 May 2015 18:28:49 -0700 Message-Id: <201505150128.t4F1Sn5B029469@new.toad.com> To: dane@ietf.org In-reply-to: <20150514010741.GI17272@mournblade.imrryr.org> References: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> <20150513183614.GC17272@mournblade.imrryr.org> <201505140015.t4E0F35B026773@new.toad.com> <20150514010741.GI17272@mournblade.imrryr.org> Comments: In-reply-to Viktor Dukhovni message dated "Thu, 14 May 2015 01:07:41 -0000." Date: Thu, 14 May 2015 18:28:49 -0700 From: John Gilmore Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 15 May 2015 01:28:52 -0000 > I don't see any HTTPS requirement in 6698, just TLS. Thus, SMTP > with STARTTLS on port 25 is using TLSA records, as is XMPP. Right. > What additional protocols over TCP that employ certificates, but not > TLS did you have in mind? Well, the obvious ones are IPSEC, OpenPGP, and SSH. VoIP and other chat protocols are other obvious apps, though crypto for them is currently fragmented (partly as a result of a lack of good key distribution). We have people working on drafts and/or implementations for various of these protocols, but the base document still inappropriately says "this can only be used for TLS". SSH has its own keying record (SSHFP, RFC 4255) but it only provides for communicating a fingerprint, not for the actual public key. DANE could be used to publish the entire public key if desired; and SSHFP doesn't seem particularly popular. Once people get used to publishing DANE keys for TLS, they might well be happy to publish DANE keys for SSH too. I thought the idea of your draft's "raw public key" text is to eliminate the requirement for certificates, so why ask about protocols that use certificates? There never was a requirement for TCP, considering DTLS doesn't use it and DTLS was in RFC 6698 (see section 3). In general I don't think that IETF standards should be written to limit their applicability to a single application. In 1985 I could've written the BOOTP spec (RFC 951) to insist that people should never use it for anything but the narrow application it was intended for (helping diskless workstations boot up from their server). Happily, Bill Croft and I didn't, and almost 10 years later, someone else built DHCP on top of BOOTP. Now billions of cellphones use DHCP to get an IP address when they connect to a WiFi access point. Why would I have wanted to rule out that outcome? Perhaps in some crabbed attempt to constrain competitors so I could sell more diskless workstations? DANE could be widely usable to provide access to crypto keys and authentication thereof for almost ANY kind of crypto protocol. But if the working group that designed it insists that it's "only to be used to support our favorite toys and no others," then people looking for a crypto key access / authentication protocol will go elsewhere. Who needs the hassle of adopting a protocol where you have to fight all the time with the designers over the simplest things? Protocols, especially poor ones, are easy enough for new implementers to design, that we should put few barriers in the way of re-using an existing protocol that has stood the test of time. John From nobody Thu May 14 22:12:53 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39D21A8A70 for ; Thu, 14 May 2015 22:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyH3RJmaMNOV for ; Thu, 14 May 2015 22:12:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F43D1A8A63 for ; Thu, 14 May 2015 22:12:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3CFED283032; Fri, 15 May 2015 05:12:48 +0000 (UTC) Date: Fri, 15 May 2015 05:12:48 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150515051248.GV17272@mournblade.imrryr.org> References: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> <20150513183614.GC17272@mournblade.imrryr.org> <201505140015.t4E0F35B026773@new.toad.com> <20150514010741.GI17272@mournblade.imrryr.org> <201505150128.t4F1Sn5B029469@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201505150128.t4F1Sn5B029469@new.toad.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 05:12:51 -0000 On Thu, May 14, 2015 at 06:28:49PM -0700, John Gilmore wrote: > > What additional protocols over TCP that employ certificates, but not > > TLS did you have in mind? Sorry about that, I should have included UDP also, as TLSA records include the transport layer protocol in the owner label, so I don't see any reason to exclude DTLS over UDP. > Well, the obvious ones are IPSEC, OpenPGP, and SSH. Does it make sense to specify IPSEC keys on a port by port basis? And if so, how does one distinguish between an application willing to talk TLS on a given port, from an O/S stack willing to do IPsec? This is important, because the keys are not necessarily available to both, and client applications may insist on TLS, when the TLSA record is hypothetically intended to be used with IPSEC. So I'm fairly sure that IPSEC requires a separate record type (not TLSA). I believe Paul Wouters is doing some work on DANE and IPSEC, so I'll further discussion to him. Similarly, PGP is not a transport protocol, and there are separate efforts to use DANE for S/MIME and PGP, but with new records distinct from TLSA. Which leaves SSH. SSH is connecting to a transport endpoint, so if someone wanted to standardize SSH with TLSA records (and possibly even DANE-TA(2) CAs?), that might be possible, despite the fact that the security protocol is neither TLS nor DTLSA. I think such an extension of TLSA can be added at that time if it makes more sense to overload TLSA than introduce a dedicated RRtype. Any security protocol that supports "2 0 1" TLSA records has to deal with X.509 certs and trust anchors and certificate chains, and are we really going to design more of these that are not TLS/DTLS? If it only supports "3 1 1" then perhaps TLSA is not the most appropriate RRtype. So I'm with you on DTLS, but I am rather sceptical about extending the TLSA RRtype much more broadly. It is easy enough to write up a spec for a new RRtype that applies to some other (than TLS/DTLS) transport security mechanism, and such a spec would be able to omit features of TLSA that are a poor fit. > SSH has its own keying record (SSHFP, RFC 4255) but it only provides > for communicating a fingerprint, not for the actual public key. > DANE could be used to publish the entire public key if desired; and > SSHFP doesn't seem particularly popular. Largely (catch-22 perhaps) because DNSSEC is not yet terribly popular. And there's not too much demand for ad-hoc inter-domain SSH. I don't SSH to google.com, but I send them email and visit their website. > Once people get used to > publishing DANE keys for TLS, they might well be happy to publish > DANE keys for SSH too. If DANE for SMTP helps to drive DNSSEC adoption, perhaps more folks will publish SSHFP, I don't see a compelling case for TLSA with SSH, the fingerprints are really good enough, the main obstacle is DNSSEC not lack of support for publishing the full key. > I thought the idea of your draft's "raw public key" text is to > eliminate the requirement for certificates, so why ask about protocols > that use certificates? It is to allow the use of RFC7250 raw public keys (no certificates), but still at this time in the context of TLS (or DTLS). > In general I don't think that IETF standards should be written to > limit their applicability to a single application. Indeed, thus DANE TLSA for SMTP, XMPP, HTTP and also application protocols that use SRV records with TLS (IMAP, ...). > In 1985 I could've > written the BOOTP spec (RFC 951) to insist that people should never > use it for anything but the narrow application it was intended for > (helping diskless workstations boot up from their server). Happily, > Bill Croft and I didn't, and almost 10 years later, someone else built > DHCP on top of BOOTP. Now billions of cellphones use DHCP to get an > IP address when they connect to a WiFi access point. Why would I have > wanted to rule out that outcome? Perhaps in some crabbed attempt to > constrain competitors so I could sell more diskless workstations? Many thanks for all those diskless Sun3/50's by the way! They got me started down my eventual career path. > DANE could be widely usable to provide access to crypto keys and > authentication thereof for almost ANY kind of crypto protocol. Indeed, and thus there's work on SMIMEA, OPENGPGKEY, ... and opportunities for any additional RRtypes that make sense. So the key question is whether for a protocol that is neither TLS, nor DTLS and wants to just use bare public keys (ditch the X.509 PKI legacy bloat) does it make sense to use TLSA records with all their permutations of parameters, or might there instead be a new (still application neutral) RRtype for "dane public keys"? _4242._tcp.newcrypto.example.com IN DANEPKEY in which the DANE-EE(3) and SPKI(1) are fixed and implicit? > But if > the working group that designed it insists that it's "only to be used > to support our favorite toys and no others," then people looking for a > crypto key access / authentication protocol will go elsewhere. Well, DANE is not just for TLS. Rather at present, TLSA records are just for TLS/DTLS. So the key question is whether that's a good fit for other use-cases. The draft extends "3 1 1" to work with TLS and RFC7250's bare keys, it is a start. How would one signal which security protocol to use with a particular transport end-point? Having TLSA signal the use of TLS is potentially helpful if the same application also supports other encapsulations. > Who needs the hassle of adopting a protocol where you have to fight all > the time with the designers over the simplest things? Protocols, > especially poor ones, are easy enough for new implementers to design, > that we should put few barriers in the way of re-using an existing > protocol that has stood the test of time. So bottom line, I am actually open to allowing "3 1 1" to be overloaded, for non-TLS "just key" purposes, but honestly sceptical that it is a good fit. It would be good to explore this with a real (non-hypothetical) use-case for an application whose designers/developers want to use DANE for key management. I don't see real obstacles to writing another draft later that updates 6698 again, if that turns out to be a fruitful direction. At present, I think the right thing to do is to make sure that the RFC 7250 use-case is adequately covered. -- Viktor. From nobody Thu May 14 22:25:27 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4391A8ACE for ; Thu, 14 May 2015 22:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrJ0d0K_nWgm for ; Thu, 14 May 2015 22:25:24 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1381A8ACA for ; Thu, 14 May 2015 22:25:24 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 735C6283032; Fri, 15 May 2015 05:25:23 +0000 (UTC) Date: Fri, 15 May 2015 05:25:23 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150515052523.GW17272@mournblade.imrryr.org> References: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> <20150513183614.GC17272@mournblade.imrryr.org> <201505140015.t4E0F35B026773@new.toad.com> <20150514010741.GI17272@mournblade.imrryr.org> <201505150056.t4F0uk5B028009@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201505150056.t4F0uk5B028009@new.toad.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 05:25:26 -0000 On Thu, May 14, 2015 at 05:56:46PM -0700, John Gilmore wrote: > > INTERNET-DRAFT J. Gilmore > DANE Working Group Electronic Frontier Foundation > Intended status: Proposed Standard July 3, 2014 > Expires: December 31, 2014 > Updates: 6698 (if approved) > > > Authenticating Raw Public Keys with DANE TLSA > draft-ietf-dane-rawkeys-00 I have read the draft, thanks. I think that RFC 7250 raw public keys are covered in the same way in draft-ietf-dane-ops via usage DANE-EE(3) selector SPKI(1). For other potential use-cases (i.e. neither TLS nor DTLS), it is not clear how to interpret the TLSA record selector, and what the meanings of the existing certificate usages might be. I'd like to see some success with RFC 7250 + DANE, before we further extend the TLSA RRtype into virgin territory. At the very least there should be a practical use-case against which to measure the soundness of the proposal. RFC7260 is a sound extension, if additional sound extensions come along, I think they can be accomodated at that time. So, I'd like to ask that at this time, we come to closure on whether RFC7250 is adequately supported by the language in draft-ietf-dane-ops. If so, let's get that out the door, and open the floor for discussion of further extensions after that. -- Viktor. From nobody Thu May 14 23:03:40 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB1C1A913E for ; Thu, 14 May 2015 23:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMo25YEzMj0K for ; Thu, 14 May 2015 23:03:36 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65941A912F for ; Thu, 14 May 2015 23:03:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DAC75283032; Fri, 15 May 2015 06:03:32 +0000 (UTC) Date: Fri, 15 May 2015 06:03:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150515060332.GX17272@mournblade.imrryr.org> References: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> <20150513183614.GC17272@mournblade.imrryr.org> <201505140015.t4E0F35B026773@new.toad.com> <20150514010741.GI17272@mournblade.imrryr.org> <20150514050948.GL17272@mournblade.imrryr.org> <1431596694.3274731.268516193.7C170F5C@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1431596694.3274731.268516193.7C170F5C@webmail.messagingengine.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt (chair guidance request) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 06:03:37 -0000 On Thu, May 14, 2015 at 11:44:54AM +0200, nudge wrote: > I've slightly reworded your text for clarity: Thanks, with guidance from the chairs, I'll merge as much as I can. > This section defines a protocol for avoiding deprecated digest > algorithms when these are published in a peer's TLSA RRset > along-side stronger algorithms. A mixture of algorithms MAY be > present in server TLSA records to allow for interoperability with > legacy or constrained clients. I don't think that the "MAY" above needs to be in RFC 2119 language. I had a lower case "may", in order to discuss a hypothetical. This is not a paragraph that *specifies* allowed server behaviour. However, if "MAY" really is better, it does not make a great deal of difference. > If a server's TLSA RRset contains RRs with more than one digest > matching type and adheres to the requirements of > with each combination of TLSA parameters containing at least > one record that matches the server's current certificate chain > (or raw public keys) then under these circumstances, a client MAY > identify its preferred digest algorithm and only process records > for that algorithm, in addition to any records with matching type > Full(0). Here (and this is not the result of your changes) we run into a bit of trouble. Because of the original uncertain status of the consensus on agility, this says "MAY", but a couple of paragraphs the text says that the client SHOULD employ algorithm agility. We need to pick one or the other for both paragraphs. > To allow for digest algorithm agility, all published DANE TLSA RRsets > MUST conform to the requirements of . With > servers publishing compliant TLSA RRsets, TLS clients MAY, for each > combination of usage and selector, ignore all digest-based RRs except > those that employ the strongest digest algorithm. The client then > processes only those RRs plus any records with matching type Full(0) Ditto. > TLS clients SHOULD use digest algorithm agility when processing > the DANE TLSA records of a TLS server. Any algorithm agility MUST > be applied after first discarding any unusable or malformed records > (unsupported digest algorithm, or incorrect digest length). Thus, > for each usage and selector, the client SHOULD process only usable > records whose digest algorithm is considered to be the strongest, > as well as any records with a matching type of Full(0). The above is the final "SHOULD" that is in apparent conflict with the initial "MAYS" that explain potential strategies, which are then upgraded from potential to "SHOULD". So the exposition needs to lose some hedging, and state clearly whether Digest Agility is "MAY" or "SHOULD" throughout. -- Viktor. From nobody Fri May 15 22:42:19 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A170E1B2A2F for ; Fri, 15 May 2015 22:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GollmE-hZUMw for ; Fri, 15 May 2015 22:42:16 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D8F1B2A2D for ; Fri, 15 May 2015 22:42:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DE08D282F50; Sat, 16 May 2015 05:42:11 +0000 (UTC) Date: Sat, 16 May 2015 05:42:11 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150516054211.GF17272@mournblade.imrryr.org> References: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> <20150513183614.GC17272@mournblade.imrryr.org> <201505140015.t4E0F35B026773@new.toad.com> <20150514010741.GI17272@mournblade.imrryr.org> <20150514050948.GL17272@mournblade.imrryr.org> <1431596694.3274731.268516193.7C170F5C@webmail.messagingengine.com> <20150515060332.GX17272@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150515060332.GX17272@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt (chair guidance request) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 05:42:17 -0000 On Fri, May 15, 2015 at 06:03:32AM +0000, Viktor Dukhovni wrote: > On Thu, May 14, 2015 at 11:44:54AM +0200, nudge wrote: > > > I've slightly reworded your text for clarity: > > Thanks, with guidance from the chairs, I'll merge as much as I can. Inspired by the proposed improvement, the below takes a stab at further clarity and elimination of redundancy. I realize it is late in the process, so guidace on whether/when/how to improve this section would be helpful. New section 9 text below the "signature" line. With Section 9 ideally no longer under a cloud of uncertainty, we would also update section 12: OLD: In , we propose a digest algorithm agility protocol. [Note: This section does not yet represent the rough consensus of the DANE working group and requires further discussion. Perhaps this belongs in a separate document.] NEW: In , we specify a digest algorithm agility protocol. -- Viktor. While specifies multiple digest algorithms, it does not specify a protocol by which the client and TLSA record publisher can agree on the strongest shared algorithm. Such a protocol allows the client and server to avoid exposure to deprecated weaker algorithms that are published for compatibility with less capable clients, but which SHOULD be avoided when possible. We specify such a protocol below. This section defines a protocol for avoiding deprecated digest algorithms when these are published in a peer's TLSA RRset alongside stronger digest algorithms. Note that this protocol never avoids RRs with DANE matching type Full(0), as these do not employ a digest algorithm that might some day be weakened by cryptanalysis. The ordering of digest algorithms by strength is not specified in advance; it is entirely up to the client. Client implementations SHOULD make the digest algorithm preference ordering a configurable option. To make digest algorithm agility possible, all published DANE TLSA RRsets MUST conform to the requirements of . Clients SHOULD use digest algorithm agility when processing the peer's DANE TLSA records. Algorithm agility is to be applied after first discarding any unusable or malformed records (unsupported digest algorithm, or incorrect digest length). For each usage and selector, the client SHOULD process only any usable records with a matching type of Full(0) and the usable records whose digest algorithm is considered by the client to be the strongest among usable records with the given usage and selector. Example: a client implements digest agility and prefers SHA2-512(2) over SHA2-256(1), while the server publishes an RRset that employs both digest algorithms as well as a Full(0) record.
_25._tcp.mail.example.com. IN TLSA 3 1 1 ( 3FE246A848798236DD2AB78D39F0651D 6B6E7CA8E2984012EB0A2E1AC8A87B72 ) _25._tcp.mail.example.com. IN TLSA 3 1 2 ( D4F5AF015B46C5057B841C7E7BAB759C BF029526D29520C5BE6A32C67475439E 54AB3A945D80C743347C9BD4DADC9D8D 57FAB78EAA835362F3CA07CCC19A3214 ) _25._tcp.mail.example.com. IN TLSA 3 1 0 ( 3059301306072A8648CE3D020106082A 8648CE3D0301070342000471CB1F504F 9E4B33971376C005445DACD33CD79A28 81C3DED1981F18E7AAA76609DD0E4EF2 8265C82703030AD60C5DBA6FB8A9397A C0FCF06D424C885D484887 )
In this case the client SHOULD accept a server public key that matches either the "3 1 0" record or the "3 1 2" record, but SHOULD not accept keys that match only the weaker "3 1 1" record. From nobody Sat May 16 11:36:04 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DE11A0266; Sat, 16 May 2015 11:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrR9hCI2a5wI; Sat, 16 May 2015 11:35:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1BD1A0250; Sat, 16 May 2015 11:35:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150516183556.17983.40412.idtracker@ietfa.amsl.com> Date: Sat, 16 May 2015 11:35:56 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-17.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 18:36:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : SMTP security via opportunistic DANE TLS Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-smtp-with-dane-17.txt Pages : 32 Date : 2015-05-16 Abstract: This memo describes a downgrade-resistant protocol for SMTP transport security between Mail Transfer Agents (MTAs) based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 16 11:41:04 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00831A0276 for ; Sat, 16 May 2015 11:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgUC2W67DDYk for ; Sat, 16 May 2015 11:41:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D58D1A0273 for ; Sat, 16 May 2015 11:41:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 23B76283015; Sat, 16 May 2015 18:41:01 +0000 (UTC) Date: Sat, 16 May 2015 18:41:01 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150516184100.GI17272@mournblade.imrryr.org> References: <20150516183556.17983.40412.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150516183556.17983.40412.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-17.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 18:41:03 -0000 On Sat, May 16, 2015 at 11:35:56AM -0700, internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-17 Editorial changes in response to GEN-ART review. -- Viktor. From nobody Sun May 17 09:55:36 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272671A6F22 for ; Sun, 17 May 2015 09:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.338 X-Spam-Level: X-Spam-Status: No, score=0.338 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dwvqj-elNFnX for ; Sun, 17 May 2015 09:55:33 -0700 (PDT) Received: from mail.zash.se (sphyrna.zash.se [IPv6:2001:470:28:559::]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37381A6EE0 for ; Sun, 17 May 2015 09:55:33 -0700 (PDT) Received: from [IPv6:2001:470:def1:0:36:aad2:7912:a40a] (unknown [IPv6:2001:470:def1:0:36:aad2:7912:a40a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zash) by mail.zash.se (Postfix) with ESMTPSA id B15E5619EF; Sun, 17 May 2015 18:55:30 +0200 (CEST) Message-ID: <5558C801.7030304@zash.se> Date: Sun, 17 May 2015 18:55:29 +0200 From: Kim Alvefur User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: DANE WG OpenPGP: id=3E52119EF853C59678DBBF6BADED9A77B67AD329; url=http://zash.se/~zash/pubkey.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sShumA6tvu80Gx2ejs4n9njbhPMeOw4Aa" Archived-At: Cc: georg@op-co.de Subject: [dane] DANE-SRV, SNI functional equivalent and XMPP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 16:55:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sShumA6tvu80Gx2ejs4n9njbhPMeOw4Aa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello list! Georg Lukas noted that section 4.1 says, in the context of XMPP, to use to=3D'xmpp23.hosting.example.net' in the stream header, as that is the "functional equivalent" of SNI in XMPP. However, that conflicts with the current semantics of 'to' being the service domain name to the server host name. That will break many, if not all, deployed servers. The server should know what certificate to use for the indicated domain name. http://tools.ietf.org/html/draft-ietf-dane-srv-14#section-4.1 --=20 Kim "Zash" Alvefur --sShumA6tvu80Gx2ejs4n9njbhPMeOw4Aa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJVWMgBAAoJEK3tmne2etMpvMsP/RfFzlCn/4Tq+zWX9cUsKz9m J+Of1tlZ6Xcvk18nUgn1X9zYEG9xHgs/hMUeGmNoFZV6XM5reTQCJ8MWHs2Jj1b7 2nNzYuIwK32zkliaCAVXkJ1nnWisgMA0rPwvIk2Z3jcFjEXkJc7FoXWe+Hx29lVo UH/aXjxejXblY659v77jYvcWx44P1tSFP48GvUNBgVq7jRdYEuovk+eKHhw85K/L f/hl1WEelXUAJ677fjmbeIXZ0BGWQayZn5sjFftx52RGCpwG8ElJRMgGk2btM32P EkVKJwbRv2RSWsQAly3CTLA1r8soHQ4fDSemZs55HMXebsYSNSTInbUs5GY6oIna 49+SFoQLRCdnbSAyim1rAzw6PiylIsnzFoAFKVHyaMbIZFk/zE+Se2TYaO6tSDHw sZu1QyXfyB28Wdb/Kt9V32/EiozQ1jnUrq1FGsJB03JfNJOIgowt2o5hg29rcAsB QJ99xorJ9biavMGxV7z18Vw3+l0BKvSr96V0ZTIbHgl8NtdqjemqthAC9bpfyZkL EMk0fbGffcAqm3XpgMnqBEfiLpOy2GVQ7AIRLRgcGH8mT/6ZPkCdq01VetSkmooG uhwU2Qzt4UVp5prgINvu1qH4CmZqBDzjBdUGMI3h+VcssLdlaiGQPp8GNWFoWzLL bjAEqukWoaU2P465rSd+ =Pnci -----END PGP SIGNATURE----- --sShumA6tvu80Gx2ejs4n9njbhPMeOw4Aa-- From nobody Mon May 18 15:03:59 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A871ACD83 for ; Mon, 18 May 2015 15:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tn-NE4E1FI0W for ; Mon, 18 May 2015 15:03:56 -0700 (PDT) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBEFE1A9081 for ; Mon, 18 May 2015 15:03:56 -0700 (PDT) Received: by padbw4 with SMTP id bw4so168761706pad.0 for ; Mon, 18 May 2015 15:03:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WaEdL31zp6tT6WzQdB+MpsAAfpAPqewQpKmVJAaFWtI=; b=a0IqZSgr/89GSEAT/iWjkQGgueUmbEh2trAZqLXGB0sIrmDpw9+yw4gKEmH1dh+2oa JtndX8IRQwmFNPrYH2TaACVExDjBjgzeyArm0hutQdzh9kHFtVGhKT0l4nwHmiwWBrhI fbZjbfgKkkQT+html838+dBtKz1paZdeGVEIzBN/tWvuOy40sxMC0dvWUN4xloEU5eE0 ocQuFwoi7a+9sOdMXICmfp9RDmRpjq6RsnrvT8sKuGrs+0XwnxOp033B2KKdbrr/KApD 6i4Y+hvRndJcnI1LxC3xhkjEZIGb4pQdA+b63JbqkXZWUwsByY0knBawIglJBBEh1Mpi LOpQ== X-Gm-Message-State: ALoCoQmjQiP+itPn8UB0s9LpWPR2TdofnwmBDUdxuEUs58LWPWaGxKnB3igBSnY/mSgF/dV8LKxq X-Received: by 10.70.24.130 with SMTP id u2mr48287279pdf.147.1431986636466; Mon, 18 May 2015 15:03:56 -0700 (PDT) Received: from aither.local ([2620:101:80fc:232:28e6:232b:b0e:4a4c]) by mx.google.com with ESMTPSA id a11sm11006866pdj.54.2015.05.18.15.03.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 May 2015 15:03:55 -0700 (PDT) Message-ID: <555A61CA.2020108@andyet.net> Date: Mon, 18 May 2015 15:03:54 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <5558C801.7030304@zash.se> In-Reply-To: <5558C801.7030304@zash.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 18 May 2015 22:03:58 -0000 On 5/17/15 9:55 AM, Kim Alvefur wrote: > Hello list! Hi Zash! > Georg Lukas noted that section 4.1 says, in the context of XMPP, to use > to='xmpp23.hosting.example.net' in the stream header, as that is the > "functional equivalent" of SNI in XMPP. However, that conflicts with > the current semantics of 'to' being the service domain name to the > server host name. That will break many, if not all, deployed servers. > The server should know what certificate to use for the indicated domain > name. > > http://tools.ietf.org/html/draft-ietf-dane-srv-14#section-4.1 Hmm. First, all draft-ietf-dane-srv says is that you don't need to use SNI in XMPP because we already have a way for the TLS client to specify which domain name it expects of the TLS server, i.e., the 'to' address of the initial stream header. Second, draft-ietf-xmpp-dna is the document that specifies the behavior of XMPP entities. So IMHO this is a topic for the XMPP WG list, not the DANE WG list. I'll forward this message to that list and continue the conversation there. :-) Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue May 19 04:45:35 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D6F1B2E17 for ; Tue, 19 May 2015 04:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JRKVacJYgaN for ; Tue, 19 May 2015 04:45:32 -0700 (PDT) Received: from mail.zash.se (sphyrna.zash.se [IPv6:2001:470:28:559::]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBA71B2E13 for ; Tue, 19 May 2015 04:45:31 -0700 (PDT) Received: from [IPv6:2001:470:def1:0:f94f:c3f6:287:7ae2] (unknown [IPv6:2001:470:def1:0:f94f:c3f6:287:7ae2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zash) by mail.zash.se (Postfix) with ESMTPSA id 16C6D60CCA; Tue, 19 May 2015 13:45:28 +0200 (CEST) Message-ID: <555B224D.20709@zash.se> Date: Tue, 19 May 2015 13:45:17 +0200 From: Kim Alvefur User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dane@ietf.org References: <5558C801.7030304@zash.se> <555A61CA.2020108@andyet.net> In-Reply-To: <555A61CA.2020108@andyet.net> OpenPGP: id=3E52119EF853C59678DBBF6BADED9A77B67AD329; url=http://zash.se/~zash/pubkey.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xwWV5gELpN3WVRc4E3wrVGtqJPlqpuK4A" Archived-At: Cc: georg@op-co.de Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 11:45:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xwWV5gELpN3WVRc4E3wrVGtqJPlqpuK4A Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-05-19 00:03, Peter Saint-Andre - &yet wrote: > On 5/17/15 9:55 AM, Kim Alvefur wrote: >> Hello list! >=20 > Hi Zash! >=20 >> Georg Lukas noted that section 4.1 says, in the context of XMPP, to us= e >> to=3D'xmpp23.hosting.example.net' in the stream header, as that is the= >> "functional equivalent" of SNI in XMPP. However, that conflicts with >> the current semantics of 'to' being the service domain name to the >> server host name. That will break many, if not all, deployed servers.= >> The server should know what certificate to use for the indicated domai= n >> name. >> >> http://tools.ietf.org/html/draft-ietf-dane-srv-14#section-4.1 >=20 > Hmm. >=20 > First, all draft-ietf-dane-srv says is that you don't need to use SNI i= n > XMPP because we already have a way for the TLS client to specify which > domain name it expects of the TLS server, i.e., the 'to' address of the= > initial stream header. What I tried to say was that this sentence in the draft is confusing and/or wrong in the context of XMPP: SRV is secure: [...] The target server host name is the preferred name for TLS SNI or its equivalent. > Second, draft-ietf-xmpp-dna is the document that specifies the behavior= > of XMPP entities. So IMHO this is a topic for the XMPP WG list, not the= > DANE WG list. I'll forward this message to that list and continue the > conversation there. Right, dane-srv doesn't have authority over XMPP specifics. Thanks :) --=20 Kim "Zash" Alvefur --xwWV5gELpN3WVRc4E3wrVGtqJPlqpuK4A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJVWyJWAAoJEK3tmne2etMpOi4P/RMzIFZ5XyAYaovMnp7u9ABC 2RXf73Y6yMlFeNnvgDCu0+OuSqoSWTQHxCg2FEVNyKtn1zVRXbhSbgTtwRye5AG5 HmTLERVTWL2UFT4+0gH+pNAW/9dhUFkBlK9PkfxAdA9G/JClPREn/XjPuE+DOy/7 fmnSAxynwSVObSj4Nist9luqVVTAF+3Rsd0Q9cMX8WHBiXI4Wna952wetADfuMYZ ov/zOsD/gOwlo3wONdnIyn4t7G13Z/ayL82Bo3ntN/OS3oTWrS1KvNjxvh+b9+K5 Rnys2rynjYFaCmk9VNILEx1E7Lkf0Z5n4mATeTRVivzVv0RR2R4U55f1+HA2YFrO az66lbTRUm1otwHSzWOJ6BZLfXoXEX9nvovj5yQT4PDQGWQH1h9z8WAfoLerB4lY AN2rRTueRy/ievbJwJzp3Iczq/XoQorENjhsjWs4r9LLFH+xWYChv93oEHZ/dxWM lHIp4t0GIsNjcECjzaLc/1ytUo1K9YEzv/gZWbHP9T+Je9A/J3abRacVQbzzyHDg xmBs5ztcB7a7ZVBTfaXRw0Z0+yOgI6QzBV0nVR3KC9i8dS6r44pgEqzL/RNsZOHT q0HejV4jbgPqJGHzddHVg6q+vr/crQ7jptxox2M7sl8yMAGEOZGQShg7JqVOv8a8 iL8/eaX9TnImukPwyZN1 =alMC -----END PGP SIGNATURE----- --xwWV5gELpN3WVRc4E3wrVGtqJPlqpuK4A-- From nobody Tue May 19 07:49:43 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EA31B2FD0 for ; Tue, 19 May 2015 07:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gxj-seTXr6u for ; Tue, 19 May 2015 07:49:39 -0700 (PDT) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C5E1B3035 for ; Tue, 19 May 2015 07:46:14 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so27635099pac.2 for ; Tue, 19 May 2015 07:46:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zGJgFKmpgEUpxD68K4yT0LTaTN2l7MFhp22ihu13Tiw=; b=KhYTwJyLNQ+FX2rQ/uo5T2kmySEbdehEUbd36HWHkIRQVNV7u2Kyij8yqTQ5A2xrW9 75hfj2Q8FatZnzyBbqfrlZUOCnzzUN+oG/Ghnp20bUHVXwZ7FxpB7I/m1SqsXmDs9Km2 AaiZ1E3J3yLOLgSjX9ZRuJGdGNAJTjl4DCUa3dQEEkotRQvueCN5iO8zu7L0l193YUbK qcequ11SBIPbc8D37tMdwKWgWnnUBXW5PnkP5UfzH/YU7im8lPZsSLfd0caRmvMop3vr tNfal1fsnetGKECkXCRsw2w9Ygj9CVDovXXo1soGcGp4SCdP375zJVaaa2zqCKPjDKeo MAUg== X-Gm-Message-State: ALoCoQmAZ6UrED0WiDm/S4JcikrpEvID2aw+u+5z+N1aUAu7TLWEnQcUEBsvRBtdt+Bf1uxgXL3s X-Received: by 10.66.66.65 with SMTP id d1mr16463118pat.22.1432046773657; Tue, 19 May 2015 07:46:13 -0700 (PDT) Received: from aither.local ([12.249.93.110]) by mx.google.com with ESMTPSA id ra3sm13329037pbb.23.2015.05.19.07.46.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 07:46:12 -0700 (PDT) Message-ID: <555B4CB3.3020203@andyet.net> Date: Tue, 19 May 2015 07:46:11 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kim Alvefur , dane@ietf.org References: <5558C801.7030304@zash.se> <555A61CA.2020108@andyet.net> <555B224D.20709@zash.se> In-Reply-To: <555B224D.20709@zash.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: georg@op-co.de Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 14:49:41 -0000 On 5/19/15 4:45 AM, Kim Alvefur wrote: > On 2015-05-19 00:03, Peter Saint-Andre - &yet wrote: >> On 5/17/15 9:55 AM, Kim Alvefur wrote: >>> Hello list! >> >> Hi Zash! >> >>> Georg Lukas noted that section 4.1 says, in the context of XMPP, to use >>> to='xmpp23.hosting.example.net' in the stream header, as that is the >>> "functional equivalent" of SNI in XMPP. However, that conflicts with >>> the current semantics of 'to' being the service domain name to the >>> server host name. That will break many, if not all, deployed servers. >>> The server should know what certificate to use for the indicated domain >>> name. >>> >>> http://tools.ietf.org/html/draft-ietf-dane-srv-14#section-4.1 >> >> Hmm. >> >> First, all draft-ietf-dane-srv says is that you don't need to use SNI in >> XMPP because we already have a way for the TLS client to specify which >> domain name it expects of the TLS server, i.e., the 'to' address of the >> initial stream header. > > What I tried to say was that this sentence in the draft is confusing > and/or wrong in the context of XMPP: > > SRV is secure: [...] The target server host name is the preferred name > for TLS SNI or its equivalent. Ah, I see. I think this might be a more generic issue. For context from §4.1, here's the complete text: SRV is insecure: The reference identifiers SHALL include the service domain and MUST NOT include the SRV target server host name (e.g., include "im.example.com" but not "xmpp23.hosting.example.net"). The service domain is the preferred name for TLS SNI or its equivalent. SRV is secure: The reference identifiers SHALL include both the service domain and the SRV target server host name (e.g., include both "im.example.com" and "xmpp23.hosting.example.net"). The target server host name is the preferred name for TLS SNI or its equivalent. I think we can all agree that when SRV is insecure, the client doesn't have a strong binding or "association" (using language from draft-ietf-xmpp-dna) of the service domain to the target server host name, so it needs to use the service domain as the reference identifier. When SRV is secure, the client does have that kind of strong binding or association, so it is OK for the client to seek a match against both the target server host name and the service domain when checking the identifiers in the certificate. Currently, this document states that when SRV is secure, it is preferred for the client to indicate to the server that its reference identifier is the target server host name. (We're assuming that the purpose of the SNI or equivalent is to indicate the client's preferred reference identifier.) If that's wrong for XMPP (and I'm not yet convinced that it is), is it potentially wrong for other application protocols, or even for all application protocols in general? Given that the client can indicate only one reference identifier via SNI or equivalent, yet we're saying that the client actually has two reference identifiers in this case, I wonder whether the best general advice is for to *indicate* the service domain but *accept* both the service domain and the target server host name. I'll check with my co-author on that to see what he thinks, but feedback from others on the list would be appreciated. >> Second, draft-ietf-xmpp-dna is the document that specifies the behavior >> of XMPP entities. So IMHO this is a topic for the XMPP WG list, not the >> DANE WG list. I'll forward this message to that list and continue the >> conversation there. > > Right, dane-srv doesn't have authority over XMPP specifics. > > Thanks :) Sure, let's discuss those specifics (if any) on the XMPP WG list - but see above on whether this might be a generic issue. Thanks for the feedback! Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue May 19 08:08:17 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CC61A8AF3 for ; Tue, 19 May 2015 08:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wC2esrCFxiCD for ; Tue, 19 May 2015 08:08:11 -0700 (PDT) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 317141A9085 for ; Tue, 19 May 2015 08:07:27 -0700 (PDT) Received: by pdea3 with SMTP id a3so29097625pde.2 for ; Tue, 19 May 2015 08:07:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uOpMNAdkPvv6Ek3XbDr4A9QRQVW3QpJhwh3dU3GNLTA=; b=lH/tLeIwFuOxVTrPuiWwRGRcUaUXb/SZ9nGks6MjxzjaqnBteT5qb77GK/ZHJqNr2g eoYjOajUojfzWDjsuVAzomTTdqDs44ECXencyL5Jx0e/VQT92P3xwSxpcURw1dvby+8R TxRNypzq1uDjbhdP6rIcwrpU5BJWXWNux8pwN9PMg3zNBnnkZazDDp1w7U0ECQzm24l/ AswCaZbE2FTAA9iJcvChKwYsAkpozbO7Me+RAyoCRr34aPLKPTAYHSwx4jUBG/7Q4B0S 3NTi56GA8D44M1h/nR0ABTP9YKGzfNIXDCThivXVpuM/4WY0QRDZOLbTDasr2Y7n8USi dmPw== X-Gm-Message-State: ALoCoQmwY1Qn/YMA/55kr5b5uCfgRAngS3Yuuf/1X31aIoaZmPwVX66Q2ZfYKqQGfZcPGURXs+vT X-Received: by 10.70.53.99 with SMTP id a3mr54987125pdp.169.1432048047329; Tue, 19 May 2015 08:07:27 -0700 (PDT) Received: from aither.local ([12.249.93.110]) by mx.google.com with ESMTPSA id ux4sm13361998pbc.61.2015.05.19.08.07.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 08:07:25 -0700 (PDT) Message-ID: <555B51AB.9070303@andyet.net> Date: Tue, 19 May 2015 08:07:23 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kim Alvefur , dane@ietf.org References: <5558C801.7030304@zash.se> <555A61CA.2020108@andyet.net> <555B224D.20709@zash.se> <555B4CB3.3020203@andyet.net> In-Reply-To: <555B4CB3.3020203@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: georg@op-co.de Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 15:08:16 -0000 On 5/19/15 7:46 AM, Peter Saint-Andre - &yet wrote: > On 5/19/15 4:45 AM, Kim Alvefur wrote: >> On 2015-05-19 00:03, Peter Saint-Andre - &yet wrote: >>> On 5/17/15 9:55 AM, Kim Alvefur wrote: >>>> Hello list! >>> >>> Hi Zash! >>> >>>> Georg Lukas noted that section 4.1 says, in the context of XMPP, to use >>>> to='xmpp23.hosting.example.net' in the stream header, as that is the >>>> "functional equivalent" of SNI in XMPP. However, that conflicts with >>>> the current semantics of 'to' being the service domain name to the >>>> server host name. That will break many, if not all, deployed servers. >>>> The server should know what certificate to use for the indicated domain >>>> name. >>>> >>>> http://tools.ietf.org/html/draft-ietf-dane-srv-14#section-4.1 >>> >>> Hmm. >>> >>> First, all draft-ietf-dane-srv says is that you don't need to use SNI in >>> XMPP because we already have a way for the TLS client to specify which >>> domain name it expects of the TLS server, i.e., the 'to' address of the >>> initial stream header. >> >> What I tried to say was that this sentence in the draft is confusing >> and/or wrong in the context of XMPP: >> >> SRV is secure: [...] The target server host name is the preferred name >> for TLS SNI or its equivalent. > > Ah, I see. > > I think this might be a more generic issue. For context from §4.1, > here's the complete text: > > SRV is insecure: The reference identifiers SHALL include the service > domain and MUST NOT include the SRV target server host name (e.g., > include "im.example.com" but not "xmpp23.hosting.example.net"). > The service domain is the preferred name for TLS SNI or its > equivalent. > > SRV is secure: The reference identifiers SHALL include both the > service domain and the SRV target server host name (e.g., include > both "im.example.com" and "xmpp23.hosting.example.net"). The > target server host name is the preferred name for TLS SNI or its > equivalent. > > I think we can all agree that when SRV is insecure, the client doesn't > have a strong binding or "association" (using language from > draft-ietf-xmpp-dna) of the service domain to the target server host > name, so it needs to use the service domain as the reference identifier. > > When SRV is secure, the client does have that kind of strong binding or > association, so it is OK for the client to seek a match against both the > target server host name and the service domain when checking the > identifiers in the certificate. > > Currently, this document states that when SRV is secure, it is preferred > for the client to indicate to the server that its reference identifier > is the target server host name. (We're assuming that the purpose of the > SNI or equivalent is to indicate the client's preferred reference > identifier.) If that's wrong for XMPP (and I'm not yet convinced that it > is), is it potentially wrong for other application protocols, or even > for all application protocols in general? > > Given that the client can indicate only one reference identifier via SNI > or equivalent, yet we're saying that the client actually has two > reference identifiers in this case, I wonder whether the best general > advice is for to *indicate* the service domain but *accept* both the > service domain and the target server host name. > > I'll check with my co-author on that to see what he thinks, but feedback > from others on the list would be appreciated. OK, Matt Miller and I chatted about this over a secure IM protocol. We're both thinking that it's best to always *indicate* the service domain in the SNI or equivalent but *accept* both the service domain and the target server host name during identity checking. Always indicating the service domain minimizes code complexity and reduces the possibility of something going horribly wrong if the client (or underlying DNS library) thinks that SRV is secure when it really isn't. I suggest the following text change: OLD SRV is secure: The reference identifiers SHALL include both the service domain and the SRV target server host name (e.g., include both "im.example.com" and "xmpp23.hosting.example.net"). The target server host name is the preferred name for TLS SNI or its equivalent. NEW SRV is secure: The reference identifiers SHALL include both the service domain and the SRV target server host name (e.g., include both "im.example.com" and "xmpp23.hosting.example.net"). The service domain is still the preferred name for TLS SNI or its equivalent (this reduces code complexity and the possibility of interoperability problems). Given that this document has already been approved for publication, we will need to check this change with Stephen Farrell, the responsible Area Director. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue May 19 11:02:02 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD281A8A5E for ; Tue, 19 May 2015 11:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioot5R3TLljX for ; Tue, 19 May 2015 11:02:00 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92DCC1A8971 for ; Tue, 19 May 2015 11:01:59 -0700 (PDT) Received: by wgjc11 with SMTP id c11so26961660wgj.0 for ; Tue, 19 May 2015 11:01:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=OGNJrR7ERVv9hv7HyVC8rb1GmNwJgYX9QucxPOEIVVs=; b=YSLqpjLrXqhrGb7XOyicDRG57FgUFeCHQpJgbcquxfj+CsvcH+eMVutqcKJmAY4/TF MLeE2naJ8dB32a8vhLV3hguV0fXVM7wEYc5flDgclS9JZY1xNLdfPUnfp5YCJG5NannN +7TeSQj8AJGBsQSE7mujyhYVw8A7bAT90XCrR7xBc34FNOEgIYVvooQ1iqlhbHPhVMN1 OZFvzyIHJajY8ynC73DJsHeZdUPKqHD5513NOsbE1Tz2zrUPX+XgQ4RzzIRHxh8969c+ DRKufs/S5wPEHhGPW3PzSTz+kLnjfnI6sfPydL14bRDUX2OSJ070UoJw7H/mPg34pyXt D7ew== X-Gm-Message-State: ALoCoQlpzAOMlqHqz6CZMPmC2C4OnFVhvfiO0IITF0/XtCa9LaqFacJD5GGVqHtX422BhKpUAbWC MIME-Version: 1.0 X-Received: by 10.180.101.65 with SMTP id fe1mr33628024wib.22.1432058518344; Tue, 19 May 2015 11:01:58 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Tue, 19 May 2015 11:01:58 -0700 (PDT) Date: Tue, 19 May 2015 14:01:58 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dane] Call for agenda items for Prague X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 18:02:01 -0000 Hi all, The Prague IETF meeting is approaching. We have requested some agenda time, please let us know if you would like some time to present. Please also keep in mind that we give time to documents that have had discussion onlist, and that have open issues that will benefit from discussions. W -- 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. ---maf From nobody Tue May 19 11:52:35 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333461A8733 for ; Tue, 19 May 2015 11:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFMIwI6cMD9n for ; Tue, 19 May 2015 11:52:32 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [194.126.158.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30051B3011 for ; Tue, 19 May 2015 11:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-transfer-encoding:content-disposition :content-type:content-type:mime-version:references:message-id :subject:subject:from:from:date:date; s=mail201310; t= 1432061470; x=1433875871; bh=w+El7pRtc0w48DZpU/DXWYuVCAOy57H6lsj lx7fkOTI=; b=XsQvMzvleJanSGSeEsCGHSyrjm6uEBzp7hl/1H+vIOjPR90dL+W fde3GvuWi4DR17RBTVVzJUrd47TUY6FjL0ucMJVHfOzeXTuSzlvqwaH4vNJzKCJy uO7vVmmYtUdiewp2VnL00MovQl1BDqLFqHADhFzhidCeM4wd+agp7kxSCyd9pB+N ohz/OuqjpLKbC9VQa8mEpL3suuOwgCMLMblgcEODkfYvkp1KLJYb1hmB2FPh8v1C zz49bjQJaRUXhaByOWf+XNcgMq5iOMRYB0zm4ypxl96tDJo8duvZlxdRsOEdZFYk 9wJ9iML7zGuy/mPgLjL74Oi4ABr7w6VaOVw== X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (ipb21b2720.dynamic.kabel-deutschland.de [178.27.39.32]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3lrmWf6MJcz2C for ; Tue, 19 May 2015 20:51:10 +0200 (CEST) Date: Tue, 19 May 2015 20:51:09 +0200 From: Patrick Ben Koetter To: dane@ietf.org Message-ID: <20150519185109.GA3232@sys4.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [dane] Call for agenda items for Prague X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 18:52:34 -0000 * Warren Kumari : > Hi all, > > The Prague IETF meeting is approaching. > > We have requested some agenda time, please let us know if you would > like some time to present. > > Please also keep in mind that we give time to documents that have had > discussion onlist, and that have open issues that will benefit from > discussions. I'd be interested to see some progress concerning localparts in OPENPGPKEY and SMIMEA. AFAIK the localpart seems to be the only remaining major issue for both drafts. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Tue May 19 16:24:19 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7F61ACDA4 for ; Tue, 19 May 2015 16:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Vr__I95Xxzo for ; Tue, 19 May 2015 16:24:15 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDEB1ACDA3 for ; Tue, 19 May 2015 16:24:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 975BB283015; Tue, 19 May 2015 23:24:14 +0000 (UTC) Date: Tue, 19 May 2015 23:24:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150519232414.GQ17272@mournblade.imrryr.org> References: <5558C801.7030304@zash.se> <555A61CA.2020108@andyet.net> <555B224D.20709@zash.se> <555B4CB3.3020203@andyet.net> <555B51AB.9070303@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555B51AB.9070303@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 23:24:17 -0000 On Tue, May 19, 2015 at 08:07:23AM -0700, Peter Saint-Andre - &yet wrote: > > SRV is insecure: The reference identifiers SHALL include the service > > domain and MUST NOT include the SRV target server host name (e.g., > > include "im.example.com" but not "xmpp23.hosting.example.net"). > > The service domain is the preferred name for TLS SNI or its > > equivalent. > > > > SRV is secure: The reference identifiers SHALL include both the > > service domain and the SRV target server host name (e.g., include > > both "im.example.com" and "xmpp23.hosting.example.net"). The > > target server host name is the preferred name for TLS SNI or its > > equivalent. > > > >I think we can all agree that when SRV is insecure, the client doesn't > >have a strong binding or "association" (using language from > >draft-ietf-xmpp-dna) of the service domain to the target server host > >name, so it needs to use the service domain as the reference identifier. I disagree. What's missing here, is any dependence on the existence of the associated TLSA records, and client support for DANE (else client would not have checked the TLSA records). When SRV is secure, the client proceeds to check TLSA RRs, otherwise it does not, and reverts to non-DANE behaviour inluding any legacy behaviour for choosing the SNI name. When SRV is secure *AND* TLSA records are found, the client MUST use the TLSA base domain as the SNI name, and MUST look for that domain in the server certificate. Non-DANE servers will not have TLSA records, so they are not affected. The client will also for compatibility with legacy certificate deployments tolerate the service domain as a name in the peer certificate. See the DANE OPS draft description of the redirection use-cases. Also compare with the SMTP draft. > >When SRV is secure, the client does have that kind of strong binding or > >association, so it is OK for the client to seek a match against both the > >target server host name and the service domain when checking the > >identifiers in the certificate. No. This binding along is not enough. The server needs to also publish TLSA records to signal that support for DANE TLS (with secure redirection) is supported by the server. > NEW > SRV is secure: The reference identifiers SHALL include both the > service domain and the SRV target server host name (e.g., include > both "im.example.com" and "xmpp23.hosting.example.net"). The > service domain is still the preferred name for TLS SNI or its > equivalent (this reduces code complexity and the possibility of > interoperability problems). I object. The fix is to delay the decision until the presence of TLSA records has been checked. -- Viktor. From nobody Tue May 19 19:46:14 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4091B2C31 for ; Tue, 19 May 2015 19:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RToTg8xd6gas for ; Tue, 19 May 2015 19:46:11 -0700 (PDT) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DFE41B2C2E for ; Tue, 19 May 2015 19:46:11 -0700 (PDT) Received: by padbw4 with SMTP id bw4so49284282pad.0 for ; Tue, 19 May 2015 19:46:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=m7dTs915iHXCNYbgaoZtDLryJ+DLfdm9hg0nTN7IxJQ=; b=Z35bLQvw3DZ3AkcVWdKUdulOpGaZ5UxQjiS4DqNxxEniD8gZuLrHX9VKKPwdfSw4aK vAp7STiEK4x+RfR9sT+z2An/csicOXkQuae7UxnWfPVLdaM0cWkVxDOd7B0UDbSPZBHM SDlm8Dpsr12LxNNYPrqA1sI1Z860Bb37R+cnc7HsSliQa/dHJRrpNZjD8Tf9SUqMZaXZ taWka0AfKwXP2WkZmubscA1PvsjKeSgWWqWxPzpCE3Xv1Q1rg9fep+ml/yIacDAyFqPA 931+WRvkXjQANVjDuzBzoaSQiHCjg6RnbBNtnqe+j8X2KX7005H+csUarUXm7n6qre8L rCmQ== X-Gm-Message-State: ALoCoQk3iddEkBlmjVq97hxQTZUcdauTd/xSomGCwSKmiAvcYQwrTJgJdYGutntGt6fO5C+E464l X-Received: by 10.68.250.229 with SMTP id zf5mr60353782pbc.158.1432089970622; Tue, 19 May 2015 19:46:10 -0700 (PDT) Received: from aither.local ([12.249.93.110]) by mx.google.com with ESMTPSA id x3sm9518589pbt.93.2015.05.19.19.46.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 19:46:09 -0700 (PDT) Message-ID: <555BF56F.8020103@andyet.net> Date: Tue, 19 May 2015 19:46:07 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <5558C801.7030304@zash.se> <555A61CA.2020108@andyet.net> <555B224D.20709@zash.se> <555B4CB3.3020203@andyet.net> <555B51AB.9070303@andyet.net> <20150519232414.GQ17272@mournblade.imrryr.org> In-Reply-To: <20150519232414.GQ17272@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 20 May 2015 02:46:13 -0000 On 5/19/15 4:24 PM, Viktor Dukhovni wrote: > On Tue, May 19, 2015 at 08:07:23AM -0700, Peter Saint-Andre - &yet wrote: > >>> SRV is insecure: The reference identifiers SHALL include the service >>> domain and MUST NOT include the SRV target server host name (e.g., >>> include "im.example.com" but not "xmpp23.hosting.example.net"). >>> The service domain is the preferred name for TLS SNI or its >>> equivalent. >>> >>> SRV is secure: The reference identifiers SHALL include both the >>> service domain and the SRV target server host name (e.g., include >>> both "im.example.com" and "xmpp23.hosting.example.net"). The >>> target server host name is the preferred name for TLS SNI or its >>> equivalent. >>> >>> I think we can all agree that when SRV is insecure, the client doesn't >>> have a strong binding or "association" (using language from >>> draft-ietf-xmpp-dna) of the service domain to the target server host >>> name, so it needs to use the service domain as the reference identifier. > > I disagree. What's missing here, is any dependence on the existence of > the associated TLSA records, and client support for DANE (else client > would not have checked the TLSA records). > > When SRV is secure, the client proceeds to check TLSA RRs, otherwise > it does not, and reverts to non-DANE behaviour inluding any legacy > behaviour for choosing the SNI name. > > When SRV is secure *AND* TLSA records are found, the client MUST > use the TLSA base domain as the SNI name, and MUST look for that > domain in the server certificate. Non-DANE servers will not have > TLSA records, so they are not affected. The client will also for > compatibility with legacy certificate deployments tolerate the > service domain as a name in the peer certificate. > > See the DANE OPS draft description of the redirection use-cases. > Also compare with the SMTP draft. > >>> When SRV is secure, the client does have that kind of strong binding or >>> association, so it is OK for the client to seek a match against both the >>> target server host name and the service domain when checking the >>> identifiers in the certificate. > > No. This binding along is not enough. The server needs to also publish > TLSA records to signal that support for DANE TLS (with secure redirection) > is supported by the server. > >> NEW >> SRV is secure: The reference identifiers SHALL include both the >> service domain and the SRV target server host name (e.g., include >> both "im.example.com" and "xmpp23.hosting.example.net"). The >> service domain is still the preferred name for TLS SNI or its >> equivalent (this reduces code complexity and the possibility of >> interoperability problems). > > I object. The fix is to delay the decision until the presence of > TLSA records has been checked. Viktor, the text in question is from §4.1, which begins as follows: 4.1. SRV Records Only If the client received zero usable TLSA certificate associations... The whole point of §4.1 is to address the case where we have SRV records and no usable TLSA records. Naturally, the client can't know that it has no usable TLSA records "until the presence of TLSA records has been checked" as you say. I'd agree with you if we were proposing to change text in §4.2, but we're not, so I don't see the force of your objection. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed May 20 01:04:15 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B211A8915 for ; Wed, 20 May 2015 01:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FCF_hXrtVBA for ; Wed, 20 May 2015 01:04:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73241A888E for ; Wed, 20 May 2015 01:04:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 84873282F50; Wed, 20 May 2015 08:04:04 +0000 (UTC) Date: Wed, 20 May 2015 08:04:04 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150520080404.GU17272@mournblade.imrryr.org> References: <5558C801.7030304@zash.se> <555A61CA.2020108@andyet.net> <555B224D.20709@zash.se> <555B4CB3.3020203@andyet.net> <555B51AB.9070303@andyet.net> <20150519232414.GQ17272@mournblade.imrryr.org> <555BF56F.8020103@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555BF56F.8020103@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 08:04:14 -0000 On Tue, May 19, 2015 at 07:46:07PM -0700, Peter Saint-Andre - &yet wrote: [ Sorry, I'm on the road, and cycles are limited. ] > >>NEW > >> SRV is secure: The reference identifiers SHALL include both the > >> service domain and the SRV target server host name (e.g., include > >> both "im.example.com" and "xmpp23.hosting.example.net"). The > >> service domain is still the preferred name for TLS SNI or its > >> equivalent (this reduces code complexity and the possibility of > >> interoperability problems). > > > >I object. The fix is to delay the decision until the presence of > >TLSA records has been checked. > > Viktor, the text in question is from ?4.1, which begins as follows: > > 4.1. SRV Records Only > > If the client received zero usable TLSA certificate associations... In that case, this is a pure legacy use-case, and no incompatible behaviour should be introduced. > The whole point of 4.1 is to address the case where we have SRV records and > no usable TLSA records. Naturally, the client can't know that it has no > usable TLSA records "until the presence of TLSA records has been checked" as > you say. I'd agree with you if we were proposing to change text in 4.2, but > we're not, so I don't see the force of your objection. I did not get a chance to read the text in context. Adding the target name as a secondary indentifier is fine, but indeed the SNI name should not change absent signalling via TLSA RRs. -- Viktor. From nobody Wed May 20 07:15:50 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EEC1A86FC for ; Wed, 20 May 2015 07:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2coBpsBQkrg for ; Wed, 20 May 2015 07:15:47 -0700 (PDT) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6711A8035 for ; Wed, 20 May 2015 07:15:36 -0700 (PDT) Received: by pdea3 with SMTP id a3so70418706pde.2 for ; Wed, 20 May 2015 07:15:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wpirHnb6eIDb6O1uD8+NyfXRJEtVa9gcvVx+ffwzVYQ=; b=HREeGLJJJmAI48D74wH8NUMJwCs7Ro92LSkaWdNsMo7jcwRAtvEE2pFR5i0s1fXjt/ QFWxoiQkVhNAUDqtcIen1Is9hHy1y7ez1BY0vRZg1Dw+Ysre2usUG7Lt5By1eu/qzPi9 dBP5sLc+BlbXLyjqmAyAQv5jIuymg4AisGz6Rdvjkg3o37LOBHlfkSeJQagbGq8yz4+9 m65Rp27qz2FuLOitKUQ1aJMtGGgn0QhvySBZqQsL3Q19SOReDnHFBinuz3nhGb61mqUw jKhy68iG5BotwOlIQMfvQExwceojAGOW+nvOyx0F9AF6qed6k51Xyoy9731XVbxlQ2NG 9FlQ== X-Gm-Message-State: ALoCoQmixGwcYSksUG4z9408WVB/c0PfpSMjmC6hFn5gTdQ+Q4d9zyO0IGRhOGNQ9OopuQtp0AgV X-Received: by 10.70.35.108 with SMTP id g12mr63275075pdj.75.1432131336202; Wed, 20 May 2015 07:15:36 -0700 (PDT) Received: from aither.local ([12.249.93.110]) by mx.google.com with ESMTPSA id k9sm16354583pdp.60.2015.05.20.07.15.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 May 2015 07:15:35 -0700 (PDT) Message-ID: <555C9704.7020000@andyet.net> Date: Wed, 20 May 2015 07:15:32 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <5558C801.7030304@zash.se> <555A61CA.2020108@andyet.net> <555B224D.20709@zash.se> <555B4CB3.3020203@andyet.net> <555B51AB.9070303@andyet.net> <20150519232414.GQ17272@mournblade.imrryr.org> <555BF56F.8020103@andyet.net> <20150520080404.GU17272@mournblade.imrryr.org> In-Reply-To: <20150520080404.GU17272@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 20 May 2015 14:15:48 -0000 On 5/20/15 1:04 AM, Viktor Dukhovni wrote: > On Tue, May 19, 2015 at 07:46:07PM -0700, Peter Saint-Andre - &yet wrote: > > [ Sorry, I'm on the road, and cycles are limited. ] Same here. :-) >>>> NEW >>>> SRV is secure: The reference identifiers SHALL include both the >>>> service domain and the SRV target server host name (e.g., include >>>> both "im.example.com" and "xmpp23.hosting.example.net"). The >>>> service domain is still the preferred name for TLS SNI or its >>>> equivalent (this reduces code complexity and the possibility of >>>> interoperability problems). >>> >>> I object. The fix is to delay the decision until the presence of >>> TLSA records has been checked. >> >> Viktor, the text in question is from ?4.1, which begins as follows: >> >> 4.1. SRV Records Only >> >> If the client received zero usable TLSA certificate associations... > > In that case, this is a pure legacy use-case, and no incompatible > behaviour should be introduced. Yes, agreed. Thus I think it's safest to recommend sending the service domain in both SRV-only, non-TLSA cases, as in the adjusted text above. >> The whole point of 4.1 is to address the case where we have SRV records and >> no usable TLSA records. Naturally, the client can't know that it has no >> usable TLSA records "until the presence of TLSA records has been checked" as >> you say. I'd agree with you if we were proposing to change text in 4.2, but >> we're not, so I don't see the force of your objection. > > I did not get a chance to read the text in context. Adding the target name > as a secondary indentifier is fine, but indeed the SNI name should not > change absent signalling via TLSA RRs. OK, great, then I think we're in agreement. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu May 21 05:26:57 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C351AD26E for ; Thu, 21 May 2015 05:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5P7Jnjx98Vj for ; Thu, 21 May 2015 05:26:54 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C87F91AD248 for ; Thu, 21 May 2015 05:26:54 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 87165283015; Thu, 21 May 2015 12:26:52 +0000 (UTC) Date: Thu, 21 May 2015 12:26:52 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150521122652.GK17272@mournblade.imrryr.org> References: <5558C801.7030304@zash.se> <555A61CA.2020108@andyet.net> <555B224D.20709@zash.se> <555B4CB3.3020203@andyet.net> <555B51AB.9070303@andyet.net> <20150519232414.GQ17272@mournblade.imrryr.org> <555BF56F.8020103@andyet.net> <20150520080404.GU17272@mournblade.imrryr.org> <555C9704.7020000@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555C9704.7020000@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 12:26:56 -0000 On Wed, May 20, 2015 at 07:15:32AM -0700, Peter Saint-Andre - &yet wrote: > >I did not get a chance to read the text in context. Adding the target name > >as a secondary indentifier is fine, but indeed the SNI name should not > >change absent signalling via TLSA RRs. > > OK, great, then I think we're in agreement. Yes, we are. -- Viktor. From nobody Thu May 21 11:09:22 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8151A064C for ; Thu, 21 May 2015 11:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhd5FXvZRDTr for ; Thu, 21 May 2015 11:09:18 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9619B1A036F for ; Thu, 21 May 2015 11:09:18 -0700 (PDT) Received: by wghq2 with SMTP id q2so93738202wgh.1 for ; Thu, 21 May 2015 11:09:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=/LOcg6vL8GsSP97FAzgJj+HL5fG8SL0gWjZTP/8p7Xs=; b=Zoyfm/M2x2ZxCpZxOvJ2g/0UEy4dh9YmZgrVs1Iw6pQzoBWoBsx9/iNyWWUMPFkLU7 v+OeLetYrKrZvCxLUlsCEo8IT7NMQem+t7KKKWWUzqosZJ+Zl3ZmuxKHLNXPpEO/1jBy cm5irlYrdFffKhdYXX2xTG9ZAbPRlKd0MLwubQvBQ5L/tV1k2+4naom/Fbt8V4lBkkuy M/iRkdrN62rM8FFGAa8iwU6njAD6kPD3hZirhthvkxvTpQPrDRmM0araiVOSr31vT1C8 Fk/9SMgDooHdm87o1AuFHhrO63eJAZbsX/cfCkXvVhCkiqaj9yKhmlVTXIP1HQdZmmk8 5m+Q== X-Gm-Message-State: ALoCoQkftplhenWC5wne60ZtXm17FjsxbKARo2IiAYLWWlb/SEWE9nLSf3ypmji9X3RKHTr38KGs MIME-Version: 1.0 X-Received: by 10.180.101.65 with SMTP id fe1mr53684262wib.22.1432231757338; Thu, 21 May 2015 11:09:17 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Thu, 21 May 2015 11:09:17 -0700 (PDT) Date: Thu, 21 May 2015 14:09:17 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dane] NomCom 2015-2016 Call for Volunteers -- please consider volunteering. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 18:09:21 -0000 Hi all, I wanted to make sure that you had all seen the NomCom 2015-2016 Call for Volunteers emails form Harald. This should be viewed as an important responsibility - having a strong IAB and IESG is important to a well functioning IETF. *Please* consider volunteering - and remember, the more people who volunteer, the less likely any one of us is to be selected... ----- The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 7437, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 7437, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are: IETF 88 (Vancouver), \ 89 (London), \ 90 (Toronto), *** ANY THREE! 91 (Honolulu), / 92 (Dallas) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. 255 people volunteered by ticking the box on the IETF 92 registration form. 149 of these have been verified as eligible. I will contact all of these shortly. Thank you for volunteering! The list of people and posts whose terms end with the March 2016 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: No terms expire at this time. IAB: Mary Barnes Joe Hildebrand Ted Hardie Erik Nordmark Brian Trammell Marc Blanchet IESG: Alissa Cooper (ART) Barry Leiba (ART) Brian Haberman (Internet) Benoit Claise (Operations and Management) Alia Atlas (Routing) Kathleen Moriarty (Security) Martin Stiemerling (Transport) The Applications and Real-Time (ART) area is the expected new area resulting from the merge of the APP and RAI areas. All appointments are for 2 years. The ART and Routing areas have 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas have at least one continuing AD. The primary activity for this nomcom will begin in July 2015 and should be completed in January 2016. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF94 (Yokohama) to conduct interviews. Being at IETF93 (Prague) is useful for orientation. Being at IETF95 is not essential. Please volunteer by sending me an email before 11:59 pm CET (UTC +2 hours) June 22, 2015, as follows: To: nomcom-chair-2015@ietf.org Subject: Nomcom 2015-16 Volunteer Please include the following information in the email body: Your Full Name: __________ // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2015/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Harald Alvestrand hta+nomcom@alvestrand.no nomcom-chair-2015@ietf.org -- 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. ---maf From nobody Thu May 21 13:08:40 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE291A7022 for ; Thu, 21 May 2015 13:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCp5b5ieg3d8 for ; Thu, 21 May 2015 13:08:37 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBB41A89A6 for ; Thu, 21 May 2015 13:08:37 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so26699490wic.0 for ; Thu, 21 May 2015 13:08:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=dYxtiKqV8gbymnwaE6COqX2zPuymIMcgNSmAzQUpjVs=; b=erPmbxU5KcRb6/bbvvOjFI04VswJA8ZpnsLfqVmYbdwAGjVeKkNtiZnagI5Id2rn3N i4dQK80sU0Lk2w6dRRD8KCxjP1QBjTT2lcwqad9FPb9nYEli9Lu34l3oEiD0W4FpDI2N qK4QjmZ94QSBRMXZ2lizhkdestzhpKAJUkmheVyZ2BQsKASjCUsdIx5knN/T2DOH8DgP p8VjaFW1ilMKgy+raqrUuzrjxwtkq22K//cNLgnaDi6lpDKWvximJl1G6H9HN+oHaaUQ h7mfVEQFaV6ODKiJJ6ex1MR63SBm+xKmivliZC5gp451viFrmroOO95uIP2iYQ67ZY9T UFoQ== X-Gm-Message-State: ALoCoQkp9khA7KCPdgBsB2I6hRoS9kzMsRIZiqRgE+KLiKn310CEs9TkrZGqIkwRnIAhgZQZmEMN MIME-Version: 1.0 X-Received: by 10.194.201.163 with SMTP id kb3mr8105351wjc.113.1432238915797; Thu, 21 May 2015 13:08:35 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Thu, 21 May 2015 13:08:35 -0700 (PDT) In-Reply-To: <20150516054211.GF17272@mournblade.imrryr.org> References: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> <20150513183614.GC17272@mournblade.imrryr.org> <201505140015.t4E0F35B026773@new.toad.com> <20150514010741.GI17272@mournblade.imrryr.org> <20150514050948.GL17272@mournblade.imrryr.org> <1431596694.3274731.268516193.7C170F5C@webmail.messagingengine.com> <20150515060332.GX17272@mournblade.imrryr.org> <20150516054211.GF17272@mournblade.imrryr.org> Date: Thu, 21 May 2015 16:08:35 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt (chair guidance request) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 20:08:39 -0000 On Sat, May 16, 2015 at 1:42 AM, Viktor Dukhovni wrote: > On Fri, May 15, 2015 at 06:03:32AM +0000, Viktor Dukhovni wrote: >> On Thu, May 14, 2015 at 11:44:54AM +0200, nudge wrote: >> >> > I've slightly reworded your text for clarity: >> >> Thanks, with guidance from the chairs, I'll merge as much as I can. > > Inspired by the proposed improvement, the below takes a stab at > further clarity and elimination of redundancy. I realize it is > late in the process, so guidace on whether/when/how to improve > this section would be helpful. New section 9 text below the > "signature" line. > > With Section 9 ideally no longer under a cloud of uncertainty, > we would also update section 12: We have heard nothing from the working group saying that they are unhappy with the new section 9, and it seems clear. > > OLD: > In , we propose a digest algorithm > agility protocol. [Note: This section does not yet represent > the rough consensus of the DANE working group and requires further > discussion. Perhaps this belongs in a separate document.] > > NEW: > In , we specify a digest algorithm > agility protocol. The Working Group reviewed this document, and we called consensus on it (and then waited a bit to see if anyone came out of the woodwork, looking sad), and so I believe that this *does* have WG consensus, and so the [Note:...] can be removed. W > > -- > Viktor. > > > While specifies multiple digest algorithms, > it does not specify a protocol by which the client and TLSA record > publisher can agree on the strongest shared algorithm. Such a > protocol allows the client and server to avoid exposure to > deprecated weaker algorithms that are published for compatibility > with less capable clients, but which SHOULD be avoided when > possible. We specify such a protocol below. > > > > This section defines a protocol for avoiding deprecated digest > algorithms when these are published in a peer's TLSA RRset alongside > stronger digest algorithms. Note that this protocol never avoids > RRs with DANE matching type Full(0), as these do not employ a > digest algorithm that might some day be weakened by cryptanalysis. > > > > The ordering of digest algorithms by strength is not specified > in advance; it is entirely up to the client. Client implementations > SHOULD make the digest algorithm preference ordering a configurable > option. > > > > To make digest algorithm agility possible, all published DANE > TLSA RRsets MUST conform to the requirements of . > Clients SHOULD use digest algorithm agility when processing the > peer's DANE TLSA records. Algorithm agility is to be applied > after first discarding any unusable or malformed records (unsupported > digest algorithm, or incorrect digest length). For each usage > and selector, the client SHOULD process only any usable records > with a matching type of Full(0) and the usable records whose > digest algorithm is considered by the client to be the strongest > among usable records with the given usage and selector. > > > > Example: a client implements digest agility and prefers SHA2-512(2) > over SHA2-256(1), while the server publishes an RRset that employs > both digest algorithms as well as a Full(0) record. > > >
> > _25._tcp.mail.example.com. IN TLSA 3 1 1 ( > 3FE246A848798236DD2AB78D39F0651D > 6B6E7CA8E2984012EB0A2E1AC8A87B72 ) > _25._tcp.mail.example.com. IN TLSA 3 1 2 ( > D4F5AF015B46C5057B841C7E7BAB759C > BF029526D29520C5BE6A32C67475439E > 54AB3A945D80C743347C9BD4DADC9D8D > 57FAB78EAA835362F3CA07CCC19A3214 ) > _25._tcp.mail.example.com. IN TLSA 3 1 0 ( > 3059301306072A8648CE3D020106082A > 8648CE3D0301070342000471CB1F504F > 9E4B33971376C005445DACD33CD79A28 > 81C3DED1981F18E7AAA76609DD0E4EF2 > 8265C82703030AD60C5DBA6FB8A9397A > C0FCF06D424C885D484887 ) > >
> > > In this case the client SHOULD accept a server public key that > matches either the "3 1 0" record or the "3 1 2" record, but > SHOULD not accept keys that match only the weaker "3 1 1" record. > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- 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. ---maf From nobody Thu May 21 15:24:33 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67B61A8784 for ; Thu, 21 May 2015 15:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYVlehom8ijN for ; Thu, 21 May 2015 15:24:30 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3A01A0064 for ; Thu, 21 May 2015 15:24:30 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4B556283015; Thu, 21 May 2015 22:24:29 +0000 (UTC) Date: Thu, 21 May 2015 22:24:29 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150521222428.GL17272@mournblade.imrryr.org> References: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> <20150513183614.GC17272@mournblade.imrryr.org> <201505140015.t4E0F35B026773@new.toad.com> <20150514010741.GI17272@mournblade.imrryr.org> <20150514050948.GL17272@mournblade.imrryr.org> <1431596694.3274731.268516193.7C170F5C@webmail.messagingengine.com> <20150515060332.GX17272@mournblade.imrryr.org> <20150516054211.GF17272@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt (chair guidance request) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 22:24:32 -0000 On Thu, May 21, 2015 at 04:08:35PM -0400, Warren Kumari wrote: > > With Section 9 ideally no longer under a cloud of uncertainty, > > we would also update section 12: > > We have heard nothing from the working group saying that they are > unhappy with the new section 9, and it seems clear. And yet the language is somewhat muddy and repetitive, and confused at least John Gilmore about what it was trying to say. Furthermore Section 12 disclaims consensus, but I think we should reach concensus on digest agility (if we have not yet). > The Working Group reviewed this document, and we called consensus on > it (and then waited a bit to see if anyone came out of the woodwork, > looking sad), and so I believe that this *does* have WG consensus, and > so the [Note:...] can be removed. Thanks. I'll remove the note, but I would very much like to improve the clarity of the section 9 text (without changing the technical content). I have such an update queued-up. How might we proceed to adopt it? -- Viktor. From nobody Fri May 22 10:34:18 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21991A86FE for ; Fri, 22 May 2015 10:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErJkAli7ImQ7 for ; Fri, 22 May 2015 10:34:08 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F270C1A871D for ; Fri, 22 May 2015 10:34:07 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so24145775wgb.3 for ; Fri, 22 May 2015 10:34:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=oh0sUloWGsZN7j2gm8jvjwFQL3r6XN3dZnIymh/ta+Q=; b=nEU0YNlkJqMZs1qLq5OHFDAUQNDemlEh3KT0XYy+rSFNU9BSsh4QJfBswK7Hbfd4ZG AvVqCtkwAyNtws9g+wuub1XgxpZbJv+jft+iVvRySo43ESWya+xnU21blHPcOWsbByJt Pl9e+9vA4oGEHamNO4B9mdWzWKmoaSa4m88nub3AU3JIg8jC6RL/8U7JyyqgqqT4ucMA j0TbEFVP9xptsyGHAvKMM9HBLvdqU8mVYVpCfqY2PXPMLZxuSxcNrGJ9SUgQPYPexVx2 cZ3dbK2MEwD+Q2wNJzrP65ndVawa55hSkoAEk3/v9ZOqo7TMLb/zXwV+lGxwBQUTWB1G UX+A== X-Gm-Message-State: ALoCoQlFsaJvXQATvbF1Zclpws5NATvDZmd+tdIWWaZs1e8Q7MJsPch7Rlras936+LI1E8fIshOV MIME-Version: 1.0 X-Received: by 10.194.10.72 with SMTP id g8mr17137261wjb.28.1432316046586; Fri, 22 May 2015 10:34:06 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Fri, 22 May 2015 10:34:06 -0700 (PDT) In-Reply-To: <20150521222428.GL17272@mournblade.imrryr.org> References: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> <20150513183614.GC17272@mournblade.imrryr.org> <201505140015.t4E0F35B026773@new.toad.com> <20150514010741.GI17272@mournblade.imrryr.org> <20150514050948.GL17272@mournblade.imrryr.org> <1431596694.3274731.268516193.7C170F5C@webmail.messagingengine.com> <20150515060332.GX17272@mournblade.imrryr.org> <20150516054211.GF17272@mournblade.imrryr.org> <20150521222428.GL17272@mournblade.imrryr.org> Date: Fri, 22 May 2015 13:34:06 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt (chair guidance request) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 17:34:14 -0000 On Thu, May 21, 2015 at 6:24 PM, Viktor Dukhovni wrote: > On Thu, May 21, 2015 at 04:08:35PM -0400, Warren Kumari wrote: > >> > With Section 9 ideally no longer under a cloud of uncertainty, >> > we would also update section 12: >> >> We have heard nothing from the working group saying that they are >> unhappy with the new section 9, and it seems clear. > > And yet the language is somewhat muddy and repetitive, and confused > at least John Gilmore about what it was trying to say. Furthermore > Section 12 disclaims consensus, but I think we should reach concensus > on digest agility (if we have not yet). > >> The Working Group reviewed this document, and we called consensus on >> it (and then waited a bit to see if anyone came out of the woodwork, >> looking sad), and so I believe that this *does* have WG consensus, and >> so the [Note:...] can be removed. > > Thanks. I'll remove the note, but I would very much like to improve > the clarity of the section 9 text (without changing the technical > content). I have such an update queued-up. How might we proceed > to adopt it? Does anyone have any useful clarity improvement suggestions? We'll wait until 12:00PM UTC on Wednesday (20:00ET), otherwise we'll go ahead with the text as written, and ask Viktor to include it. W > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- 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. ---maf From nobody Sat May 23 01:18:13 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E01B1AC3FC for ; Sat, 23 May 2015 01:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuiMa1Pp2pUL for ; Sat, 23 May 2015 01:18:01 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F26D1AC3D4 for ; Sat, 23 May 2015 01:18:01 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E39B5283015; Sat, 23 May 2015 08:17:59 +0000 (UTC) Date: Sat, 23 May 2015 08:17:59 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150523081759.GA17272@mournblade.imrryr.org> References: <20150513183614.GC17272@mournblade.imrryr.org> <201505140015.t4E0F35B026773@new.toad.com> <20150514010741.GI17272@mournblade.imrryr.org> <20150514050948.GL17272@mournblade.imrryr.org> <1431596694.3274731.268516193.7C170F5C@webmail.messagingengine.com> <20150515060332.GX17272@mournblade.imrryr.org> <20150516054211.GF17272@mournblade.imrryr.org> <20150521222428.GL17272@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt (chair guidance request) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 08:18:10 -0000 On Fri, May 22, 2015 at 01:34:06PM -0400, Warren Kumari wrote: > Does anyone have any useful clarity improvement suggestions? > We'll wait until 12:00PM UTC on Wednesday (20:00ET), otherwise we'll > go ahead with the text as written, and ask Viktor to include it. Multiple updates were posted list. The latest one is on github: https://github.com/vdukhovni/ietf/commit/d67149f19893d76bf5a716d982211d3f52d40509?diff=split#diff-6232fbcb795dbe385e4d6b7436795328 -- Viktor. From nobody Sun May 24 13:41:26 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836E61AD063; Sun, 24 May 2015 13:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_25=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGiO8QTr4aYY; Sun, 24 May 2015 13:41:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9315C1AD067; Sun, 24 May 2015 13:41:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> Date: Sun, 24 May 2015 13:41:21 -0700 Archived-At: Cc: dane-chairs@ietf.org, dane@ietf.org, draft-ietf-dane-smtp-with-dane@ietf.org, draft-ietf-dane-smtp-with-dane.ad@ietf.org, draft-ietf-dane-smtp-with-dane.shepherd@ietf.org Subject: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 20:41:23 -0000 Barry Leiba has entered the following ballot position for draft-ietf-dane-smtp-with-dane-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Nothing fundamental here; I just have three things I'd like to sort out before balloting "yes" on this, and they should all be easy to resolve: 1. References and terminology: You use RFC 1034 to define "RR", and RFC 5598 to define "MSA", "MTA", and "MUA".  And these are definitions that must be understood in order to properly understand this document.  I think that makes those normative references, not informative ones, and they should be changed.  (5598 is already in the downref registry, so,there's no problem with the downref here.) 2. Section 2.2.1 says this:    That said, the protocol in this memo is    an "opportunistic security" protocol, meaning that it strives to    communicate with each peer as securely as possible, while maintaining    broad interoperability.  Therefore, the SMTP client MAY proceed to    use DANE TLS (as described in Section 2.2.2 below) even with MX hosts    obtained via an "insecure" MX RRSet.  For example, when a hosting    provider has a signed DNS zone and publishes TLSA records for its    SMTP servers, hosted domains that are not signed may still benefit    from the provider's TLSA records. That makes sense.  Why doesn't the same thing apply for insecure TLSA records?  Section 2.2 says that when TLSA records are insecure, you don't use them, and SHOULD use pre-DANE security. Please explain why they shouldn't use insecure TLSA records for opportunistic encryption. 3. In Section 2.2.1:    When DANE TLS is mandatory (Section 6) for    a given destination, delivery MUST be delayed when the MX RRSet is    not "secure". This contradicts the "delivery MAY proceed" in the previous paragraph (and it also doesn't really fit into the paragraph about logging anyway). If you want to restrict things, I think you should put the most restrictive condition first, so move this sentence to the top of the previous paragraph this way: OLD If the MX RRSet (or any CNAME leading to it) is "insecure" (see Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via pre-DANE opportunistic TLS. NEW If the MX RRSet (or any CNAME leading to it) is "insecure" (see Section 2.1.1), then if DANE TLS is mandatory (Section 6) for the given destination, delivery MUST be delayed. If DANE TLS is not mandatory, then it need not apply, and delivery MAY proceed via pre-DANE opportunistic TLS. END ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 2.2 --    contrast, DNSSEC validated TLSA records MUST NOT be published for    servers that do not support TLS.  Clients can safely interpret their    presence as a commitment by the server operator to implement TLS and    STARTTLS. I don't know that this needs any text changes, though perhaps a mention of this in the Security Considerations would be good: I'm not sure how "safely" they will be able to do that in practice.  Remember that the people running the email severs often have no connection to the people who will insert or remove the TLSA records from the DNS.  It's possible that a software change in the mail servers will remove support for DANE, and the TLSA record will not be correspondingly removed. I'm hoping that once this really gets rolled out, that won't be a real issue, but it could be for a while.  It might be worth saying in the Security Considerations that such a situation needs to be avoided, and coordination is important, to make sure it doesn't happen.  Otherwise, according to Section 2.2, mail delivery from DANE-aware MTAs will fail. -- Sections 2.2.1 and 2.2.2 -- In 2.2.1: In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset is not "insecure" then it is "secure", and the SMTP client MUST treat each MX hostname as a separate non-MX destination for opportunistic DANE TLS (as described in Section 2.2.2). In 2.2.2: This section describes the algorithm used to locate the TLSA records and associated TLSA base domain for an input domain that is not subject to MX resolution or that lacks MX records. I find this combination unnecessarily confusing -- it starts to sound a bit like Fizzbin . I know it's explained further (which is why this isn't a DISCUSS point), but I think clarity in the introduction would help a lot. I suggest this, but anything similar would be equally helpful: NEW In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset is not "insecure" then it is "secure", and the SMTP client MUST treat each MX hostname as described in Section 2.2.2. END NEW This section describes the algorithm used to locate the TLSA records and associated TLSA base domain for an input domain that is not subject to MX resolution, that represents a hostname from a secure MX RRset, or that lacks MX records. END That latter ordering matches the order of the bullet list, and I think that's useful for making the text understandable. You might also re-think the title for Section 2.2.2, but I think that's less important. -- Section 2.2.3 -- If the ultimate response is a "secure" TLSA RRSet, then the candidate TLSA base domain will be the actual TLSA base domain and the TLSA RRSet will constitute the TLSA records for the destination. If none of the candidate TLSA base domains yield "secure" TLSA records then delivery MAY proceed via pre-DANE opportunistic TLS. SMTP clients MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades or even to skip SMTP servers that fail authentication, but MUST NOT misrepresent authentication success as either a secure connection to the SMTP server or as a secure delivery to the intended next-hop domain. When SMTP clients elect to use insecure TLSA records, this text implies, but doesn't make it completely clear, that they should only do that after checking all candidates. It would be good to be clear: check all candidates, stopping at the first secure TLSA. If no candidates produce secure TLSA, then you MAY use an insecure one, or you MAY use pre-DANE TLS. Is that right? In general, I strongly encourage you to review Section 2.2.3 and make sure that it reads smoothly to someone who's not already familiar with the DANE SMTP work. I'm not sure the organization of the thoughts in this section is very good as it's currently written. -- Section 3.1 -- In summary, we RECOMMEND the use of either "DANE-EE(3) SPKI(1) SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records depending on site needs. But later, in Section 3.1.1, you specifically single out the former: TLSA records published for SMTP servers SHOULD, in most cases, be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. To be more consistent in your advice, I suggest changing the advice in 3.1 thus: NEW In summary, we RECOMMEND the use of "DANE-EE(3) SPKI(1) SHA2-256(1)", with "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records as a second choice, depending on site needs. See the following two subsections for more details. END If that's not the advice you mean to give, then something is unclear. -- Section 3.1.1 -- Similarly, the expiration date of the server certificate MUST be ignored, the validity period of the TLSA record key binding is determined by the validity interval of the TLSA record DNSSEC signature. Editorial: "Similarly" to what? I'd remove the word. Also, the comma after "ignored" needs to be a colon (or a semicolon, but I think a colon is better here; the comma splice is just wrong). With DANE-EE(3) servers need not employ SNI (may ignore the client's SNI message) even when the server is known under independent names Editorial: This needs a comma after "DANE-EE(3)", and would do well with "they" before "may ignore"). -- Section 3.1.1 -- Such servers MUST either publish DANE-TA(2) records for an intermediate certificate or MUST instead use DANE- EE(3) TLSA records. The first "MUST" should be moved one word later, after "either" (or else the second "MUST" should be removed). -- Section 3.1.3 -- Note, this section applies to MTA-to-MTA SMTP on port 25. Earlier, in 2.2.3, you note that "the destination TCP port is typically 25, but this may be different with custom routes specified by the MTA administrator". I don't think you mean for this section not to apply in the latter case, so I suggest changing this to, "Note, this section applies to MTA-to-MTA SMTP, which is normally on port 25." Nothing is lost since the PKIX certificate usages cannot aid SMTP TLS security, they can only impede SMTP TLS interoperability. Editorial: You need a comma after "lost", and the existing comma needs to be a semicolon. The last paragraph of the section is missing a final period. -- Section 6 -- Administrators of mail servers that employ mandatory DANE TLS, need to carefully monitor their mail logs and queues. Nit: the comma should be removed. From nobody Sun May 24 19:05:03 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014EC1B2A33; Sun, 24 May 2015 19:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8ixkQEe8VbW; Sun, 24 May 2015 19:04:57 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02CC61A88FD; Sun, 24 May 2015 19:04:31 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 502EE283033; Mon, 25 May 2015 02:04:30 +0000 (UTC) Date: Mon, 25 May 2015 02:04:30 +0000 From: Viktor Dukhovni To: draft-ietf-dane-smtp-with-dane@ietf.org, dane@ietf.org Message-ID: <20150525020430.GK17272@mournblade.imrryr.org> References: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 02:05:02 -0000 On Sun, May 24, 2015 at 01:41:21PM -0700, Barry Leiba wrote: > 1. References and terminology: > > You use RFC 1034 to define "RR", and RFC 5598 to define "MSA", "MTA", and > "MUA". And these are definitions that must be understood in order to > properly understand this document. I think that makes those normative > references, not informative ones, and they should be changed. (5598 is > already in the downref registry, so,there's no problem with the downref > here.) No objections from me. If nobody else objects, I'll move these to normative in a few days. > 2. Section 2.2.1 says this: > > That said, the protocol in this memo is > an "opportunistic security" protocol, meaning that it strives to > communicate with each peer as securely as possible, while maintaining > broad interoperability.? Therefore, the SMTP client MAY proceed to > use DANE TLS (as described in Section 2.2.2 below) even with MX hosts > obtained via an "insecure" MX RRSet.? For example, when a hosting > provider has a signed DNS zone and publishes TLSA records for its > SMTP servers, hosted domains that are not signed may still benefit > from the provider's TLSA records. > > That makes sense. Why doesn't the same thing apply for insecure TLSA > records? Section 2.2 says that when TLSA records are insecure, you don't > use them, and SHOULD use pre-DANE security. Please explain why they > shouldn't use insecure TLSA records for opportunistic encryption. If I recall correctly, the working group was concerned about diluting the otherwise clear position that TLSA should not be used without DNSSEC. In the context this draft alone, the main reason to avoid using TLSA records from insecure zones, is that lookups of such records are prone to failures (with long timeouts while trying all NS records) against "bare-bones" nameservers that support neither DNSSEC nor TLSA records. When the MX RRset is secure, but the A/AAAA records are insecure, no TLSA lookup takes place. I think that proceeding with (soft-fail) TLSA lookups when the MX RRset is insecure invites implementation errors. > 3. In Section 2.2.1: > > When DANE TLS is mandatory (Section 6) for > a given destination, delivery MUST be delayed when the MX RRSet is > not "secure". > > This contradicts the "delivery MAY proceed" in the previous paragraph > (and it also doesn't really fit into the paragraph about logging anyway). > If you want to restrict things, I think you should put the most > restrictive condition first, so move this sentence to the top of the > previous paragraph this way: > > OLD > If the MX RRSet (or any CNAME leading to it) is "insecure" (see > Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via > pre-DANE opportunistic TLS. > NEW > If the MX RRSet (or any CNAME leading to it) is "insecure" (see > Section 2.1.1), then if DANE TLS is mandatory (Section 6) for > the given destination, delivery MUST be delayed. If DANE TLS > is not mandatory, then it need not apply, and delivery MAY proceed > via pre-DANE opportunistic TLS. > END Thanks, this is a big improvement. Perhaps the "MAY proceed" should probably also be clarified. The intention is to note the possibility of using pre-DANE TLS (which is not required, cleartext is also allowed). It is not the intention of this text to make using the MX host optional. Delivery, with or without TLS, MUST be attempted. So perhaps better still: NEW If the MX RRSet (or any CNAME leading to it) is "insecure" (see Section 2.1.1), then if DANE TLS is mandatory (Section 6) for the given destination, delivery MUST be delayed. If DANE TLS is not mandatory, then DANE does not apply and delivery proceeds with pre-DANE opportunistic TLS (perhaps even in cleartext). END > -- Section 2.2 -- > > ... DNSSEC validated TLSA records MUST NOT be published for > servers that do not support TLS. Clients can safely interpret their > presence as a commitment by the server operator to implement TLS and > STARTTLS. > > I don't know that this needs any text changes, though perhaps a mention > of this in the Security Considerations would be good: I'm not sure how > "safely" they will be able to do that in practice. Indeed the "safely" is the result of the server mandate, and also the problems servers will incur when they mess up, once this protocol is adopted sufficiently widely. So "safely" is somewhat forward-looking. Should such a note be in "Security" or "Operational" considerations? And is it really needed? > I'm hoping that once this really gets rolled out, that won't be a real > issue, but it could be for a while. It might be worth saying in the > Security Considerations that such a situation needs to be avoided, and > coordination is important, to make sure it doesn't happen. Otherwise, > according to Section 2.2, mail delivery from DANE-aware MTAs will fail. We're on the same page, the only question is whether this is sufficiently obvious to avoid needing to explain it. > -- Sections 2.2.1 and 2.2.2 -- > > In 2.2.1: > In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset > is not "insecure" then it is "secure", and the SMTP client MUST treat > each MX hostname as a separate non-MX destination for opportunistic > DANE TLS (as described in Section 2.2.2). > > In 2.2.2: > This section describes the algorithm used to locate the TLSA records > and associated TLSA base domain for an input domain that is not > subject to MX resolution or that lacks MX records. > > NEW > In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset > is not "insecure" then it is "secure", and the SMTP client MUST treat > each MX hostname as described in Section 2.2.2. > END > > NEW > This section describes the algorithm used to locate the TLSA records > and associated TLSA base domain for an input domain that is not > subject to MX resolution, that represents a hostname from a secure MX > RRset, or that lacks MX records. > END Much better, thanks. When would you like to see a new version with these changes? (I am guessing I should wait for any additional IESG comments?) > You might also > re-think the title for Section 2.2.2, but I think that's less important. I see what you mean, but nothing obvious comes to mind. Is "Post-MX" better than "Non-MX"? > -- Section 2.2.3 -- > > If the ultimate response is a "secure" TLSA RRSet, then the candidate > TLSA base domain will be the actual TLSA base domain and the TLSA > RRSet will constitute the TLSA records for the destination. If none > of the candidate TLSA base domains yield "secure" TLSA records then > delivery MAY proceed via pre-DANE opportunistic TLS. SMTP clients > MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades > or even to skip SMTP servers that fail authentication, but MUST NOT > misrepresent authentication success as either a secure connection to > the SMTP server or as a secure delivery to the intended next-hop > domain. Thanks for highlighting this. The same fix as above for "MAY proceed via pre-DANE opportunistic TLS" should likely be applied here. > When SMTP clients elect to use insecure TLSA records, this text implies, > but doesn't make it completely clear, that they should only do that after > checking all candidates. Yes. There are at most two choices (before and after CNAME expansion). The expansion is tried first, and if that is not secure, and there was in fact CNAME indirection, the origin MUST be tried. If the origin is secure, that MUST be used. I can tweak this text for more clarity. > It would be good to be clear: check all > candidates, stopping at the first secure TLSA. If no candidates produce > secure TLSA, then you MAY use an insecure one, or you MAY use pre-DANE > TLS. Is that right? Yes, and that "last" MAY, is really a "free to use TLS the old way", but in any case MUST use the destination with whatever security you can get. No skipping of insecure MX hosts. Adherence to MX preference first, channel security second. > In general, I strongly encourage you to review Section 2.2.3 and make > sure that it reads smoothly to someone who's not already familiar with > the DANE SMTP work. I'm not sure the organization of the thoughts in > this section is very good as it's currently written. Noted. How should I communicate any proposed revisions? > -- Section 3.1 -- > > In summary, we RECOMMEND the use of either "DANE-EE(3) SPKI(1) > SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records > depending on site needs. Indeed, these two are a sufficient best-practice set to cover all needs. > But later, in Section 3.1.1, you specifically single out the former: > > TLSA records published for SMTP servers SHOULD, in most cases, be > "DANE-EE(3) SPKI(1) SHA2-256(1)" records. The vast majority of sites should (and do in fact among the early adopters) stick to usage DANE-EE(3), the DANE-TA(2) case is for select sites with an internal PKI (private CA) and lots of servers. > To be more consistent in your advice, I suggest changing the advice in > 3.1 thus: > > NEW > In summary, we RECOMMEND the use of "DANE-EE(3) SPKI(1) > SHA2-256(1)", with "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA > records as a second choice, depending on site needs. See > the following two subsections for more details. > END This works. Thanks. > -- Section 3.1.1 -- > > Similarly, the expiration date of the server certificate MUST be > ignored, the validity period of the TLSA record key binding is > determined by the validity interval of the TLSA record DNSSEC > signature. > > Editorial: "Similarly" to what? I'd remove the word. Also, the comma > after "ignored" needs to be a colon (or a semicolon, but I think a colon > is better here; the comma splice is just wrong). Will do. > With DANE-EE(3) servers need not employ SNI (may ignore the client's > SNI message) even when the server is known under independent names > > Editorial: This needs a comma after "DANE-EE(3)", and would do well with > "they" before "may ignore"). Thanks. > -- Section 3.1.1 -- > > Such servers MUST either publish DANE-TA(2) > records for an intermediate certificate or MUST instead use DANE- > EE(3) TLSA records. > > The first "MUST" should be moved one word later, after "either" (or else > the second "MUST" should be removed). Thanks, no problem. > -- Section 3.1.3 -- > > Note, this section applies to MTA-to-MTA SMTP on port 25. > > Earlier, in 2.2.3, you note that "the destination TCP port is typically > 25, but this may be different with custom routes specified by the MTA > administrator". I don't think you mean for this section not to apply in > the latter case, so I suggest changing this to, "Note, this section > applies to MTA-to-MTA SMTP, which is normally on port 25." Thanks. Indeed that's the correct formulation. > Nothing is lost since the > PKIX certificate usages cannot aid SMTP TLS security, they can only > impede SMTP TLS interoperability. > > Editorial: You need a comma after "lost", and the existing comma needs to > be a semicolon. > > The last paragraph of the section is missing a final period. No worries. > -- Section 6 -- > > Administrators of mail servers that employ mandatory DANE TLS, need > to carefully monitor their mail logs and queues. > > Nit: the comma should be removed. Thanks. -- Viktor. From nobody Mon May 25 16:17:18 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEFD1ACD79; Mon, 25 May 2015 16:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7L4jzt_3M4k; Mon, 25 May 2015 16:17:12 -0700 (PDT) Received: from smtp76.ord1c.emailsrvr.com (smtp76.ord1c.emailsrvr.com [108.166.43.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09821ACD7A; Mon, 25 May 2015 16:17:11 -0700 (PDT) Received: from smtp10.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp10.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 4EC8A38015B; Mon, 25 May 2015 19:17:11 -0400 (EDT) Received: by smtp10.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 109B7380137; Mon, 25 May 2015 19:17:09 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.0.0.9] (c-76-117-202-186.hsd1.nj.comcast.net [76.117.202.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Mon, 25 May 2015 23:17:11 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Olafur Gudmundsson In-Reply-To: <20150525020430.GK17272@mournblade.imrryr.org> Date: Mon, 25 May 2015 19:17:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <841AFD92-8615-43BF-98B4-48770FA72235@ogud.com> References: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> <20150525020430.GK17272@mournblade.imrryr.org> To: dane WG list , The IESG X-Mailer: Apple Mail (2.2098) Archived-At: Cc: draft-ietf-dane-smtp-with-dane@ietf.org Subject: Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 25 May 2015 23:17:15 -0000 > On May 24, 2015, at 10:04 PM, Viktor Dukhovni = wrote: >=20 > On Sun, May 24, 2015 at 01:41:21PM -0700, Barry Leiba wrote: >=20 >> 1. References and terminology: >>=20 >> You use RFC 1034 to define "RR", and RFC 5598 to define "MSA", "MTA", = and >> "MUA". And these are definitions that must be understood in order to >> properly understand this document. I think that makes those normative >> references, not informative ones, and they should be changed. (5598 = is >> already in the downref registry, so,there's no problem with the = downref >> here.) >=20 > No objections from me. If nobody else objects, I'll move these to > normative in a few days. >=20 Fine by me=20 >> 2. Section 2.2.1 says this: >>=20 >> That said, the protocol in this memo is >> an "opportunistic security" protocol, meaning that it strives to >> communicate with each peer as securely as possible, while = maintaining >> broad interoperability.? Therefore, the SMTP client MAY proceed to >> use DANE TLS (as described in Section 2.2.2 below) even with MX = hosts >> obtained via an "insecure" MX RRSet.? For example, when a hosting >> provider has a signed DNS zone and publishes TLSA records for its >> SMTP servers, hosted domains that are not signed may still benefit >> from the provider's TLSA records. >>=20 >> That makes sense. Why doesn't the same thing apply for insecure TLSA >> records? Section 2.2 says that when TLSA records are insecure, you = don't >> use them, and SHOULD use pre-DANE security. Please explain why they >> shouldn't use insecure TLSA records for opportunistic encryption. >=20 > If I recall correctly, the working group was concerned about diluting > the otherwise clear position that TLSA should not be used without > DNSSEC. Barry, the working went down this path at one point and it turns quickly = into a quicksand of special cases.=20 For that reason we are not in base documents allowing TLSA w/o DNSSEC,=20= Same goes for Service Records (SRV + MX) as if those are forged there is = no value in TLSA for the forged=20 servers.=20 IMHO we should hold SRV and MX records to the same standard and IESG has = blessed the SRV doc with DNSSEC MUST, so I will object strongly to any attempt to lower the = requirements.=20 >=20 > In the context this draft alone, the main reason to avoid using > TLSA records from insecure zones, is that lookups of such records > are prone to failures (with long timeouts while trying all NS > records) against "bare-bones" nameservers that support neither > DNSSEC nor TLSA records. >=20 > When the MX RRset is secure, but the A/AAAA records are insecure, > no TLSA lookup takes place. I think that proceeding with (soft-fail) > TLSA lookups when the MX RRset is insecure invites implementation > errors. +1=20 >=20 >> 3. In Section 2.2.1: >>=20 >> When DANE TLS is mandatory (Section 6) for >> a given destination, delivery MUST be delayed when the MX RRSet is >> not "secure". >>=20 >> This contradicts the "delivery MAY proceed" in the previous paragraph >> (and it also doesn't really fit into the paragraph about logging = anyway). >> If you want to restrict things, I think you should put the most >> restrictive condition first, so move this sentence to the top of the >> previous paragraph this way: >>=20 >> OLD >> If the MX RRSet (or any CNAME leading to it) is "insecure" (see >> Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed = via >> pre-DANE opportunistic TLS. >> NEW >> If the MX RRSet (or any CNAME leading to it) is "insecure" (see >> Section 2.1.1), then if DANE TLS is mandatory (Section 6) for >> the given destination, delivery MUST be delayed. If DANE TLS >> is not mandatory, then it need not apply, and delivery MAY proceed >> via pre-DANE opportunistic TLS. >> END >=20 > Thanks, this is a big improvement. Perhaps the "MAY proceed" should > probably also be clarified. The intention is to note the possibility > of using pre-DANE TLS (which is not required, cleartext is also > allowed). It is not the intention of this text to make using the > MX host optional. Delivery, with or without TLS, MUST be attempted. >=20 > So perhaps better still: >=20 > NEW > If the MX RRSet (or any CNAME leading to it) is "insecure" (see > Section 2.1.1), then if DANE TLS is mandatory (Section 6) for > the given destination, delivery MUST be delayed. If DANE TLS > is not mandatory, then DANE does not apply and delivery proceeds > with pre-DANE opportunistic TLS (perhaps even in cleartext). > END >=20 +1=20 >> -- Section 2.2 -- >>=20 >> ... DNSSEC validated TLSA records MUST NOT be published for >> servers that do not support TLS. Clients can safely interpret = their >> presence as a commitment by the server operator to implement TLS = and >> STARTTLS. >>=20 >> I don't know that this needs any text changes, though perhaps a = mention >> of this in the Security Considerations would be good: I'm not sure = how >> "safely" they will be able to do that in practice. >=20 > Indeed the "safely" is the result of the server mandate, and also the > problems servers will incur when they mess up, once this protocol is > adopted sufficiently widely. So "safely" is somewhat forward-looking. > Should such a note be in "Security" or "Operational" considerations? > And is it really needed? >=20 IMHO this just stating the obvious, it is harmless from a security = perspective.=20 If something like this is needed then maybe we need "TLSA for Dummies=E2=80= =9D statement.=20 DANE for SMTP requires the following:=20 - SMTP servers MUST support SSL, zone with MX record MUST be = DNSSEC signed,=20 - at least one zone with mail server names MUST be DNSSEC signed, = and the mail server name MUST have TLSA records below it at = _xxx._smtp.=20 >> I'm hoping that once this really gets rolled out, that won't be a = real >> issue, but it could be for a while. It might be worth saying in the >> Security Considerations that such a situation needs to be avoided, = and >> coordination is important, to make sure it doesn't happen. Otherwise, >> according to Section 2.2, mail delivery from DANE-aware MTAs will = fail. >=20 > We're on the same page, the only question is whether this is > sufficiently obvious to avoid needing to explain it. Agree,=20 >=20 >> -- Sections 2.2.1 and 2.2.2 -- >>=20 >> In 2.2.1: >> In the absence of DNS lookup errors (Section 2.1.1), if the MX = RRset >> is not "insecure" then it is "secure", and the SMTP client MUST = treat >> each MX hostname as a separate non-MX destination for opportunistic >> DANE TLS (as described in Section 2.2.2). >>=20 >> In 2.2.2: >> This section describes the algorithm used to locate the TLSA = records >> and associated TLSA base domain for an input domain that is not >> subject to MX resolution or that lacks MX records. >>=20 >> NEW >> In the absence of DNS lookup errors (Section 2.1.1), if the MX = RRset >> is not "insecure" then it is "secure", and the SMTP client MUST = treat >> each MX hostname as described in Section 2.2.2. >> END >>=20 >> NEW >> This section describes the algorithm used to locate the TLSA = records >> and associated TLSA base domain for an input domain that is not >> subject to MX resolution, that represents a hostname from a secure = MX >> RRset, or that lacks MX records. >> END >=20 > Much better, thanks. When would you like to see a new version with > these changes? (I am guessing I should wait for any additional IESG > comments?) +1 >=20 >> You might also >> re-think the title for Section 2.2.2, but I think that's less = important. >=20 > I see what you mean, but nothing obvious comes to mind. Is "Post-MX" > better than "Non-MX"? >=20 >> -- Section 2.2.3 -- >>=20 >> If the ultimate response is a "secure" TLSA RRSet, then the = candidate >> TLSA base domain will be the actual TLSA base domain and the TLSA >> RRSet will constitute the TLSA records for the destination. If = none >> of the candidate TLSA base domains yield "secure" TLSA records then >> delivery MAY proceed via pre-DANE opportunistic TLS. SMTP clients >> MAY elect to use "insecure" TLSA records to avoid STARTTLS = downgrades >> or even to skip SMTP servers that fail authentication, but MUST NOT >> misrepresent authentication success as either a secure connection = to >> the SMTP server or as a secure delivery to the intended next-hop >> domain. >=20 > Thanks for highlighting this. The same fix as above for "MAY > proceed via pre-DANE opportunistic TLS" should likely be applied > here. >=20 >> When SMTP clients elect to use insecure TLSA records, this text = implies, >> but doesn't make it completely clear, that they should only do that = after >> checking all candidates. >=20 > Yes. There are at most two choices (before and after CNAME > expansion). The expansion is tried first, and if that is not > secure, and there was in fact CNAME indirection, the origin MUST > be tried. If the origin is secure, that MUST be used. >=20 > I can tweak this text for more clarity. +1 >=20 >> It would be good to be clear: check all >> candidates, stopping at the first secure TLSA. If no candidates = produce >> secure TLSA, then you MAY use an insecure one, or you MAY use = pre-DANE >> TLS. Is that right? >=20 > Yes, and that "last" MAY, is really a "free to use TLS the old > way", but in any case MUST use the destination with whatever security > you can get. No skipping of insecure MX hosts. Adherence to MX > preference first, channel security second. >=20 >> In general, I strongly encourage you to review Section 2.2.3 and make >> sure that it reads smoothly to someone who's not already familiar = with >> the DANE SMTP work. I'm not sure the organization of the thoughts in >> this section is very good as it's currently written. >=20 > Noted. How should I communicate any proposed revisions? >=20 >> -- Section 3.1 -- >>=20 >> In summary, we RECOMMEND the use of either "DANE-EE(3) SPKI(1) >> SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records >> depending on site needs. >=20 > Indeed, these two are a sufficient best-practice set to cover all > needs. >=20 >> But later, in Section 3.1.1, you specifically single out the former: >>=20 >> TLSA records published for SMTP servers SHOULD, in most cases, be >> "DANE-EE(3) SPKI(1) SHA2-256(1)" records. >=20 > The vast majority of sites should (and do in fact among the early > adopters) stick to usage DANE-EE(3), the DANE-TA(2) case is for > select sites with an internal PKI (private CA) and lots of servers. >=20 >> To be more consistent in your advice, I suggest changing the advice = in >> 3.1 thus: >>=20 >> NEW >> In summary, we RECOMMEND the use of "DANE-EE(3) SPKI(1) >> SHA2-256(1)", with "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA >> records as a second choice, depending on site needs. See >> the following two subsections for more details. >> END >=20 > This works. Thanks. >=20 >> -- Section 3.1.1 -- >>=20 >> Similarly, the expiration date of the server certificate MUST be >> ignored, the validity period of the TLSA record key binding is >> determined by the validity interval of the TLSA record DNSSEC >> signature. >>=20 >> Editorial: "Similarly" to what? I'd remove the word. Also, the = comma >> after "ignored" needs to be a colon (or a semicolon, but I think a = colon >> is better here; the comma splice is just wrong). >=20 > Will do. >=20 >> With DANE-EE(3) servers need not employ SNI (may ignore the = client's >> SNI message) even when the server is known under independent names >>=20 >> Editorial: This needs a comma after "DANE-EE(3)", and would do well = with >> "they" before "may ignore"). >=20 > Thanks. >=20 >> -- Section 3.1.1 -- >>=20 >> Such servers MUST either publish DANE-TA(2) >> records for an intermediate certificate or MUST instead use DANE- >> EE(3) TLSA records. >>=20 >> The first "MUST" should be moved one word later, after "either" (or = else >> the second "MUST" should be removed). >=20 > Thanks, no problem. >=20 >> -- Section 3.1.3 -- >>=20 >> Note, this section applies to MTA-to-MTA SMTP on port 25. >>=20 >> Earlier, in 2.2.3, you note that "the destination TCP port is = typically >> 25, but this may be different with custom routes specified by the MTA >> administrator". I don't think you mean for this section not to apply = in >> the latter case, so I suggest changing this to, "Note, this section >> applies to MTA-to-MTA SMTP, which is normally on port 25." >=20 > Thanks. Indeed that's the correct formulation. >=20 >> Nothing is lost since the >> PKIX certificate usages cannot aid SMTP TLS security, they can only >> impede SMTP TLS interoperability. >>=20 >> Editorial: You need a comma after "lost", and the existing comma = needs to >> be a semicolon. >>=20 >> The last paragraph of the section is missing a final period. >=20 > No worries. >=20 >> -- Section 6 -- >>=20 >> Administrators of mail servers that employ mandatory DANE TLS, need >> to carefully monitor their mail logs and queues. >>=20 >> Nit: the comma should be removed. >=20 > Thanks. >=20 > --=20 > Viktor. Thanks Barry and Victor for careful review any good response=20 Olafur From nobody Mon May 25 17:03:48 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8061A020B; Mon, 25 May 2015 17:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLDIe6IPVBIY; Mon, 25 May 2015 17:03:46 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8D6A1A01F0; Mon, 25 May 2015 17:03:45 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 6E75134940D; Tue, 26 May 2015 00:03:42 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B501B160087; Tue, 26 May 2015 00:04:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A284D160089; Tue, 26 May 2015 00:04:07 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3JADM3PsGw9h; Tue, 26 May 2015 00:04:07 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 24798160087; Tue, 26 May 2015 00:04:07 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D70AC2F50D87; Tue, 26 May 2015 10:03:38 +1000 (EST) To: Olafur Gudmundsson From: Mark Andrews References: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> <20150525020430.GK17272@mournblade.imrryr.org> <841AFD92-8615-43BF-98B4-48770FA72235@ogud.com> In-reply-to: Your message of "Mon, 25 May 2015 19:17:09 -0400." <841AFD92-8615-43BF-98B4-48770FA72235@ogud.com> Date: Tue, 26 May 2015 10:03:37 +1000 Message-Id: <20150526000338.D70AC2F50D87@rock.dv.isc.org> Archived-At: Cc: draft-ietf-dane-smtp-with-dane@ietf.org, The IESG , dane WG list Subject: Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 00:03:47 -0000 In message <841AFD92-8615-43BF-98B4-48770FA72235@ogud.com>, Olafur Gudmundsson writes: > >> 2. Section 2.2.1 says this: > >> > >> That said, the protocol in this memo is > >> an "opportunistic security" protocol, meaning that it strives to > >> communicate with each peer as securely as possible, while maintaining > >> broad interoperability.? Therefore, the SMTP client MAY proceed to > >> use DANE TLS (as described in Section 2.2.2 below) even with MX hosts > >> obtained via an "insecure" MX RRSet.? For example, when a hosting > >> provider has a signed DNS zone and publishes TLSA records for its > >> SMTP servers, hosted domains that are not signed may still benefit > >> from the provider's TLSA records. > >> > >> That makes sense. Why doesn't the same thing apply for insecure TLSA > >> records? Section 2.2 says that when TLSA records are insecure, you > don't > >> use them, and SHOULD use pre-DANE security. Please explain why they > >> shouldn't use insecure TLSA records for opportunistic encryption. > > > > If I recall correctly, the working group was concerned about diluting > > the otherwise clear position that TLSA should not be used without > > DNSSEC. > > Barry, the working went down this path at one point and it turns quickly > into a quicksand of special cases. > For that reason we are not in base documents allowing TLSA w/o DNSSEC, > Same goes for Service Records (SRV + MX) as if those are forged there is > no value in TLSA for the forged > servers. > IMHO we should hold SRV and MX records to the same standard and IESG has > blessed the SRV doc with > DNSSEC MUST, so I will object strongly to any attempt to lower the > requirements. In addition it is just plain pointless to do the lookup. If the A/AAAA is insecure the TLSA lookup will be insecure due to there being not DNSSEC trusted path the TLSA node. You can't prove whether the server was supposed to offer STARTTLS or not. Faked answers can "prove" either assertion. You don't get a viable trust anchor if you do get back a TLSA record as the answer will be insecure. SMTP servers can already be configured to accept CERTS where you don't have a trust anchor for that server if you just want to have a encrypted stream to stop casual snooping of traffic and the server happens to say it supports STARTTLS. > > In the context this draft alone, the main reason to avoid using > > TLSA records from insecure zones, is that lookups of such records > > are prone to failures (with long timeouts while trying all NS > > records) against "bare-bones" nameservers that support neither > > DNSSEC nor TLSA records. The main reason for not doing the lookup is that it is pointless (see above). The very much secondary reason for not doing the lookup is that there is a very small percentage of servers that mishandle TLSA lookups. SMTP servers are going to have to handle these broken servers once they get secure A/AAAA responses. draft-andrews-dns-no-response-issue is looking at the issues of servers that don't respond or respond incorrectly. > > When the MX RRset is secure, but the A/AAAA records are insecure, > > no TLSA lookup takes place. I think that proceeding with (soft-fail) > > TLSA lookups when the MX RRset is insecure invites implementation > > errors. > > +1 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon May 25 17:31:38 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFF11A1A55; Mon, 25 May 2015 17:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nFDN-xdlHLq; Mon, 25 May 2015 17:31:32 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9FF1A1A3E; Mon, 25 May 2015 17:31:32 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lwbnX1RjKz4xl; Tue, 26 May 2015 02:31:28 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=mRs8QxeP X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 6-XDc3T3pIRp; Tue, 26 May 2015 02:31:27 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 26 May 2015 02:31:26 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BEFB08004A; Mon, 25 May 2015 20:31:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1432600284; bh=jia4mXXHFyP179zMCAzcyxdBhYjSYrREluJL229KcfM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=mRs8QxePiSfI4vWXS6X4VYEVdxIqntdO1BTyiIYJYd1ZGdfAv+5AAwgFol8l6uZdE Ec1WOfS760rGt0wNrwuTEhOUNChtoM8SiirB6aTBd4SRA6VqJl6kmy2XuDuVDBssKo jxFf5n/mVAYr0WA1dsP3R7KG+DGIBPBckdSSGlWk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t4Q0VN6s007190; Mon, 25 May 2015 20:31:23 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 25 May 2015 20:31:23 -0400 (EDT) From: Paul Wouters To: Mark Andrews In-Reply-To: <20150526000338.D70AC2F50D87@rock.dv.isc.org> Message-ID: References: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> <20150525020430.GK17272@mournblade.imrryr.org> <841AFD92-8615-43BF-98B4-48770FA72235@ogud.com> <20150526000338.D70AC2F50D87@rock.dv.isc.org> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: draft-ietf-dane-smtp-with-dane@ietf.org, The IESG , dane WG list Subject: Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 00:31:35 -0000 On Tue, 26 May 2015, Mark Andrews wrote: > In addition it is just plain pointless to do the lookup. > > If the A/AAAA is insecure the TLSA lookup will be insecure due to > there being not DNSSEC trusted path the TLSA node. I don't understand this. Wether the A/AAA is spoofed or someone with sufficient power to redirect routing of that range to them is the same thing. So even if the A/AAAA were trusted by DNSSEC, you don't know if you are talking to the real or rogue servers in that IP. > You can't prove > whether the server was supposed to offer STARTTLS or not. Yes you can? The presence of TLSA means you MUST do STARTTLS, and not downgrade to plaintext. Sure, it can be spoofed but you're not posting anything signed with DNSSEC, you're not losing any security here? > Faked answers can "prove" either assertion. Sure. Not signing will not help against active attacks. But publishing unsigned could help you agaisnt passive attacks. > You don't get a viable trust anchor if you do get back a TLSA record > as the answer will be insecure. SMTP servers can already be > configured to accept CERTS where you don't have a trust anchor for > that server if you just want to have a encrypted stream to stop > casual snooping of traffic and the server happens to say it supports > STARTTLS. That is true. You don't win much by an out-of-band insecure TLSA lookup. > The main reason for not doing the lookup is that it is pointless > (see above). The very much secondary reason for not doing the > lookup is that there is a very small percentage of servers that > mishandle TLSA lookups. SMTP servers are going to have to handle > these broken servers once they get secure A/AAAA responses. If broken servers are indistinguishable from an attack, then it is an attack, and things should break. (yes spoken without operator hat on) >>> When the MX RRset is secure, but the A/AAAA records are insecure, >>> no TLSA lookup takes place. I think that proceeding with (soft-fail) >>> TLSA lookups when the MX RRset is insecure invites implementation >>> errors. I don't like that because I would like to be able to publish TLSA records in my nohats.ca zone pointing to some mail service I use that uses certificates but are not themselves dnssec signed. eg: nohats.ca. IN MX 5 mail.insecure-bigmail.com. nohats.ca. IN TLSA As for insecure TLSA records themselves, while I would prefer we would use them in a better-than-nothing sense, I am more fearful of implementations just not bothering or forgetting to check for DNSSEC and blindly trusting these. So I think it is more clear to just say ignore insecure TLSA records. Paul From nobody Mon May 25 17:32:15 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2128A1A1A55 for ; Mon, 25 May 2015 17:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qK2leBIVnuFm for ; Mon, 25 May 2015 17:32:10 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3AC1A1A34 for ; Mon, 25 May 2015 17:32:10 -0700 (PDT) Received: by wifw1 with SMTP id w1so11774142wif.0 for ; Mon, 25 May 2015 17:32:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Ldso9i8ZALmuwro8M7sA4n2A00cjCT2w8l/Ky68k2hc=; b=QX2I463uzQKsvsW8dOBr5EJrK46zytUw6eZFff41OcELZtBeaJjldmVXgSFJR7Fkr7 DsxdLX5HYrYNFV3H395RFGd14Qsr+lLijUkQCGgMD2ah4Q4r9TDyGpERcxwlHBkwC1my yC1hulbTaWqFq4zHp4v622rftK997xbgFoCTbHHC9ETRX3CcSy9Zepallt6LwqBqTKKN sMZqakgmzqVbBPbeI627vYC6On00f6+2IRjsB285r53TkvmJOMxWxfgyCNm26cPQzT97 33eoC1JSeF2bVOuJf2je5hzTrTIxc6Ri+KmMJ/jWejV8BZgRUFCUWWTNWo4SIXjErO0Q dxcA== X-Gm-Message-State: ALoCoQnTAnJqtiX51XPzwMIFM4HIrwNnnVtlnSEqmyQWpfolzSSTUqlh2oo/UU+fH8D9zIKqUqd7 MIME-Version: 1.0 X-Received: by 10.194.216.196 with SMTP id os4mr44412937wjc.117.1432600328308; Mon, 25 May 2015 17:32:08 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Mon, 25 May 2015 17:32:08 -0700 (PDT) In-Reply-To: References: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> <20150513183614.GC17272@mournblade.imrryr.org> <201505140015.t4E0F35B026773@new.toad.com> <20150514010741.GI17272@mournblade.imrryr.org> <20150514050948.GL17272@mournblade.imrryr.org> <1431596694.3274731.268516193.7C170F5C@webmail.messagingengine.com> <20150515060332.GX17272@mournblade.imrryr.org> <20150516054211.GF17272@mournblade.imrryr.org> <20150521222428.GL17272@mournblade.imrryr.org> Date: Mon, 25 May 2015 20:32:08 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt (chair guidance request) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 00:32:13 -0000 On Fri, May 22, 2015 at 1:34 PM, Warren Kumari wrote: > On Thu, May 21, 2015 at 6:24 PM, Viktor Dukhovni wrote: >> On Thu, May 21, 2015 at 04:08:35PM -0400, Warren Kumari wrote: >> >>> > With Section 9 ideally no longer under a cloud of uncertainty, >>> > we would also update section 12: >>> >>> We have heard nothing from the working group saying that they are >>> unhappy with the new section 9, and it seems clear. >> >> And yet the language is somewhat muddy and repetitive, and confused >> at least John Gilmore about what it was trying to say. Furthermore >> Section 12 disclaims consensus, but I think we should reach concensus >> on digest agility (if we have not yet). >> >>> The Working Group reviewed this document, and we called consensus on >>> it (and then waited a bit to see if anyone came out of the woodwork, >>> looking sad), and so I believe that this *does* have WG consensus, and >>> so the [Note:...] can be removed. >> >> Thanks. I'll remove the note, but I would very much like to improve >> the clarity of the section 9 text (without changing the technical >> content). I have such an update queued-up. How might we proceed >> to adopt it? > > > Does anyone have any useful clarity improvement suggestions? > We'll wait until 12:00PM UTC on Wednesday (20:00ET), otherwise we'll > go ahead with the text as written, and ask Viktor to include it. ... I have some very small grammar / readability suggestions. Take them if you like them, or ignore if you don't.... ------ While specifies multiple digest algorithms, it does not specify a protocol by which the client and TLSA record publisher can agree on the strongest shared algorithm. Such a protocol allows the client and server to avoid exposure to [O]: Such a protocol allows the client and server [P]: Such a protocol would allow the client and server [C]: We haven't specified the protocol yet, so different tense for readability. deprecated weaker algorithms that are published for compatibility with less capable clients, but which SHOULD be avoided when possible. We specify such a protocol below. This section defines a protocol for avoiding deprecated digest algorithms when these are published in a peer's TLSA RRset alongside stronger digest algorithms. Note that this protocol never avoids RRs with DANE matching type Full(0), as these do not employ a digest algorithm that might some day be weakened by cryptanalysis. [WK] ... we hope -- or we have some *serious* issues. :-P The ordering of digest algorithms by strength is not specified in advance; it is entirely up to the client. Client implementations SHOULD make the digest algorithm preference ordering a configurable option. [O]: The ordering of digest algorithms by strength is not specified in advance; it is entirely up to the client. Client implementations SHOULD make the digest algorithm preference ordering a configurable option. [P]: While all clients SHOULD implement ordering of digest algorithms by strength, each client is free to decide upon the order of digest algorithms, from strongest to weakest. Client implementations SHOULD make the digest algorithm preference ordering a configurable option. [C]: The original paragraph is unclear as to whether the client can choose the order of the algorithms or whether the client can choose to implement this feature at all. To make digest algorithm agility possible, all published DANE TLSA RRsets MUST conform to the requirements of . Clients SHOULD use digest algorithm agility when processing the peer's DANE TLSA records. Algorithm agility is to be applied after first discarding any unusable or malformed records (unsupported digest algorithm, or incorrect digest length). For each usage and selector, the client SHOULD process only any usable records with a matching type of Full(0) and the usable records whose digest algorithm is considered by the client to be the strongest among usable records with the given usage and selector. Example: a client implements digest agility and prefers SHA2-512(2) over SHA2-256(1), while the server publishes an RRset that employs both digest algorithms as well as a Full(0) record.
_25._tcp.mail.example.com. IN TLSA 3 1 1 ( 3FE246A848798236DD2AB78D39F0651D 6B6E7CA8E2984012EB0A2E1AC8A87B72 ) _25._tcp.mail.example.com. IN TLSA 3 1 2 ( D4F5AF015B46C5057B841C7E7BAB759C BF029526D29520C5BE6A32C67475439E 54AB3A945D80C743347C9BD4DADC9D8D 57FAB78EAA835362F3CA07CCC19A3214 ) _25._tcp.mail.example.com. IN TLSA 3 1 0 ( 3059301306072A8648CE3D020106082A 8648CE3D0301070342000471CB1F504F 9E4B33971376C005445DACD33CD79A28 81C3DED1981F18E7AAA76609DD0E4EF2 8265C82703030AD60C5DBA6FB8A9397A C0FCF06D424C885D484887 )
In this case the client SHOULD accept a server public key that matches either the "3 1 0" record or the "3 1 2" record, but SHOULD not accept keys that match only the weaker "3 1 1" record. ----- > > W > > >> >> -- >> Viktor. >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > > > > -- > 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. > ---maf -- 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. ---maf From nobody Mon May 25 18:28:17 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC3D1A1EF1; Mon, 25 May 2015 18:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEYOnyHHl8W2; Mon, 25 May 2015 18:28:14 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A05C1A1BF8; Mon, 25 May 2015 18:28:14 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E3357283015; Tue, 26 May 2015 01:28:12 +0000 (UTC) Date: Tue, 26 May 2015 01:28:12 +0000 From: Viktor Dukhovni To: dane@ietf.org, draft-ietf-dane-smtp-with-dane@ietf.org Message-ID: <20150526012812.GP17272@mournblade.imrryr.org> References: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> <20150525020430.GK17272@mournblade.imrryr.org> <841AFD92-8615-43BF-98B4-48770FA72235@ogud.com> <20150526000338.D70AC2F50D87@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 01:28:16 -0000 On Mon, May 25, 2015 at 08:31:23PM -0400, Paul Wouters wrote: > >If the A/AAAA is insecure the TLSA lookup will be insecure due to > >there being not DNSSEC trusted path the TLSA node. > > I don't understand this. Let's make it specific. If the zone containing smtp.example.com. IN A 192.0.2.1 is unsigned (whether because example.com is unsigned, or because "smtp.example.com" is itself a delegated 'insecure' zone), then it is exceedingly unlikely (a miracle) if somehow the associated TLSA RRset: _25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 is "secure". For that to happen, there would have to be an explicit DNSSEC trust-anchor for either "_tcp.smtp.example.com" or "_25._tcp.example.com" configured in the validating resolver. Since that's going to happen basically "never", the client just assumes the inevitable outcome, and avoids the lookup. The canonical problem case is "nist.gov". Their zone is signed and MX lookups yield a "secure" result: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52380 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 nist.gov. MX 0 nist-gov.mail.protection.outlook.com. If address record lookups that lead to "insecure" answers: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2284 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 nist-gov.mail.protection.outlook.com. A 207.46.163.247 nist-gov.mail.protection.outlook.com. A 207.46.163.170 nist-gov.mail.protection.outlook.com. A 207.46.163.138 are not used to infer that "TLSA" is also "insecure" and thus to suppress TLSA lookups, then TLSA lookups fail, and to avoid "downgrade" attacks no mail is delivered to "nist.gov". ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60707 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;_25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA Such failures would make deployment of DANE TLS for SMTP unattractive to MTA administrators. The proposed language (implemented in Postfix and Exim) avoids this problem. We've discussed this before. > Wether the A/AAA is spoofed or someone > with sufficient power to redirect routing of that range to them > is the same thing. The A/AAAA lookups serve to discover whether the zone with the server name is signed. We don't actually care whether the address records are secure. We could query for any other record that "bare-bones" nameservers don't mishandle, but since the A records will be needed anyway, we use those. > I don't like that because I would like to be able to publish TLSA > records in my nohats.ca zone pointing to some mail service I use > that uses certificates but are not themselves dnssec signed. eg: > > nohats.ca. IN MX 5 mail.insecure-bigmail.com. > nohats.ca. IN TLSA This does you no good anyway, because queries for TLSA records with MX and SRV services are made for the "_._tcp." NOT "_._tcp.". Nor are you particulary likely to reliably publish accurate TLSA records for a server operated by a third party. Inevitably they'll make changes on their end, and your mail will stop. So this is not an option. > As for insecure TLSA records themselves, while I would prefer we > would use them in a better-than-nothing sense, I am more fearful of > implementations just not bothering or forgetting to check for DNSSEC > and blindly trusting these. So I think it is more clear to just say > ignore insecure TLSA records. I think we agree on that. -- Viktor. From nobody Mon May 25 18:33:21 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD171A6EFB; Mon, 25 May 2015 18:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAXoDpqFI21K; Mon, 25 May 2015 18:33:18 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA061A6EF0; Mon, 25 May 2015 18:33:18 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 52FC8349422; Tue, 26 May 2015 01:33:16 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 9D75E160053; Tue, 26 May 2015 01:33:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 81636160087; Tue, 26 May 2015 01:33:41 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OQFk6cLRdrVw; Tue, 26 May 2015 01:33:41 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id EDE25160053; Tue, 26 May 2015 01:33:40 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 55BD02F51464; Tue, 26 May 2015 11:33:13 +1000 (EST) To: Paul Wouters From: Mark Andrews References: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> <20150525020430.GK17272@mournblade.imrryr.org> <841AFD92-8615-43BF-98B4-48770FA72235@ogud.com> <20150526000338.D70AC2F50D87@rock.dv.isc.org> In-reply-to: Your message of "Mon, 25 May 2015 20:31:23 -0400." Date: Tue, 26 May 2015 11:33:12 +1000 Message-Id: <20150526013313.55BD02F51464@rock.dv.isc.org> Archived-At: Cc: draft-ietf-dane-smtp-with-dane@ietf.org, The IESG , dane WG list Subject: Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 01:33:20 -0000 In message , Paul Wouters wr ites: > On Tue, 26 May 2015, Mark Andrews wrote: > > > In addition it is just plain pointless to do the lookup. > > > > If the A/AAAA is insecure the TLSA lookup will be insecure due to > > there being not DNSSEC trusted path the TLSA node. > > I don't understand this. Wether the A/AAA is spoofed or someone > with sufficient power to redirect routing of that range to them > is the same thing. So even if the A/AAAA were trusted by DNSSEC, > you don't know if you are talking to the real or rogue servers > in that IP. If the A/AAAA result is secure you do the TLSA lookup. > > You can't prove > > whether the server was supposed to offer STARTTLS or not. > > Yes you can? The presence of TLSA means you MUST do STARTTLS, > and not downgrade to plaintext. Sure, it can be spoofed but > you're not posting anything signed with DNSSEC, you're not > losing any security here? If the answer is INSECURE you can't prove the TLSA exists. The MUST only applies if you get a SECURE response to the TLSA record which will not happen if the A/AAAA response is insecure. > > Faked answers can "prove" either assertion. > > Sure. Not signing will not help against active attacks. But publishing > unsigned could help you agaisnt passive attacks. And you can tell the difference how? Spoofed affirmative TLSA responses can lead to a DoS if they are accepted either because the server does not offer STARTTLS or the TLSA does not match the CERT offered. > > as the answer will be insecure. SMTP servers can already be > > configured to accept CERTS where you don't have a trust anchor for > > that server if you just want to have a encrypted stream to stop > > casual snooping of traffic and the server happens to say it supports > > STARTTLS. > > That is true. You don't win much by an out-of-band insecure TLSA lookup. > > > The main reason for not doing the lookup is that it is pointless > > (see above). The very much secondary reason for not doing the > > lookup is that there is a very small percentage of servers that > > mishandle TLSA lookups. SMTP servers are going to have to handle > > these broken servers once they get secure A/AAAA responses. > > If broken servers are indistinguishable from an attack, then it is > an attack, and things should break. (yes spoken without operator hat on) > > >>> When the MX RRset is secure, but the A/AAAA records are insecure, > >>> no TLSA lookup takes place. I think that proceeding with (soft-fail) > >>> TLSA lookups when the MX RRset is insecure invites implementation > >>> errors. > > I don't like that because I would like to be able to publish TLSA > records in my nohats.ca zone pointing to some mail service I use > that uses certificates but are not themselves dnssec signed. eg: > > nohats.ca. IN MX 5 mail.insecure-bigmail.com. > nohats.ca. IN TLSA Which no SMTP client will lookup. Much better to write to their support@ address and say you are moving your email to someone that supports TLSA if they don't add the records with them carry through with the threat if they don't. There is nothing stopping any SMTP service operator configuring and signing TLSA records other than pigheadedness on the part of the operator. > As for insecure TLSA records themselves, while I would prefer we > would use them in a better-than-nothing sense, I am more fearful of > implementations just not bothering or forgetting to check for DNSSEC > and blindly trusting these. So I think it is more clear to just say > ignore insecure TLSA records. Except they are not better-than-nothing. Using them requires that you deal with the failure modes of dealing with them. They introduce their own new threats. They also don't enhance security. Ignoring them doesn't prevent opportunic use of STARTTLS. > Paul -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon May 25 18:40:20 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5503B1AD0CC; Mon, 25 May 2015 18:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6R6NKC5v0lYp; Mon, 25 May 2015 18:40:14 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4B61AD0C8; Mon, 25 May 2015 18:40:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lwdJr2WT8z1Hm; Tue, 26 May 2015 03:40:12 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=Bcks/nzq X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id NzJhwTthXYDL; Tue, 26 May 2015 03:40:11 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 26 May 2015 03:40:11 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5B51480042; Mon, 25 May 2015 21:40:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1432604409; bh=WVcBXUWyiOFFMSD/43d215u1ErT2XTZ0p/7RGEeEVNU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Bcks/nzqApK5SOx0TfHyvFOx61Q+/OXGrUFpC/7Bn8YGm1PBzmXfBiOLN60pJPb88 JmiSAFqhs+m5jJEMQfbCstjdE0ghqC8WMZ04jZMv0SJmrza7/yMc753+YUN5z4YF6a k8pRF7nds5xRt8SJGhRHMdrBgJYkSyS1lqhAgwzQ= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t4Q1e9aN014174; Mon, 25 May 2015 21:40:09 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 25 May 2015 21:40:09 -0400 (EDT) From: Paul Wouters To: Mark Andrews In-Reply-To: <20150526013313.55BD02F51464@rock.dv.isc.org> Message-ID: References: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> <20150525020430.GK17272@mournblade.imrryr.org> <841AFD92-8615-43BF-98B4-48770FA72235@ogud.com> <20150526000338.D70AC2F50D87@rock.dv.isc.org> <20150526013313.55BD02F51464@rock.dv.isc.org> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: draft-ietf-dane-smtp-with-dane@ietf.org, The IESG , dane WG list Subject: Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 01:40:16 -0000 On Tue, 26 May 2015, Mark Andrews wrote: > If the A/AAAA result is secure you do the TLSA lookup. > >>> You can't prove >>> whether the server was supposed to offer STARTTLS or not. >> >> Yes you can? The presence of TLSA means you MUST do STARTTLS, >> and not downgrade to plaintext. Sure, it can be spoofed but >> you're not posting anything signed with DNSSEC, you're not >> losing any security here? > > If the answer is INSECURE you can't prove the TLSA exists. The > MUST only applies if you get a SECURE response to the TLSA record > which will not happen if the A/AAAA response is insecure. I forgot the whole level of indirection looking up the TLSA at the mail server names instead of the domain zone itself. I never liked these but I understand why it's the least worst solution. Thanks Mark and Viktor for explaining it to me, again.... :) Paul From nobody Mon May 25 19:19:25 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC2A1A8870; Mon, 25 May 2015 19:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hr37N7eqCi0F; Mon, 25 May 2015 19:19:22 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505511A886C; Mon, 25 May 2015 19:19:22 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id EEE7634940D; Tue, 26 May 2015 02:19:18 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2B902160053; Tue, 26 May 2015 02:19:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D522B160087; Tue, 26 May 2015 02:19:43 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XL_T9Lj4Dfjc; Tue, 26 May 2015 02:19:43 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 23274160053; Tue, 26 May 2015 02:19:43 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 90A7D2F51662; Tue, 26 May 2015 12:19:15 +1000 (EST) To: dane@ietf.org From: Mark Andrews References: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> <20150525020430.GK17272@mournblade.imrryr.org> <841AFD92-8615-43BF-98B4-48770FA72235@ogud.com> <20150526000338.D70AC2F50D87@rock.dv.isc.org> <20150526012812.GP17272@mournblade.imrryr.org> In-reply-to: Your message of "Tue, 26 May 2015 01:28:12 +0000." <20150526012812.GP17272@mournblade.imrryr.org> Date: Tue, 26 May 2015 12:19:14 +1000 Message-Id: <20150526021915.90A7D2F51662@rock.dv.isc.org> Archived-At: Cc: draft-ietf-dane-smtp-with-dane@ietf.org Subject: Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 02:19:24 -0000 In message <20150526012812.GP17272@mournblade.imrryr.org>, Viktor Dukhovni writ es: > On Mon, May 25, 2015 at 08:31:23PM -0400, Paul Wouters wrote: > > > >If the A/AAAA is insecure the TLSA lookup will be insecure due to > > >there being not DNSSEC trusted path the TLSA node. > > > > I don't understand this. > > Let's make it specific. If the zone containing > > smtp.example.com. IN A 192.0.2.1 > > is unsigned (whether because example.com is unsigned, or because > "smtp.example.com" is itself a delegated 'insecure' zone), then > it is exceedingly unlikely (a miracle) if somehow the associated > TLSA RRset: > > _25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0c44298fc1c149afbf4c8996fb924 > 27ae41e4649b934ca495991b7852b855 > > is "secure". For that to happen, there would have to be an explicit > DNSSEC trust-anchor for either "_tcp.smtp.example.com" or > "_25._tcp.example.com" configured in the validating resolver. > > Since that's going to happen basically "never", the client just > assumes the inevitable outcome, and avoids the lookup. > > The canonical problem case is "nist.gov". Their zone is signed > and MX lookups yield a "secure" result: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52380 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > nist.gov. MX 0 nist-gov.mail.protection.outlook.com. > > If address record lookups that lead to "insecure" answers: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2284 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > nist-gov.mail.protection.outlook.com. A 207.46.163.247 > nist-gov.mail.protection.outlook.com. A 207.46.163.170 > nist-gov.mail.protection.outlook.com. A 207.46.163.138 > > are not used to infer that "TLSA" is also "insecure" and thus to > suppress TLSA lookups, then TLSA lookups fail, and to avoid > "downgrade" attacks no mail is delivered to "nist.gov". > > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60707 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > ;_25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA The servers for outlook.com also don't handle EDNS version negotiation or unknown EDNS options. ISC is intending to ship BIND 9.11.0 with DNS COOKIES enabled by default. There is going to be more pain than just TLSA lookups once that happens. See the following report for all the EDNS compliance errors with the servers for outlook.com. https://ednscomp.isc.org/ednscomp/6840acd09c Yes, Microsoft were informed months ago that their servers are not EDNS compliant and that what we intend to ship servers that won't work with the servers they are using. Fixing these bugs should take less than 5 minutes for a developer of the nameservers Microsoft are using. They are trivial compliance bugs. Add: /* If the EDNS version is != 0 send BADVERS as the error code. */ if (opt != NULL && ((opt->ttl >> 16) & 0xff) != 0) { send_error(rcode = BADVERS); return; } Remove: if (opt != NULL && opt->rdlen != 0) { send_error(rcode = FORMERR); return; } As unknown EDNS options are supposed to be ignored. Reconfigure the firewall to ignore EDNS version in the opt record on 3 of the servers. Fixing the TLSA issue is also similar. It should result in a NOERROR no data response. Stop sending NOTIMP on unknown types that are not reserved for META queries. The handling of non meta query types was documented over a decade ago. The servers are capable of sending valid NOERROR no data responses which this mx response demonstrates. ; <<>> DiG 9.11.0pre-alpha <<>> +noedns mx _25._tcp.nist-gov.mail.protection.outlook.com @ns2-proddns.glbdns.o365filtering.com +norec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56970 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;_25._tcp.nist-gov.mail.protection.outlook.com. IN MX ;; AUTHORITY SECTION: mail.protection.outlook.com. 3600 IN SOA ns1-proddns.glbdns.o365filtering.com. hostmaster.o365filtering.com. 2013010801 3600 600 86400 3600 ;; Query time: 188 msec ;; SERVER: 207.46.100.42#53(207.46.100.42) ;; WHEN: Tue May 26 12:13:19 EST 2015 ;; MSG SIZE rcvd: 190 It's not like sending the wrong response code is a new issue. We have CERT advisories issued in the past for just such misbehaviour (NXDOMAIN in response to AAAA queries). Is it going to require someone writing up a CERT advisary for load balancer vendors to fix their broken servers? > Such failures would make deployment of DANE TLS for SMTP unattractive > to MTA administrators. The proposed language (implemented in > Postfix and Exim) avoids this problem. We've discussed this before. > > > Wether the A/AAA is spoofed or someone > > with sufficient power to redirect routing of that range to them > > is the same thing. > > The A/AAAA lookups serve to discover whether the zone with the > server name is signed. We don't actually care whether the address > records are secure. We could query for any other record that > "bare-bones" nameservers don't mishandle, but since the A > records will be needed anyway, we use those. > > > I don't like that because I would like to be able to publish TLSA > > records in my nohats.ca zone pointing to some mail service I use > > that uses certificates but are not themselves dnssec signed. eg: > > > > nohats.ca. IN MX 5 mail.insecure-bigmail.com. > > nohats.ca. IN TLSA > > This does you no good anyway, because queries for TLSA records with > MX and SRV services are made for the "_._tcp." > NOT "_._tcp.". Nor are you particulary likely > to reliably publish accurate TLSA records for a server operated by > a third party. Inevitably they'll make changes on their end, and > your mail will stop. So this is not an option. > > > As for insecure TLSA records themselves, while I would prefer we > > would use them in a better-than-nothing sense, I am more fearful of > > implementations just not bothering or forgetting to check for DNSSEC > > and blindly trusting these. So I think it is more clear to just say > > ignore insecure TLSA records. > > I think we agree on that. > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon May 25 19:58:08 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8CC1A8974; Mon, 25 May 2015 19:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_25=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNV0B4DPedSY; Mon, 25 May 2015 19:58:02 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E39141A894A; Mon, 25 May 2015 19:58:01 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so47746699igb.1; Mon, 25 May 2015 19:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TZOkEmp04axzHJtIZIhAZ8YU7eXJ+URPYyngJSj7edE=; b=LoYhbhaCwvf1yd2Y2LoPPPVWbyOheWD6CY9TOmeKXXYRPQx1QRyOrbsvOvbgCa0Ui2 4To6CttB3fJqw6PfIAOycad0RvIFsLYfIZ9kScpic+pAZts1rYR57G+cGPOvlcWa5B0Z NUSYW2AFUiuX7hsGpVZGySaYI+VDCHtYx5y0T4oDpVs22qA/EDgp+DEPmzQXXwoMpX97 gqsUruVTrYtD2bEryzHKyoww9DIIwCHClolta1ZvQ3yGJ+4iI9ZJtfLSaRUjo5RryeUd rw5BGxpKG/h/JFec47IhwuqYAglfD+qsw4HGAAzbcHw0YrW7KRVkIXO7C//tEpta+BpY Sq0A== MIME-Version: 1.0 X-Received: by 10.107.25.199 with SMTP id 190mr17610875ioz.11.1432609081414; Mon, 25 May 2015 19:58:01 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.195 with HTTP; Mon, 25 May 2015 19:58:01 -0700 (PDT) In-Reply-To: <20150525020430.GK17272@mournblade.imrryr.org> References: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> <20150525020430.GK17272@mournblade.imrryr.org> Date: Mon, 25 May 2015 22:58:01 -0400 X-Google-Sender-Auth: 0Ej5K_PSpSclCA8bHa7IlGW8g68 Message-ID: From: Barry Leiba To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-dane-smtp-with-dane@ietf.org Subject: Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 02:58:04 -0000 Quick response for tonight, with a fuller one on Tuesday, NY time: Thanks for the responses, Viktor and Olafur. Between the two, you've explained what I need for DISCUSS point 2. Tomorrow I'll clear the DISCUSS completely and give a better email response (short version: all is good on all comments, and thanks). As to when to post a revised I-D: my preference is always "early and often", but you should check with Stephen, as he's the responsible AD. Barry On Sun, May 24, 2015 at 10:04 PM, Viktor Dukhovni wrote: > On Sun, May 24, 2015 at 01:41:21PM -0700, Barry Leiba wrote: > >> 1. References and terminology: >> >> You use RFC 1034 to define "RR", and RFC 5598 to define "MSA", "MTA", and >> "MUA". And these are definitions that must be understood in order to >> properly understand this document. I think that makes those normative >> references, not informative ones, and they should be changed. (5598 is >> already in the downref registry, so,there's no problem with the downref >> here.) > > No objections from me. If nobody else objects, I'll move these to > normative in a few days. > >> 2. Section 2.2.1 says this: >> >> That said, the protocol in this memo is >> an "opportunistic security" protocol, meaning that it strives to >> communicate with each peer as securely as possible, while maintaining >> broad interoperability.? Therefore, the SMTP client MAY proceed to >> use DANE TLS (as described in Section 2.2.2 below) even with MX hosts >> obtained via an "insecure" MX RRSet.? For example, when a hosting >> provider has a signed DNS zone and publishes TLSA records for its >> SMTP servers, hosted domains that are not signed may still benefit >> from the provider's TLSA records. >> >> That makes sense. Why doesn't the same thing apply for insecure TLSA >> records? Section 2.2 says that when TLSA records are insecure, you don't >> use them, and SHOULD use pre-DANE security. Please explain why they >> shouldn't use insecure TLSA records for opportunistic encryption. > > If I recall correctly, the working group was concerned about diluting > the otherwise clear position that TLSA should not be used without > DNSSEC. > > In the context this draft alone, the main reason to avoid using > TLSA records from insecure zones, is that lookups of such records > are prone to failures (with long timeouts while trying all NS > records) against "bare-bones" nameservers that support neither > DNSSEC nor TLSA records. > > When the MX RRset is secure, but the A/AAAA records are insecure, > no TLSA lookup takes place. I think that proceeding with (soft-fail) > TLSA lookups when the MX RRset is insecure invites implementation > errors. > >> 3. In Section 2.2.1: >> >> When DANE TLS is mandatory (Section 6) for >> a given destination, delivery MUST be delayed when the MX RRSet is >> not "secure". >> >> This contradicts the "delivery MAY proceed" in the previous paragraph >> (and it also doesn't really fit into the paragraph about logging anyway). >> If you want to restrict things, I think you should put the most >> restrictive condition first, so move this sentence to the top of the >> previous paragraph this way: >> >> OLD >> If the MX RRSet (or any CNAME leading to it) is "insecure" (see >> Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via >> pre-DANE opportunistic TLS. >> NEW >> If the MX RRSet (or any CNAME leading to it) is "insecure" (see >> Section 2.1.1), then if DANE TLS is mandatory (Section 6) for >> the given destination, delivery MUST be delayed. If DANE TLS >> is not mandatory, then it need not apply, and delivery MAY proceed >> via pre-DANE opportunistic TLS. >> END > > Thanks, this is a big improvement. Perhaps the "MAY proceed" should > probably also be clarified. The intention is to note the possibility > of using pre-DANE TLS (which is not required, cleartext is also > allowed). It is not the intention of this text to make using the > MX host optional. Delivery, with or without TLS, MUST be attempted. > > So perhaps better still: > > NEW > If the MX RRSet (or any CNAME leading to it) is "insecure" (see > Section 2.1.1), then if DANE TLS is mandatory (Section 6) for > the given destination, delivery MUST be delayed. If DANE TLS > is not mandatory, then DANE does not apply and delivery proceeds > with pre-DANE opportunistic TLS (perhaps even in cleartext). > END > >> -- Section 2.2 -- >> >> ... DNSSEC validated TLSA records MUST NOT be published for >> servers that do not support TLS. Clients can safely interpret their >> presence as a commitment by the server operator to implement TLS and >> STARTTLS. >> >> I don't know that this needs any text changes, though perhaps a mention >> of this in the Security Considerations would be good: I'm not sure how >> "safely" they will be able to do that in practice. > > Indeed the "safely" is the result of the server mandate, and also the > problems servers will incur when they mess up, once this protocol is > adopted sufficiently widely. So "safely" is somewhat forward-looking. > Should such a note be in "Security" or "Operational" considerations? > And is it really needed? > >> I'm hoping that once this really gets rolled out, that won't be a real >> issue, but it could be for a while. It might be worth saying in the >> Security Considerations that such a situation needs to be avoided, and >> coordination is important, to make sure it doesn't happen. Otherwise, >> according to Section 2.2, mail delivery from DANE-aware MTAs will fail. > > We're on the same page, the only question is whether this is > sufficiently obvious to avoid needing to explain it. > >> -- Sections 2.2.1 and 2.2.2 -- >> >> In 2.2.1: >> In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset >> is not "insecure" then it is "secure", and the SMTP client MUST treat >> each MX hostname as a separate non-MX destination for opportunistic >> DANE TLS (as described in Section 2.2.2). >> >> In 2.2.2: >> This section describes the algorithm used to locate the TLSA records >> and associated TLSA base domain for an input domain that is not >> subject to MX resolution or that lacks MX records. >> >> NEW >> In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset >> is not "insecure" then it is "secure", and the SMTP client MUST treat >> each MX hostname as described in Section 2.2.2. >> END >> >> NEW >> This section describes the algorithm used to locate the TLSA records >> and associated TLSA base domain for an input domain that is not >> subject to MX resolution, that represents a hostname from a secure MX >> RRset, or that lacks MX records. >> END > > Much better, thanks. When would you like to see a new version with > these changes? (I am guessing I should wait for any additional IESG > comments?) > >> You might also >> re-think the title for Section 2.2.2, but I think that's less important. > > I see what you mean, but nothing obvious comes to mind. Is "Post-MX" > better than "Non-MX"? > >> -- Section 2.2.3 -- >> >> If the ultimate response is a "secure" TLSA RRSet, then the candidate >> TLSA base domain will be the actual TLSA base domain and the TLSA >> RRSet will constitute the TLSA records for the destination. If none >> of the candidate TLSA base domains yield "secure" TLSA records then >> delivery MAY proceed via pre-DANE opportunistic TLS. SMTP clients >> MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades >> or even to skip SMTP servers that fail authentication, but MUST NOT >> misrepresent authentication success as either a secure connection to >> the SMTP server or as a secure delivery to the intended next-hop >> domain. > > Thanks for highlighting this. The same fix as above for "MAY > proceed via pre-DANE opportunistic TLS" should likely be applied > here. > >> When SMTP clients elect to use insecure TLSA records, this text implies, >> but doesn't make it completely clear, that they should only do that after >> checking all candidates. > > Yes. There are at most two choices (before and after CNAME > expansion). The expansion is tried first, and if that is not > secure, and there was in fact CNAME indirection, the origin MUST > be tried. If the origin is secure, that MUST be used. > > I can tweak this text for more clarity. > >> It would be good to be clear: check all >> candidates, stopping at the first secure TLSA. If no candidates produce >> secure TLSA, then you MAY use an insecure one, or you MAY use pre-DANE >> TLS. Is that right? > > Yes, and that "last" MAY, is really a "free to use TLS the old > way", but in any case MUST use the destination with whatever security > you can get. No skipping of insecure MX hosts. Adherence to MX > preference first, channel security second. > >> In general, I strongly encourage you to review Section 2.2.3 and make >> sure that it reads smoothly to someone who's not already familiar with >> the DANE SMTP work. I'm not sure the organization of the thoughts in >> this section is very good as it's currently written. > > Noted. How should I communicate any proposed revisions? > >> -- Section 3.1 -- >> >> In summary, we RECOMMEND the use of either "DANE-EE(3) SPKI(1) >> SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records >> depending on site needs. > > Indeed, these two are a sufficient best-practice set to cover all > needs. > >> But later, in Section 3.1.1, you specifically single out the former: >> >> TLSA records published for SMTP servers SHOULD, in most cases, be >> "DANE-EE(3) SPKI(1) SHA2-256(1)" records. > > The vast majority of sites should (and do in fact among the early > adopters) stick to usage DANE-EE(3), the DANE-TA(2) case is for > select sites with an internal PKI (private CA) and lots of servers. > >> To be more consistent in your advice, I suggest changing the advice in >> 3.1 thus: >> >> NEW >> In summary, we RECOMMEND the use of "DANE-EE(3) SPKI(1) >> SHA2-256(1)", with "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA >> records as a second choice, depending on site needs. See >> the following two subsections for more details. >> END > > This works. Thanks. > >> -- Section 3.1.1 -- >> >> Similarly, the expiration date of the server certificate MUST be >> ignored, the validity period of the TLSA record key binding is >> determined by the validity interval of the TLSA record DNSSEC >> signature. >> >> Editorial: "Similarly" to what? I'd remove the word. Also, the comma >> after "ignored" needs to be a colon (or a semicolon, but I think a colon >> is better here; the comma splice is just wrong). > > Will do. > >> With DANE-EE(3) servers need not employ SNI (may ignore the client's >> SNI message) even when the server is known under independent names >> >> Editorial: This needs a comma after "DANE-EE(3)", and would do well with >> "they" before "may ignore"). > > Thanks. > >> -- Section 3.1.1 -- >> >> Such servers MUST either publish DANE-TA(2) >> records for an intermediate certificate or MUST instead use DANE- >> EE(3) TLSA records. >> >> The first "MUST" should be moved one word later, after "either" (or else >> the second "MUST" should be removed). > > Thanks, no problem. > >> -- Section 3.1.3 -- >> >> Note, this section applies to MTA-to-MTA SMTP on port 25. >> >> Earlier, in 2.2.3, you note that "the destination TCP port is typically >> 25, but this may be different with custom routes specified by the MTA >> administrator". I don't think you mean for this section not to apply in >> the latter case, so I suggest changing this to, "Note, this section >> applies to MTA-to-MTA SMTP, which is normally on port 25." > > Thanks. Indeed that's the correct formulation. > >> Nothing is lost since the >> PKIX certificate usages cannot aid SMTP TLS security, they can only >> impede SMTP TLS interoperability. >> >> Editorial: You need a comma after "lost", and the existing comma needs to >> be a semicolon. >> >> The last paragraph of the section is missing a final period. > > No worries. > >> -- Section 6 -- >> >> Administrators of mail servers that employ mandatory DANE TLS, need >> to carefully monitor their mail logs and queues. >> >> Nit: the comma should be removed. > > Thanks. > > -- > Viktor. > From nobody Tue May 26 03:34:52 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1051B2AC8; Tue, 26 May 2015 03:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eA74LIrYZ4vz; Tue, 26 May 2015 03:34:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE651B2ACF; Tue, 26 May 2015 03:34:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 867F9BE9F; Tue, 26 May 2015 11:34:47 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QRO1FYUsLBT; Tue, 26 May 2015 11:34:46 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EE93BBE50; Tue, 26 May 2015 11:34:45 +0100 (IST) Message-ID: <55644C45.9070600@cs.tcd.ie> Date: Tue, 26 May 2015 11:34:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Barry Leiba , dane@ietf.org References: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> <20150525020430.GK17272@mournblade.imrryr.org> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-dane-smtp-with-dane@ietf.org Subject: Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 10:34:50 -0000 On 26/05/15 03:58, Barry Leiba wrote: > As to when to post a revised I-D: my preference is always "early and > often", but you should check with Stephen, as he's the responsible AD. If you're ready to post before close-of-business Tuesday please do so. Otherwise holding until Friday after the telechat is fine. S. From nobody Tue May 26 05:44:55 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258AD1B2B2E; Tue, 26 May 2015 05:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAi6RDgqRJOO; Tue, 26 May 2015 05:44:52 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361FC1B2B2B; Tue, 26 May 2015 05:44:52 -0700 (PDT) Received: by iepj10 with SMTP id j10so90689778iep.3; Tue, 26 May 2015 05:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lVYHM+9onaH+e1uE4f90IkuCsgeemNi+Z99TbqkhvKo=; b=ErVtXTKgnsj0NCRwERHyq/WNYJ8vn66hA5zKhIkX/afLwdjzPOCf/QBp02Ube0Rg3W /sobKYM8xmech2d3zM2wDImB1/NO5NmLeIU6pSJKTT1KewynVF31fXZC09IGEdebHFiK WPZHemcEThY8KLr7E3c7ezAwCztAO5DZS1ayHh2FAG/kp5u7WvFXMRnswq3i3mVcD7Jr 4izlh0hb3qEHusaWxyQlBnqp0Qv9tX1+tueoWQuEUeGaKEZJK7fAZNoY/m8/7KLlfbgs gg+NyClArGnWMVEb7+cOM5+M7cXv4DQW4ftQB/+XpuqmQesxuUcZIlewZfZmAH0P0ZWf Vc7Q== MIME-Version: 1.0 X-Received: by 10.107.3.79 with SMTP id 76mr33514946iod.60.1432644291670; Tue, 26 May 2015 05:44:51 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.195 with HTTP; Tue, 26 May 2015 05:44:51 -0700 (PDT) In-Reply-To: <20150525020430.GK17272@mournblade.imrryr.org> References: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> <20150525020430.GK17272@mournblade.imrryr.org> Date: Tue, 26 May 2015 08:44:51 -0400 X-Google-Sender-Auth: M2MBCKdLXgoUrlClVqGAFxqRsys Message-ID: From: Barry Leiba To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-dane-smtp-with-dane@ietf.org, IESG Subject: Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 12:44:54 -0000 Time for a proper reply now. I've already cleared the DISCUSS and recorded the resolution in the tracker comments, but I didn't have it re-send the message (this will serve for that). I'm adding the IESG list back to the CC on this reply. Anything I don't mention is stuff we agree on that needs no further comment. And thanks for considering all my comments and addressing them. >> 2. Section 2.2.1 says this: >> >> That said, the protocol in this memo is >> an "opportunistic security" protocol, meaning that it strives to >> communicate with each peer as securely as possible, while maintaining >> broad interoperability.? Therefore, the SMTP client MAY proceed to >> use DANE TLS (as described in Section 2.2.2 below) even with MX hosts >> obtained via an "insecure" MX RRSet.? For example, when a hosting >> provider has a signed DNS zone and publishes TLSA records for its >> SMTP servers, hosted domains that are not signed may still benefit >> from the provider's TLSA records. >> >> That makes sense. Why doesn't the same thing apply for insecure TLSA >> records? Section 2.2 says that when TLSA records are insecure, you don't >> use them, and SHOULD use pre-DANE security. Please explain why they >> shouldn't use insecure TLSA records for opportunistic encryption. > > If I recall correctly, the working group was concerned about diluting > the otherwise clear position that TLSA should not be used without > DNSSEC. > > In the context this draft alone, the main reason to avoid using > TLSA records from insecure zones, is that lookups of such records > are prone to failures (with long timeouts while trying all NS > records) against "bare-bones" nameservers that support neither > DNSSEC nor TLSA records. > > When the MX RRset is secure, but the A/AAAA records are insecure, > no TLSA lookup takes place. I think that proceeding with (soft-fail) > TLSA lookups when the MX RRset is insecure invites implementation > errors. Olafur further adds: > Barry, the working went down this path at one point and it turns quickly into > a quicksand of special cases. For that reason we are not in base documents > allowing TLSA w/o DNSSEC, Same goes for Service Records (SRV + MX) > as if those are forged there is no value in TLSA for the forged servers. > IMHO we should hold SRV and MX records to the same standard and IESG > has blessed the SRV doc with DNSSEC MUST, so I will object strongly to > any attempt to lower the requirements. I'm happy with the explanation (and that the issue was discussed by the working group, so I've removed this comment entirely. Thanks for the discussion. >> 3. In Section 2.2.1: >> >> When DANE TLS is mandatory (Section 6) for >> a given destination, delivery MUST be delayed when the MX RRSet is >> not "secure". >> >> This contradicts the "delivery MAY proceed" in the previous paragraph >> (and it also doesn't really fit into the paragraph about logging anyway). >> If you want to restrict things, I think you should put the most >> restrictive condition first, so move this sentence to the top of the >> previous paragraph this way: >> >> OLD >> If the MX RRSet (or any CNAME leading to it) is "insecure" (see >> Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via >> pre-DANE opportunistic TLS. >> NEW >> If the MX RRSet (or any CNAME leading to it) is "insecure" (see >> Section 2.1.1), then if DANE TLS is mandatory (Section 6) for >> the given destination, delivery MUST be delayed. If DANE TLS >> is not mandatory, then it need not apply, and delivery MAY proceed >> via pre-DANE opportunistic TLS. >> END > > Thanks, this is a big improvement. Perhaps the "MAY proceed" should > probably also be clarified. The intention is to note the possibility > of using pre-DANE TLS (which is not required, cleartext is also > allowed). It is not the intention of this text to make using the > MX host optional. Delivery, with or without TLS, MUST be attempted. > > So perhaps better still: > > NEW > If the MX RRSet (or any CNAME leading to it) is "insecure" (see > Section 2.1.1), then if DANE TLS is mandatory (Section 6) for > the given destination, delivery MUST be delayed. If DANE TLS > is not mandatory, then DANE does not apply and delivery proceeds > with pre-DANE opportunistic TLS (perhaps even in cleartext). > END Yes, that looks great, so keep that one. Thanks for further tweaking it. >> -- Section 2.2 -- >> >> ... DNSSEC validated TLSA records MUST NOT be published for >> servers that do not support TLS. Clients can safely interpret their >> presence as a commitment by the server operator to implement TLS and >> STARTTLS. >> >> I don't know that this needs any text changes, though perhaps a mention >> of this in the Security Considerations would be good: I'm not sure how >> "safely" they will be able to do that in practice. > > Indeed the "safely" is the result of the server mandate, and also the > problems servers will incur when they mess up, once this protocol is > adopted sufficiently widely. So "safely" is somewhat forward-looking. > Should such a note be in "Security" or "Operational" considerations? > And is it really needed? > >> I'm hoping that once this really gets rolled out, that won't be a real >> issue, but it could be for a while. It might be worth saying in the >> Security Considerations that such a situation needs to be avoided, and >> coordination is important, to make sure it doesn't happen. Otherwise, >> according to Section 2.2, mail delivery from DANE-aware MTAs will fail. > > We're on the same page, the only question is whether this is > sufficiently obvious to avoid needing to explain it. You're probably right, and this is entirely up to your judgment. If you see anything you think is worth adding, fine; if not, that's also fine. >> You might also >> re-think the title for Section 2.2.2, but I think that's less important. > > I see what you mean, but nothing obvious comes to mind. Is "Post-MX" > better than "Non-MX"? Hm. Yes, perhaps. Again, to your judgment on this, including not making any change if that's what you think best. >> When SMTP clients elect to use insecure TLSA records, this text implies, >> but doesn't make it completely clear, that they should only do that after >> checking all candidates. > > Yes. There are at most two choices (before and after CNAME > expansion). The expansion is tried first, and if that is not > secure, and there was in fact CNAME indirection, the origin MUST > be tried. If the origin is secure, that MUST be used. > > I can tweak this text for more clarity. > >> It would be good to be clear: check all >> candidates, stopping at the first secure TLSA. If no candidates produce >> secure TLSA, then you MAY use an insecure one, or you MAY use pre-DANE >> TLS. Is that right? > > Yes, and that "last" MAY, is really a "free to use TLS the old > way", but in any case MUST use the destination with whatever security > you can get. No skipping of insecure MX hosts. Adherence to MX > preference first, channel security second. Thanks... whatever you decide will be fine. >> In general, I strongly encourage you to review Section 2.2.3 and make >> sure that it reads smoothly to someone who's not already familiar with >> the DANE SMTP work. I'm not sure the organization of the thoughts in >> this section is very good as it's currently written. > > Noted. How should I communicate any proposed revisions? No need to communicate them explicitly: I trust you to review it and do what you can to organize it. This was (and is) a non-blocking comment. Thanks in advance for giving it another look. Barry From nobody Tue May 26 06:29:55 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6807F1B2C45; Tue, 26 May 2015 06:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHWi5TmUoH10; Tue, 26 May 2015 06:29:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 046E61B2D68; Tue, 26 May 2015 06:29:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150526132948.7810.97818.idtracker@ietfa.amsl.com> Date: Tue, 26 May 2015 06:29:48 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-18.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 13:29:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : SMTP security via opportunistic DANE TLS Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-smtp-with-dane-18.txt Pages : 33 Date : 2015-05-26 Abstract: This memo describes a downgrade-resistant protocol for SMTP transport security between Mail Transfer Agents (MTAs) based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 26 06:37:11 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0871C1B2E1F; Tue, 26 May 2015 06:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbqasA8lHBAt; Tue, 26 May 2015 06:37:09 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 775F71B2E26; Tue, 26 May 2015 06:37:05 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2F169283031; Tue, 26 May 2015 13:37:04 +0000 (UTC) Date: Tue, 26 May 2015 13:37:04 +0000 From: Viktor Dukhovni To: Stephen Farrell Message-ID: <20150526133703.GV17272@mournblade.imrryr.org> References: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> <20150525020430.GK17272@mournblade.imrryr.org> <55644C45.9070600@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55644C45.9070600@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: iesg@ietf.org, dane@ietf.org Subject: Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 13:37:11 -0000 On Tue, May 26, 2015 at 11:34:45AM +0100, Stephen Farrell wrote: > If you're ready to post before close-of-business Tuesday > please do so. Otherwise holding until Friday after the > telechat is fine. OK, I think I beat the deadline. I hope the result meets expectations: https://www.ietf.org/rfcdiff?url1=draft-ietf-dane-smtp-with-dane-17&url2=draft-ietf-dane-smtp-with-dane-18 If there's anything I missed, or goofed up, let me know, I'll fix it after the telechat. -- Viktor. From nobody Tue May 26 06:38:41 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04B31A89B3; Tue, 26 May 2015 06:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IuSyFupOPqw; Tue, 26 May 2015 06:38:35 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C1A1A89AB; Tue, 26 May 2015 06:38:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 586ABBE87; Tue, 26 May 2015 14:38:33 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9va3bz1jvov; Tue, 26 May 2015 14:38:32 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 04AEEBE83; Tue, 26 May 2015 14:38:31 +0100 (IST) Message-ID: <55647756.3080601@cs.tcd.ie> Date: Tue, 26 May 2015 14:38:30 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Viktor Dukhovni References: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> <20150525020430.GK17272@mournblade.imrryr.org> <55644C45.9070600@cs.tcd.ie> <20150526133703.GV17272@mournblade.imrryr.org> In-Reply-To: <20150526133703.GV17272@mournblade.imrryr.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: iesg@ietf.org, dane@ietf.org Subject: Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 13:38:38 -0000 On 26/05/15 14:37, Viktor Dukhovni wrote: > On Tue, May 26, 2015 at 11:34:45AM +0100, Stephen Farrell wrote: > >> If you're ready to post before close-of-business Tuesday >> please do so. Otherwise holding until Friday after the >> telechat is fine. > > OK, I think I beat the deadline. I hope the result meets > expectations: > > https://www.ietf.org/rfcdiff?url1=draft-ietf-dane-smtp-with-dane-17&url2=draft-ietf-dane-smtp-with-dane-18 > > If there's anything I missed, or goofed up, let me know, I'll fix > it after the telechat. Thanks Viktor, I'll ask Barry if he has time to check the diff matches his comments. Cheers, S. > From nobody Tue May 26 07:21:11 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522CE1B2F06; Tue, 26 May 2015 07:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gpBh5jqUHOM; Tue, 26 May 2015 07:21:02 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B87B1B2EE1; Tue, 26 May 2015 07:20:43 -0700 (PDT) Received: by iebgx4 with SMTP id gx4so92969181ieb.0; Tue, 26 May 2015 07:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ivWqrMgwJoX/on3rMVs3BddXQ3PUfoUXSbmpJTSNN/o=; b=QRps65Qq921kQEcWEEAbl9tCMevQp4Uk9SP7Mz4vX+Vj8fmiUUX7AmrzkALSfsETZd uBAr7YvboxypVuLWH7kIBCca45fjael9gDuWNg8Pj1H0m3tAliwj0O8yOQi3Ldv984cy XEGuZUen7Qrn+6E5Zq9VLD3QZh1qit0EpG/fE1SMKpz6va3/467ICfrqZK9M16OTPN9E KbYmuH7w7AE8I+M9B1Ybyat1B+5jCpAkwch8titpDH4Pf6Uq/PVTsaf06ln9+DgkC7PJ WyADC5TVxPwtRnsUsr5gcblDsKUdaaoWaoDZJo/HVrZXN5ICjIEnX0VGshkARdNr2LOW 99Rg== MIME-Version: 1.0 X-Received: by 10.43.171.202 with SMTP id nv10mr29941195icc.30.1432650042633; Tue, 26 May 2015 07:20:42 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.195 with HTTP; Tue, 26 May 2015 07:20:42 -0700 (PDT) In-Reply-To: <20150526133703.GV17272@mournblade.imrryr.org> References: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> <20150525020430.GK17272@mournblade.imrryr.org> <55644C45.9070600@cs.tcd.ie> <20150526133703.GV17272@mournblade.imrryr.org> Date: Tue, 26 May 2015 10:20:42 -0400 X-Google-Sender-Auth: vUO7g9fCKIoSHg0tKTtvgVSSNU8 Message-ID: From: Barry Leiba To: Viktor Dukhovni Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dane@ietf.org, IESG Subject: Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 14:21:03 -0000 > OK, I think I beat the deadline. I hope the result meets > expectations: > > https://www.ietf.org/rfcdiff?url1=draft-ietf-dane-smtp-with-dane-17&url2=draft-ietf-dane-smtp-with-dane-18 > > If there's anything I missed, or goofed up, let me know, I'll fix > it after the telechat. No goofs that I see, and it looks like everything's covered. Thanks again for the responses, and for the quick turnaround. Barry From nobody Tue May 26 16:24:16 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2089E1B331F for ; Tue, 26 May 2015 16:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBksIrrzWq2h for ; Tue, 26 May 2015 16:24:13 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0E11B331E for ; Tue, 26 May 2015 16:24:13 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6214F283031; Tue, 26 May 2015 23:24:12 +0000 (UTC) Date: Tue, 26 May 2015 23:24:12 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150526232412.GC2342@mournblade.imrryr.org> References: <201505140015.t4E0F35B026773@new.toad.com> <20150514010741.GI17272@mournblade.imrryr.org> <20150514050948.GL17272@mournblade.imrryr.org> <1431596694.3274731.268516193.7C170F5C@webmail.messagingengine.com> <20150515060332.GX17272@mournblade.imrryr.org> <20150516054211.GF17272@mournblade.imrryr.org> <20150521222428.GL17272@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt (chair guidance request) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 23:24:15 -0000 On Mon, May 25, 2015 at 08:32:08PM -0400, Warren Kumari wrote: > > ... I have some very small grammar / readability suggestions. > > > Take them if you like them, or ignore if you don't.... I'll post a new version later today (I'm in Australia today, so for most of you, my later today will be your tomorrow). -- Viktor. From nobody Tue May 26 18:24:37 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB131B3373 for ; Tue, 26 May 2015 18:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6i-IMRaeO6Jy for ; Tue, 26 May 2015 18:24:34 -0700 (PDT) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EAC1A1A83 for ; Tue, 26 May 2015 18:24:34 -0700 (PDT) Received: by padbw4 with SMTP id bw4so105676813pad.0 for ; Tue, 26 May 2015 18:24:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uHWDINCj/wL8GfmTlVxt3BEwGIbAJzcpB9ZqUkZUsD0=; b=ZqGsyyd8B8xdWLCaCZAFwQGzSe1YaYj+BB+WvYMnQbnZx0kYYQ7QH1gopbtqCPNBeN V90mhUYqbESInVmFV2vdjORcmOuPGizJ6UTbAZi4mPwnCcRlOznZ9D1rFgwYEeNlf3Jg YB2MACGWyzapMhT/kDFJM5fewEK99ItSIFS2O082CwUxLi20Yxug/GZImveAtWC+2oyl JDw8LY+EwwiTtCSXrd4QZrQR5kwNG5sfX9Aq0T6DNmKPuRg0rwigDYRO2sudQYvGX529 f8HFWD8Y0aZHBvgwgBzdGLSzeUWmhCWA8AfDmFkTiMUt+AzzY+J0JtCD+rjI7Gtghovv /a5Q== X-Gm-Message-State: ALoCoQmuLJJOwH929o5204E5uKFIc3b49M05Hl9mrWU/Bqv5jJsqBu2uV02mumb33KTH4ZBxLfHP X-Received: by 10.68.231.98 with SMTP id tf2mr54660885pbc.12.1432689873682; Tue, 26 May 2015 18:24:33 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id qy7sm14272049pbb.12.2015.05.26.18.24.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 18:24:32 -0700 (PDT) Message-ID: <55651CC9.9020004@andyet.net> Date: Tue, 26 May 2015 19:24:25 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Warren Kumari , "" References: <20150513182627.9918.67542.idtracker@ietfa.amsl.com> <20150513183614.GC17272@mournblade.imrryr.org> <201505140015.t4E0F35B026773@new.toad.com> <20150514010741.GI17272@mournblade.imrryr.org> <20150514050948.GL17272@mournblade.imrryr.org> <1431596694.3274731.268516193.7C170F5C@webmail.messagingengine.com> <20150515060332.GX17272@mournblade.imrryr.org> <20150516054211.GF17272@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt (chair guidance request) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 27 May 2015 01:24:35 -0000 On 5/21/15 2:08 PM, Warren Kumari wrote: > On Sat, May 16, 2015 at 1:42 AM, Viktor Dukhovni wrote: >> On Fri, May 15, 2015 at 06:03:32AM +0000, Viktor Dukhovni wrote: >>> On Thu, May 14, 2015 at 11:44:54AM +0200, nudge wrote: >>> >>>> I've slightly reworded your text for clarity: >>> >>> Thanks, with guidance from the chairs, I'll merge as much as I can. >> >> Inspired by the proposed improvement, the below takes a stab at >> further clarity and elimination of redundancy. I realize it is >> late in the process, so guidace on whether/when/how to improve >> this section would be helpful. New section 9 text below the >> "signature" line. >> >> With Section 9 ideally no longer under a cloud of uncertainty, >> we would also update section 12: > > We have heard nothing from the working group saying that they are > unhappy with the new section 9, and it seems clear. > > >> >> OLD: >> In , we propose a digest algorithm >> agility protocol. [Note: This section does not yet represent >> the rough consensus of the DANE working group and requires further >> discussion. Perhaps this belongs in a separate document.] >> >> NEW: >> In , we specify a digest algorithm >> agility protocol. > > > The Working Group reviewed this document, and we called consensus on > it (and then waited a bit to see if anyone came out of the woodwork, > looking sad), and so I believe that this *does* have WG consensus, and > so the [Note:...] can be removed. Although I wouldn't call this a "protocol" since it describes desirable client behavior and not an over-the-wire negotiation, the proposed text seems fine to me. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed May 27 02:03:25 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748F51A9041 for ; Wed, 27 May 2015 02:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FcsSBPls4SD for ; Wed, 27 May 2015 02:03:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD931A0406 for ; Wed, 27 May 2015 02:03:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWO27760; Wed, 27 May 2015 09:03:15 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0158.001; Wed, 27 May 2015 10:03:12 +0100 From: Hosnieh Rafiee To: dane WG list Thread-Topic: Any open source implementation? Thread-Index: AdCYW/UOTSuU0IpcTjelP0Y4+pHTuQ== Date: Wed, 27 May 2015 09:03:11 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A70154B64F@lhreml504-mbs> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [dane] Any open source implementation? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 27 May 2015 09:03:24 -0000 Hello, Is there any open source implementation of DANE? Would you please share the= link (perhaps not to the list to avoid noises but to me directly) Thanks, Best, Hosnieh From nobody Wed May 27 03:10:47 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657F21AC446; Wed, 27 May 2015 03:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRNFeeaMATXJ; Wed, 27 May 2015 03:10:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7118E1AC44D; Wed, 27 May 2015 03:10:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150527101042.30531.71530.idtracker@ietfa.amsl.com> Date: Wed, 27 May 2015 03:10:42 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-ops-09.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 10:10:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Updates to and Operational Guidance for the DANE Protocol Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-ops-09.txt Pages : 29 Date : 2015-05-27 Abstract: This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification based on subsequent implementation experience. It also contains guidance for implementers, operators and protocol developers who want to make use of DANE records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-ops-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 27 03:53:53 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC791A90EB for ; Wed, 27 May 2015 03:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xr11AN5mrHtA for ; Wed, 27 May 2015 03:53:51 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3647D1A87C5 for ; Wed, 27 May 2015 03:53:51 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7A5F0283031; Wed, 27 May 2015 10:53:49 +0000 (UTC) Date: Wed, 27 May 2015 10:53:49 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150527105349.GG2342@mournblade.imrryr.org> References: <814D0BFB77D95844A01CA29B44CBF8A70154B64F@lhreml504-mbs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A70154B64F@lhreml504-mbs> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Any open source implementation? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 10:53:52 -0000 On Wed, May 27, 2015 at 09:03:11AM +0000, Hosnieh Rafiee wrote: > Is there any open source implementation of DANE? Would you please share > the link (perhaps not to the list to avoid noises but to me directly) As yet, there is no robust DANE support in mainstream TLS libraries. You can find preliminary DANE support based on OpenSSL in: https://github.com/vdukhovni/ssl_dane This works with OpenSSL 1.0.0 and later. The application is responsible for all DNSSEC TLSA record lookups, the library uses TLSA records provided by the application to verify the TLS peer. The above is not intended to be supported after DANE is made available directly in OpenSSL. Also the source is the documentation. This is for early adopters only, not a long-term API. -- Viktor. From nobody Wed May 27 04:45:06 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301D11ACD0A for ; Wed, 27 May 2015 04:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gA07bXcPViU for ; Wed, 27 May 2015 04:45:04 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E472B1ACE09 for ; Wed, 27 May 2015 04:45:03 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9418E283031; Wed, 27 May 2015 11:45:02 +0000 (UTC) Date: Wed, 27 May 2015 11:45:02 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150527114502.GH2342@mournblade.imrryr.org> References: <20150514010741.GI17272@mournblade.imrryr.org> <20150514050948.GL17272@mournblade.imrryr.org> <1431596694.3274731.268516193.7C170F5C@webmail.messagingengine.com> <20150515060332.GX17272@mournblade.imrryr.org> <20150516054211.GF17272@mournblade.imrryr.org> <20150521222428.GL17272@mournblade.imrryr.org> <20150526232412.GC2342@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150526232412.GC2342@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt (chair guidance request) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 11:45:05 -0000 On Tue, May 26, 2015 at 11:24:12PM +0000, Viktor Dukhovni wrote: > > Take them if you like them, or ignore if you don't.... > > I'll post a new version later today (I'm in Australia today, > so for most of you, my later today will be your tomorrow). Done, please confirm that diffs are acceptable. -- Viktor. From nobody Wed May 27 06:01:35 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CF11A88BE for ; Wed, 27 May 2015 06:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkQtvm_brQIi for ; Wed, 27 May 2015 06:01:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761A81A88D5 for ; Wed, 27 May 2015 06:01:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTA19624; Wed, 27 May 2015 13:01:27 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Wed, 27 May 2015 14:01:07 +0100 From: Hosnieh Rafiee To: "dane@ietf.org" Thread-Topic: [dane] Any open source implementation? Thread-Index: AdCYW/UOTSuU0IpcTjelP0Y4+pHTuQABxKGAAAZ7BaA= Date: Wed, 27 May 2015 13:01:07 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A70154B719@lhreml504-mbs> References: <814D0BFB77D95844A01CA29B44CBF8A70154B64F@lhreml504-mbs> <20150527105349.GG2342@mournblade.imrryr.org> In-Reply-To: <20150527105349.GG2342@mournblade.imrryr.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [dane] Any open source implementation? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 27 May 2015 13:01:34 -0000 > > Is there any open source implementation of DANE? Would you please > > share the link (perhaps not to the list to avoid noises but to me > > directly) >=20 > As yet, there is no robust DANE support in mainstream TLS libraries. >=20 > You can find preliminary DANE support based on OpenSSL in: >=20 > https://github.com/vdukhovni/ssl_dane >=20 > This works with OpenSSL 1.0.0 and later. The application is > responsible for all DNSSEC TLSA record lookups, the library uses TLSA > records provided by the application to verify the TLS peer. >=20 > The above is not intended to be supported after DANE is made available > directly in OpenSSL. Also the source is the documentation. >=20 > This is for early adopters only, not a long-term API. >=20 > -- > Viktor. Thanks a lot! Best, Hosnieh From nobody Wed May 27 11:14:23 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879C51A899F; Wed, 27 May 2015 11:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd9_ICkO5NCl; Wed, 27 May 2015 11:14:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A18E1A1AAE; Wed, 27 May 2015 11:14:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150527181420.21608.62150.idtracker@ietfa.amsl.com> Date: Wed, 27 May 2015 11:14:20 -0700 Archived-At: Cc: dane-chairs@ietf.org, dane@ietf.org, draft-ietf-dane-smtp-with-dane@ietf.org, draft-ietf-dane-smtp-with-dane.ad@ietf.org, draft-ietf-dane-smtp-with-dane.shepherd@ietf.org Subject: [dane] Ben Campbell's Yes on draft-ietf-dane-smtp-with-dane-18: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 18:14:21 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dane-smtp-with-dane-18: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this. I only have a few trivial comments: 2.1.3, first paragraph: The seems redundant to similar normative language in 2.1.1 2.1.3, last paragraph: "...it may need to issue a separate query..." I assume that means it also may _not_ need to do so. Is it worth elaborating on that case? Editorial: 2.3.3, first sentence: This is pretty convoluted. You might consider breaking it into a few simpler sentences. From nobody Wed May 27 11:44:02 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47141A1B12 for ; Wed, 27 May 2015 11:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCm4e6zDksFT for ; Wed, 27 May 2015 11:43:59 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DBCD1A19F4 for ; Wed, 27 May 2015 11:43:59 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so102430540wic.0 for ; Wed, 27 May 2015 11:43:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=bpHEApPNeFKMUwO34PcZtpEGXT4e6U1XZx04sVJKjbs=; b=haqFbp6/efuP+dx3QZU23FIWM8S6ThnIKDxDgbz8bOS9OlGB3VVx+OEaa7t34Ilq8m VAjwgdZWRuKkAb6qw8zjDxLeNsc2/sA73po6aJrYxtROSL3Bm97GLHGGBxrqYu/t5nnZ P4m/K8uIM7clAqwLzMExtWl/DVLHMNutYG/Jh0T02OG5zp4WGUUoGFa7NMC6wnrIovol HYmBFZOKAmZFwrV6/YJL9G5W2rDUP2B1kgtbPM43ribhK/SHQt89aE2KmkdJqlUkZmAX FL3zi6mQ9J7TUzwbWlS1IJ6iBcMkLatb0uGlBCa4JQQlDBRdAeTL9yPqpGm8f0ZANYlm NqcQ== X-Gm-Message-State: ALoCoQmU+91Ch12TgAu09SDZ3438MtSvRKpE6k5qxYX5H6/UEGHJi56VAtZKt81vuMagadWlDct9 MIME-Version: 1.0 X-Received: by 10.181.27.131 with SMTP id jg3mr52580068wid.89.1432752238226; Wed, 27 May 2015 11:43:58 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Wed, 27 May 2015 11:43:58 -0700 (PDT) Date: Wed, 27 May 2015 14:43:58 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dane] Agenda requests for Prague. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 27 May 2015 18:44:01 -0000 Hi all, We have requested a slot at the upcoming meeting in Prague (IETF93). Please send over agenda requests if you would like some time. We give priority to drafts that have received significant discussion and have open issues. If we do not have sufficient material to justify meeting we will cancel the meeting slot. W -- 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. ---maf From nobody Wed May 27 12:03:13 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB641A9030 for ; Wed, 27 May 2015 12:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOkK1RcePFgj for ; Wed, 27 May 2015 12:03:11 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2790A1A8ACC for ; Wed, 27 May 2015 12:02:54 -0700 (PDT) Received: by wizk4 with SMTP id k4so122290371wiz.1 for ; Wed, 27 May 2015 12:02:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=drjB1/XEtiTcxSRzgKG/PDegLE3zEh78ft57ixHa10s=; b=jnPVWd943kfJTOvi8TuDoSM1KRmlCGIIPPxOKqjmOD9558Wlg2UCxPwgKlHtn8rVyM xXG6VvUvcuX32vAsN55QXIHSbWNiV6Zrm5tQ68hQi85fHXyO/X7KVUQtzoGEfo0VeSD2 CUlWHg8TCOypAtlk3IMW9SS1y0ZU94SPFnr4Yz1Fk829d9L/EzFNCRxxBp9dDoV2qOoZ pGdMaqkjXA0w+jGoPDN1S28zrRsm1zbHdDduF107tdE7B00g7RpzySnVkkJCEGJs4INb L8z/4i5+cHEqoRCrVVPgdrJ6kqmBzPkXIQSD3wRZqRaFlSP8x7IIyGKtK173yYZTfp0u mv9Q== X-Gm-Message-State: ALoCoQkF5r4W6bqvbElpUOdQWW9bqVYhwzYIusHy/lmBJuU6o/PhWk1T/abAPgO4JGSJfGfIVN3S MIME-Version: 1.0 X-Received: by 10.180.77.34 with SMTP id p2mr8756949wiw.22.1432753372939; Wed, 27 May 2015 12:02:52 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Wed, 27 May 2015 12:02:52 -0700 (PDT) In-Reply-To: <20150527114502.GH2342@mournblade.imrryr.org> References: <20150514010741.GI17272@mournblade.imrryr.org> <20150514050948.GL17272@mournblade.imrryr.org> <1431596694.3274731.268516193.7C170F5C@webmail.messagingengine.com> <20150515060332.GX17272@mournblade.imrryr.org> <20150516054211.GF17272@mournblade.imrryr.org> <20150521222428.GL17272@mournblade.imrryr.org> <20150526232412.GC2342@mournblade.imrryr.org> <20150527114502.GH2342@mournblade.imrryr.org> Date: Wed, 27 May 2015 15:02:52 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt (chair guidance request) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 27 May 2015 19:03:12 -0000 LGTM. On Wed, May 27, 2015 at 7:45 AM, Viktor Dukhovni wrote: > On Tue, May 26, 2015 at 11:24:12PM +0000, Viktor Dukhovni wrote: > >> > Take them if you like them, or ignore if you don't.... >> >> I'll post a new version later today (I'm in Australia today, >> so for most of you, my later today will be your tomorrow). > > Done, please confirm that diffs are acceptable. > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- 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. ---maf From nobody Wed May 27 16:56:57 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5081B2ADF; Wed, 27 May 2015 16:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FTijjHj5Rpp; Wed, 27 May 2015 16:56:41 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4811ACD11; Wed, 27 May 2015 16:56:31 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 926E4283031; Wed, 27 May 2015 23:56:30 +0000 (UTC) Date: Wed, 27 May 2015 23:56:30 +0000 From: Viktor Dukhovni To: The IESG , draft-ietf-dane-smtp-with-dane@ietf.org, draft-ietf-dane-smtp-with-dane.shepherd@ietf.org, dane-chairs@ietf.org, draft-ietf-dane-smtp-with-dane.ad@ietf.org, dane@ietf.org Message-ID: <20150527235630.GI2342@mournblade.imrryr.org> References: <20150527181420.21608.62150.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150527181420.21608.62150.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Ben Campbell's Yes on draft-ietf-dane-smtp-with-dane-18: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 27 May 2015 23:56:44 -0000 On Wed, May 27, 2015 at 11:14:20AM -0700, Ben Campbell wrote: > 2.1.3, first paragraph: > > The seems redundant to similar normative language in 2.1.1 Indeed this repeats language in 2.1.1, if restating the requirement is frowned upon, this can be deleted. > 2.1.3, last paragraph: "...it may need to issue a > separate query..." > > I assume that means it also may _not_ need to do so. Is it worth > elaborating on that case? The "may" is really a "will" conditional on the initial premise. Perhaps one reason for the tentative tone, is that I was guessing that some implementations would not go the extra mile to support DANE with servers whose A/AAAA records are CNAME aliases into "insecure" zones. That is: ; The TLSA record in this secure zone is likely to not get used, ; because the A record is insecure, and implementations are likely ; to not bother with the additional "IN CNAME" query that distinguishes ; this from both zones being insecure. ; smtp.example.com. IN CNAME smtp.example.net. ; secure zone example.com _25._tcp.smtp.example.com. IN TLSA 3 1 1 ... ; ditto smtp.example.net. IN A 192.0.2.1 ; insecure zone example.net Indeed while Postfix makes the extra CNAME query, IIRC Exim does not. This is rather a corner case, because MX hostnames are in any case not supposed to be CNAME aliases, and most email domains have MX records, and MX hosts that are CNAME aliases are rare. So I guess that this is an optional behaviour for MTAs that choose to support DANE even in this corner case. Does this need additional text in the document, or can we leave to implementors to reach their own conclusions once they understand that "insecure" CNAME responses for A/AAAA records can be returned from "secure" zones when the CNAME target is an "insecure" zone. (I might note that the same considerations apply to the DANE SRV draft, but that document is much less detail oriented, and does not discuss the issue at all). > Editorial: > > 2.3.3, first sentence: This is pretty convoluted. You might consider > breaking it into a few simpler sentences. As there is no "2.3.3", I assume you mean "2.2.3", which is indeed complex. For a particular SMTP server, the associated TLSA base domain is either the server hostname or, when that hostname is an alias (CNAME or DNAME), possibly its fully alias-expanded name if every stage in the alias expansion is "secure". This yields either one or two candidate TLSA base domains for the SMTP server. When there are two candidate TLSA base domains, the alias-expanded domain name has a higher precedence (is tried first). The first of these to yield a "secure" TLSA RRSet is the final TLSA base domain. Each candidate TLSA base domain (alias-expanded or original) is in turn prefixed with service labels of the form "_._tcp". The resulting domain name is used to issue a DNSSEC query with the query type set to TLSA ([RFC6698] Section 7.1). How about the following: When the SMTP server's hostname is not a CNAME or DNAME alias, the list of associated candidate TLSA base domains (see below) consists of just the server hostname. When hostname is an alias with a "secure" (at every stage) full expansion, the list of candidate TLSA base domains (see below) is a pair of domains: the fully expanded server hostname first and the unexpanded server hostname second. Each candidate TLSA base domain (alias-expanded or original) is in turn prefixed with service labels of the form "_._tcp". The resulting domain name is used to issue a DNSSEC query with the query type set to TLSA ([RFC6698] Section 7.1). The first of these candidate domains to yield a "secure" TLSA RRSet becomes the actual TLSA base domain. Is that better? -- Viktor. From nobody Wed May 27 20:33:05 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B141A1AC6; Wed, 27 May 2015 20:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaQKoYp-AqPd; Wed, 27 May 2015 20:33:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08A81A1B48; Wed, 27 May 2015 20:33:01 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4S3WkI6079307 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 May 2015 22:32:56 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Viktor Dukhovni" Date: Wed, 27 May 2015 22:32:46 -0500 Message-ID: <769F276E-58B2-4065-BA36-8005E2F8D15C@nostrum.com> In-Reply-To: <20150527235630.GI2342@mournblade.imrryr.org> References: <20150527181420.21608.62150.idtracker@ietfa.amsl.com> <20150527235630.GI2342@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: dane-chairs@ietf.org, dane@ietf.org, draft-ietf-dane-smtp-with-dane@ietf.org, The IESG , draft-ietf-dane-smtp-with-dane.ad@ietf.org, draft-ietf-dane-smtp-with-dane.shepherd@ietf.org Subject: Re: [dane] Ben Campbell's Yes on draft-ietf-dane-smtp-with-dane-18: (with COMMENT) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 28 May 2015 03:33:04 -0000 On 27 May 2015, at 18:56, Viktor Dukhovni wrote: > On Wed, May 27, 2015 at 11:14:20AM -0700, Ben Campbell wrote: > >> 2.1.3, first paragraph: >> >> The seems redundant to similar normative language in 2.1.1 > > Indeed this repeats language in 2.1.1, if restating the requirement > is frowned upon, this can be deleted. It's not necessarily broken, but it's not optimal. It's no problem as long as they agree, but it can be error prone for future updates, if any ever happen. > >> 2.1.3, last paragraph: "...it may need to issue a >> separate query..." >> >> I assume that means it also may _not_ need to do so. Is it worth >> elaborating on that case? > > The "may" is really a "will" conditional on the initial premise. > > Perhaps one reason for the tentative tone, is that I was guessing > that some implementations would not go the extra mile to support > DANE with servers whose A/AAAA records are CNAME aliases into > "insecure" zones. That is: > > ; The TLSA record in this secure zone is likely to not get used, > ; because the A record is insecure, and implementations are likely > ; to not bother with the additional "IN CNAME" query that > distinguishes > ; this from both zones being insecure. > ; > smtp.example.com. IN CNAME smtp.example.net. ; secure zone > example.com > _25._tcp.smtp.example.com. IN TLSA 3 1 1 ... ; ditto > > smtp.example.net. IN A 192.0.2.1 ; insecure zone example.net > > Indeed while Postfix makes the extra CNAME query, IIRC Exim does > not. This is rather a corner case, because MX hostnames are in > any case not supposed to be CNAME aliases, and most email domains > have MX records, and MX hosts that are CNAME aliases are rare. > > So I guess that this is an optional behaviour for MTAs that choose > to support DANE even in this corner case. > > Does this need additional text in the document, or can we leave to > implementors to reach their own conclusions once they understand > that "insecure" CNAME responses for A/AAAA records can be returned > from "secure" zones when the CNAME target is an "insecure" zone. > > (I might note that the same considerations apply to the DANE SRV > draft, but that document is much less detail oriented, and does > not discuss the issue at all). Would it make sense to say something like "When this occurs, if a client needs to determine the security status ... , it _needs_ to issue a separate query..." That is, drop the "may", but still leave it conditional? > >> Editorial: >> >> 2.3.3, first sentence: This is pretty convoluted. You might consider >> breaking it into a few simpler sentences. > > As there is no "2.3.3", I assume you mean "2.2.3", which is indeed > complex. > > For a particular SMTP server, the associated TLSA base domain is > either the server hostname or, when that hostname is an alias (CNAME > or DNAME), possibly its fully alias-expanded name if every stage in > the alias expansion is "secure". This yields either one or two > candidate TLSA base domains for the SMTP server. When there are two > candidate TLSA base domains, the alias-expanded domain name has a > higher precedence (is tried first). The first of these to yield a > "secure" TLSA RRSet is the final TLSA base domain. > > Each candidate TLSA base domain (alias-expanded or original) is in > turn prefixed with service labels of the form "_._tcp". The > resulting domain name is used to issue a DNSSEC query with the query > type set to TLSA ([RFC6698] Section 7.1). > > How about the following: > > When the SMTP server's hostname is not a CNAME or DNAME alias, > the list of associated candidate TLSA base domains (see below) > consists of just the server hostname. > > When hostname is an alias with a "secure" (at every stage) full > expansion, the list of candidate TLSA base domains (see below) > is a pair of domains: the fully expanded server hostname first > and the unexpanded server hostname second. > > Each candidate TLSA base domain (alias-expanded or original) is in > turn prefixed with service labels of the form "_._tcp". The > resulting domain name is used to issue a DNSSEC query with the query > type set to TLSA ([RFC6698] Section 7.1). > > The first of these candidate domains to yield a "secure" TLSA > RRSet becomes the actual TLSA base domain. > > Is that better? Much, than you. Thanks! Ben. From nobody Fri May 29 05:48:09 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55CC1A8894; Fri, 29 May 2015 05:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kxVfjmfIeqO; Fri, 29 May 2015 05:48:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE47A1A88A5; Fri, 29 May 2015 05:48:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150529124805.4991.91912.idtracker@ietfa.amsl.com> Date: Fri, 29 May 2015 05:48:05 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-ops-10.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 12:48:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Updates to and Operational Guidance for the DANE Protocol Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-ops-10.txt Pages : 29 Date : 2015-05-29 Abstract: This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC6698) based on subsequent implementation experience. It also contains guidance for implementers, operators and protocol developers who want to make use of DANE records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-ops-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 29 07:53:06 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAD11A8A23; Fri, 29 May 2015 07:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDqqJ5JkkCtP; Fri, 29 May 2015 07:53:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE161ABB19; Fri, 29 May 2015 07:53:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150529145300.17253.35992.idtracker@ietfa.amsl.com> Date: Fri, 29 May 2015 07:53:00 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 14:53:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : SMTP security via opportunistic DANE TLS Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-smtp-with-dane-19.txt Pages : 32 Date : 2015-05-29 Abstract: This memo describes a downgrade-resistant protocol for SMTP transport security between Mail Transfer Agents (MTAs) based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 29 08:36:30 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9A01AC3EF for ; Fri, 29 May 2015 08:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93H4SC_WF6D4 for ; Fri, 29 May 2015 08:36:25 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368671A9301 for ; Fri, 29 May 2015 08:36:25 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9C3ED208B4 for ; Fri, 29 May 2015 11:36:24 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute4.internal (MEProxy); Fri, 29 May 2015 11:36:24 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=rdvzWycrxsDQde/CvNXRfobPp8U=; b=DC+Aau qcNvdWYpxJujfalXmGLE0nL4GrRjWTQuSGqSJkDufigiB+hwYJLxpV0r6o0nkFJq yJP4u0i9BesCM1czgKcofsqGzMVqKFXA3jcR8vzuOHub7g4RtwH2Ixz8cKq7QUz6 FkZJ7BWJm7j/2UIzCxcf1bpz70kPiG6SE2jPQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=rdvzWycrxsDQde/ CvNXRfobPp8U=; b=OfWVXFk2H96FuTlfPx7LK2ykpgo+sWp+0AfLLwELFfkduPy arTZR9YzZzCoT5rUPnPl4xhDkNre81b/k+dOy8iCUP2XWTxBytOtoxtNGQjwEVS2 dFIJ4jT1QbEMYz4ysHrgtszX7iZNOP4BKWYFMKhMNRol1gCrqHtWhy+LNwZY= Received: by web6.nyi.internal (Postfix, from userid 99) id 74A16440E8; Fri, 29 May 2015 11:36:24 -0400 (EDT) Message-Id: <1432913784.1547477.281537633.6AC1BCE5@webmail.messagingengine.com> X-Sasl-Enc: Dq5bFq/7lnbAnWwR2ETWdorLpFncicthMoDMicaYk/Ka 1432913784 From: nudge To: dane@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-073992ec Date: Fri, 29 May 2015 17:36:24 +0200 In-Reply-To: <20150529124805.4991.91912.idtracker@ietfa.amsl.com> References: <20150529124805.4991.91912.idtracker@ietfa.amsl.com> Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-10.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 15:36:26 -0000 Tiny nits: Section 5.1 - Paragraph 4: (i.e., the[y] may ignore the client's SNI message) Section 8.2 - Paragraph 1: A more complex [?] involves switching to a trust-anchor or PKIX usage from a chain that is either self-signed, or issued by a private CA and thus not compatible with PKIX. Section 8.4: o Extend the TLSA RRset with a new combination of parameters (usage, selector and matching type) that [is] used to generate matching associations for all certificate chains that are published with some other parameter combination. From nobody Fri May 29 16:05:16 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C271A8A62; Fri, 29 May 2015 16:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOnKg6v5XRDq; Fri, 29 May 2015 16:05:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B29E91A90A1; Fri, 29 May 2015 16:05:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150529230510.22375.78210.idtracker@ietfa.amsl.com> Date: Fri, 29 May 2015 16:05:10 -0700 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-ops-11.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 23:05:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Updates to and Operational Guidance for the DANE Protocol Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-ops-11.txt Pages : 29 Date : 2015-05-29 Abstract: This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC6698) based on subsequent implementation experience. It also contains guidance for implementers, operators and protocol developers who want to make use of DANE records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-ops-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 29 16:10:38 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B301A90D3 for ; Fri, 29 May 2015 16:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny9DJgjQTklv for ; Fri, 29 May 2015 16:10:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BFE21A907F for ; Fri, 29 May 2015 16:10:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 534EB283015; Fri, 29 May 2015 23:10:33 +0000 (UTC) Date: Fri, 29 May 2015 23:10:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150529231033.GU2342@mournblade.imrryr.org> References: <20150529124805.4991.91912.idtracker@ietfa.amsl.com> <1432913784.1547477.281537633.6AC1BCE5@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432913784.1547477.281537633.6AC1BCE5@webmail.messagingengine.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-10.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 23:10:37 -0000 On Fri, May 29, 2015 at 05:36:24PM +0200, nudge wrote: > Tiny nits: > > Section 5.1 - Paragraph 4: > > (i.e., the[y] may ignore > the client's SNI message) > > Section 8.2 - Paragraph 1: > > A more complex [?] involves switching to a trust-anchor or PKIX usage > from a chain that is either self-signed, or issued by a private CA > and thus not compatible with PKIX. Thanks fixed in -11. This example also needed to be simplified a bit. -- Viktor.