From paulitrix@gmail.com Sun Nov 3 12:38:27 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C58C21F9E11 for ; Sun, 3 Nov 2013 12:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1VTB+ApJ1g8 for ; Sun, 3 Nov 2013 12:38:26 -0800 (PST) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9136A11E80E3 for ; Sun, 3 Nov 2013 12:38:20 -0800 (PST) Received: by mail-bk0-f51.google.com with SMTP id my12so768673bkb.38 for ; Sun, 03 Nov 2013 12:38:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=S8K+eqBojAVKCq6DumQHMYR8h+M7mIWCHMpdN52PeN8=; b=ufkD+gm2ABtoyQYce+68nDrvYFnHVmhAMCPzZSBrtW/D+yAADw5755ugRmTzRFDdDE GdNTj2Qc3MilYWNgnfTgZAKAPqQO7mPVAguAq83rpm9H0KvejnKAz7O7v6N8lyrShHwv TsHjOYs+biWL+/13/HO/5DxYdd7tL8p7Az49Ys0dHcvjUPLTaaqJuvdsgRFVFel7Lth1 Ko9avjkzbr60E7+ocgTCvR24OyoDHrw0NOXw3N8cX/9oeicBfiy7FwUFc64jbJpSEOEM vfurq+vwPxdML2dKZKqqbZkBgVz/V49ND8R3flvhgmh2uOoMPf3x+yoQTouyL42iAcwt NR+A== X-Received: by 10.204.167.140 with SMTP id q12mr7015015bky.2.1383511099658; Sun, 03 Nov 2013 12:38:19 -0800 (PST) Received: from ?IPv6:2001:67c:370:144:6999:6fa3:76f4:bea8? ([2001:67c:370:144:6999:6fa3:76f4:bea8]) by mx.google.com with ESMTPSA id pu8sm12490112bkb.9.2013.11.03.12.38.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 12:38:18 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Paul M In-Reply-To: Date: Sun, 3 Nov 2013 12:38:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <39820722-5645-481F-ABDE-456C5B1965D9@gmail.com> References: To: dane@ietf.org X-Mailer: Apple Mail (2.1816) Subject: [dane] Meetup at IETF 88 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 20:38:27 -0000 I noticed in the IETF 88 agenda that there will be no DANE working group = session. As I am pretty new to this group, I would like to meet some = members who are attending the IETF meeting in person to discuss = Internet drafts and would gladly volunteer to review some of the drafts. = Where can we meet and what time?=20 =97=97=97=97=97=97 Paul M= From paul@cypherpunks.ca Sun Nov 3 21:52:01 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2513121E80CB for ; Sun, 3 Nov 2013 21:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guOSYWWxGhkB for ; Sun, 3 Nov 2013 21:51:55 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id B5C7321E8119 for ; Sun, 3 Nov 2013 21:51:52 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3dCjnJ3wSwz774; Mon, 4 Nov 2013 00:51:48 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id XP8QTyRG-wFS; Mon, 4 Nov 2013 00:51:46 -0500 (EST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 4 Nov 2013 00:51:46 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id ADEE1807CA; Mon, 4 Nov 2013 00:51:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9CD71800A9; Mon, 4 Nov 2013 00:51:42 -0500 (EST) Date: Mon, 4 Nov 2013 00:51:42 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Paul M In-Reply-To: <39820722-5645-481F-ABDE-456C5B1965D9@gmail.com> Message-ID: References: <39820722-5645-481F-ABDE-456C5B1965D9@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane WG list Subject: Re: [dane] Meetup at IETF 88 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 05:52:01 -0000 On Sun, 3 Nov 2013, Paul M wrote: > I noticed in the IETF 88 agenda that there will be no DANE working group session. As I am pretty new to this group, I would like to meet some members who are attending the IETF meeting in person to discuss Internet drafts and would gladly volunteer to review some of the drafts. Where can we meet and what time? I'm around, more free time on thu/fri for meetups. Paul From paul.hoffman@vpnc.org Mon Nov 4 11:09:00 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A9521E81F6 for ; Mon, 4 Nov 2013 11:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-TFaV2PMVn8 for ; Mon, 4 Nov 2013 11:08:59 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 78E0E21E8099 for ; Mon, 4 Nov 2013 11:08:50 -0800 (PST) Received: from dhcp-b88d.meeting.ietf.org (dhcp-b88d.meeting.ietf.org [31.133.184.141]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rA4J8l8p030327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 4 Nov 2013 12:08:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> Date: Mon, 4 Nov 2013 11:08:46 -0800 To: "dane@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) X-Mailer: Apple Mail (2.1816) Subject: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:09:00 -0000 Hi again. I have put in a room request for lunch on Thursday; I'll let = the list know when I get it. If you're at the Vancouver IETF meeting and = want to talk about DANE, hold the date. We'll meet at 11:45 in order to = give people time to run out and get some food and bring it to the room; = no food or beverage will be provided. --Paul Hoffman= From mamille2@cisco.com Mon Nov 4 11:25:01 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E7F21E805F for ; Mon, 4 Nov 2013 11:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhrc-TrA6GK0 for ; Mon, 4 Nov 2013 11:24:55 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6B27911E81F7 for ; Mon, 4 Nov 2013 11:24:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1506; q=dns/txt; s=iport; t=1383593095; x=1384802695; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iS1hERHCxLOTG+waP2KEkGQZxSdfdhV+qE1Jx2RkpLE=; b=Vqsa14L9BxKC5SOAzqEov2ZVlTP1NhiYEv/BxECIaxnHMCaaOvVHLeGL Fe6waBw2qakKK7SX61vRmHWUxvU8+UwWSc8yHIlVJdZNhLW5booqT7xpo VNWdfLZ96VAftd7ne63RjiJn7vhlc/WhEVDNbmm2xdi5bgmh5ApTpQD7g Y=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFACb0d1KtJV2b/2dsb2JhbABZgweBC78/gSsWdIIlAQEBAwF5BQsCAQhGMiUCBA4FDodtBr5Qj1gHgyCBDgOQLoEwgk2DX5IJgyaCKg X-IronPort-AV: E=Sophos;i="4.93,634,1378857600"; d="asc'?scan'208";a="280599942" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 04 Nov 2013 19:24:55 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA4JOsKG025181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 19:24:54 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.19]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 13:24:54 -0600 From: "Matt Miller (mamille2)" To: Paul Hoffman Thread-Topic: [dane] Informal lunch meeting in Vancouver on Thursday Thread-Index: AQHO2ZFVM0sya7CkzkO4pXl+S1Ye4poV2IOA Date: Mon, 4 Nov 2013 19:24:54 +0000 Message-ID: References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> In-Reply-To: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.91] Content-Type: multipart/signed; boundary="Apple-Mail=_23D6A795-37BC-4F40-9CEC-BC1592F34392"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Cc: "dane@ietf.org list" Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:25:01 -0000 --Apple-Mail=_23D6A795-37BC-4F40-9CEC-BC1592F34392 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 4, 2013, at 11:08 AM, Paul Hoffman wrote: > Hi again. I have put in a room request for lunch on Thursday; I'll let = the list know when I get it. If you're at the Vancouver IETF meeting and = want to talk about DANE, hold the date. We'll meet at 11:45 in order to = give people time to run out and get some food and bring it to the room; = no food or beverage will be provided. >=20 I would be interested. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_23D6A795-37BC-4F40-9CEC-BC1592F34392 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSd/SDAAoJEDWi+S0W7cO1PzQIAJAd/wUCjQDX8HCa9naclWaG /ZuvxWf/1Vl/OjOurdnx503NIpAlpQ18vuEJ7hBQG4Y3QLlBSfq1n4640IhiNQAJ 9ZqWJ61ZY0/JrK4tZJ/DEGj/PakMX85Q9LmrbVixWBVo145uOcgrHBRDA09L8Zec CxoFRGFVW/81z6+xbhMtA1APaaPoq5tRe9Jj8QxIyYY/bgoH5GYYAwECz5oilSvx 4iKKWamC3K9s54uc5Ib75ZtEuVJYdLvcaWHLo7iuliBKu+IWMxcDKG1unOe4I7h/ xO/KaVTkhGiYAEwSQT947o/hGLw3aobxlD7uy6B065ZisnesBSA8VJWVyD4LkHs= =oUCu -----END PGP SIGNATURE----- --Apple-Mail=_23D6A795-37BC-4F40-9CEC-BC1592F34392-- From paulitrix@gmail.com Mon Nov 4 11:35:55 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B1021E821C for ; Mon, 4 Nov 2013 11:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fi+oS-7554O7 for ; Mon, 4 Nov 2013 11:35:28 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 10D8521E80C4 for ; Mon, 4 Nov 2013 11:35:10 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id l4so3522426lbv.23 for ; Mon, 04 Nov 2013 11:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4xBvbHetJjnDRdOm65qkEAFkIgms0vL+zZnDO0IVnpM=; b=CQ2dSVVSo6JBkgV5C0YJyongEx2f+1UiVdbHZcjNpVL8Enb9nMntIKZM6IyCK20imD ffTTEWY04Qgq9AGVotPxISDUOiDJFiYK3Q1zq1a+uIyY+AtxRSlRbRZiJs+C9psGR+t/ UUmJoawNEmtz5ZYu7FbZdCfcKzQmRpPx+x2doDBszidYBZQMgt/CZNb3unYbhLQLVD2s 89+IW6w3rIRXGWACHzpeW+0ksx9zyloH3EYNYyAUbsfDer1bJYdL/u19wF7ZwBQDrF3f YLlWPHSnlBeuXnVy+0qiGku86fnJYzrAPWpu1ptfajEkHwVbjRLIClytLA8HE8znXLyT HSAw== X-Received: by 10.152.26.72 with SMTP id j8mr13046346lag.19.1383593709993; Mon, 04 Nov 2013 11:35:09 -0800 (PST) Received: from dhcp-9715.meeting.ietf.org (dhcp-9715.meeting.ietf.org. [31.133.151.21]) by mx.google.com with ESMTPSA id ed8sm13873220lbc.11.2013.11.04.11.35.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 11:35:09 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Paul M In-Reply-To: Date: Mon, 4 Nov 2013 11:35:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4049C760-EC66-41D5-9F10-C2CB453611CC@gmail.com> References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> To: "Matt Miller (mamille2)" X-Mailer: Apple Mail (2.1816) Cc: Paul Hoffman , "dane@ietf.org list" Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:35:55 -0000 +1 Will be there.=20 On 4/11/2013, at 11:24 am, Matt Miller (mamille2) = wrote: >=20 > On Nov 4, 2013, at 11:08 AM, Paul Hoffman = wrote: >=20 >> Hi again. I have put in a room request for lunch on Thursday; I'll = let the list know when I get it. If you're at the Vancouver IETF meeting = and want to talk about DANE, hold the date. We'll meet at 11:45 in order = to give people time to run out and get some food and bring it to the = room; no food or beverage will be provided. >>=20 >=20 > I would be interested. >=20 >=20 > - m&m >=20 > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From stpeter@stpeter.im Mon Nov 4 11:54:24 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BA121E8225 for ; Mon, 4 Nov 2013 11:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYcXJCbjq-18 for ; Mon, 4 Nov 2013 11:54:20 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 944E311E8175 for ; Mon, 4 Nov 2013 11:54:15 -0800 (PST) Received: from sjc-vpn5-650.cisco.com (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D485D4010C; Mon, 4 Nov 2013 12:54:14 -0700 (MST) Message-ID: <5277FB66.406@stpeter.im> Date: Mon, 04 Nov 2013 11:54:14 -0800 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Matt Miller (mamille2)" , Paul Hoffman References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dane@ietf.org list" Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:54:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/4/13 11:24 AM, Matt Miller (mamille2) wrote: > > On Nov 4, 2013, at 11:08 AM, Paul Hoffman > wrote: > >> Hi again. I have put in a room request for lunch on Thursday; >> I'll let the list know when I get it. If you're at the Vancouver >> IETF meeting and want to talk about DANE, hold the date. We'll >> meet at 11:45 in order to give people time to run out and get >> some food and bring it to the room; no food or beverage will be >> provided. >> > > I would be interested. I am interested but I have a conflict. I securely delegate all feedback to Matt. :-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSd/tmAAoJEOoGpJErxa2pD6IQAKjdseT7gea+2hybWxXBgMtc ijedrWUmtTU09TvGCK/UJ3o/bsqcy/pacYN5qmgkNGL7p9G2YLo0m+TgWlq9xvto RxP4kk52gFslKEhRS4pwkqWvSGRR8br6V6ZdBbyMOgePdguTLGzwFzLWwJXXekYt 6rHZ+f0BsyBWyxAH6NWxf21ZJovTqSNOQ2TUoPkAB0TFoxm5jAc2daVrsk0LALhE WAV/y5v6jm/VD9EYg54FesS6nsd081qRiXfWpOnV4IK75b6JKec+niS7/ji8FPhI O6nLLSPDYSIGxpE0DUSROGLeTM/Oc9yclIxILpZCaIJpiwrrJOnEYkNoAwzi0bYn PrGsISm56qcJddoZcqheC7LMzNu6p9IaWzK8nEd5UCxvBsvEv8OoRyy/CLMWWovs cwtdK2uFsaToVc77Kt5+fS2Q4MA+p49NCJwREbJYnad1J+ej1qxpgy5WsNps7jeg kWlj1SMohTDRc1tVa4Nx+BPirSQujWbymxlHx1LD70ePRCJKgKWntJfdugMRjGgS Y3laAVOLjkJVJsrdz7YKOJN9Sfrac5ZcrXB0DohLKnjt9olQgh5ue3BUQZqHTMKm V+HyPW+poxohQDh3ZXmiTtpaOs4aWgWGwOJJT8ZBYkPqbr1n0HaDf4WdN6RkVQCy h9WMiN4I1Jey5NiCg6f2 =aKvN -----END PGP SIGNATURE----- From warren@kumari.net Mon Nov 4 12:09:04 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B9621E81BC for ; Mon, 4 Nov 2013 12:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1A28PFyqXi4t for ; Mon, 4 Nov 2013 12:08:59 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2763E11E8175 for ; Mon, 4 Nov 2013 12:08:51 -0800 (PST) Received: from [31.130.224.70] (unknown [31.130.224.70]) by vimes.kumari.net (Postfix) with ESMTPSA id 6EC4E1B40316; Mon, 4 Nov 2013 15:08:50 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> Date: Mon, 4 Nov 2013 12:08:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <90B09F3E-2D11-4127-A5BB-9D243AB31097@kumari.net> References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1510) Cc: "dane@ietf.org list" Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 20:09:04 -0000 On Nov 4, 2013, at 11:08 AM, Paul Hoffman wrote: > Hi again. I have put in a room request for lunch on Thursday; I'll let = the list know when I get it. If you're at the Vancouver IETF meeting and = want to talk about DANE, hold the date. We'll meet at 11:45 in order to = give people time to run out and get some food and bring it to the room; = no food or beverage will be provided. Thank you. Will be there. W >=20 > --Paul Hoffman > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 -- "Real children don't go hoppity-skip unless they are on drugs." -- Susan, the ultimate sensible governess (Terry Pratchett, = Hogfather) From stpeter@stpeter.im Mon Nov 4 12:20:51 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD6521E81F9 for ; Mon, 4 Nov 2013 12:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.379 X-Spam-Level: X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQGvoEFzdPwi for ; Mon, 4 Nov 2013 12:20:47 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5525911E8225 for ; Mon, 4 Nov 2013 12:20:45 -0800 (PST) Received: from sjc-vpn5-650.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D90A24010C; Mon, 4 Nov 2013 13:20:44 -0700 (MST) Message-ID: <5278019B.8040601@stpeter.im> Date: Mon, 04 Nov 2013 12:20:43 -0800 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Matt Miller (mamille2)" , Paul Hoffman References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <5277FB66.406@stpeter.im> In-Reply-To: <5277FB66.406@stpeter.im> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dane@ietf.org list" Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 20:20:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/4/13 11:54 AM, Peter Saint-Andre wrote: > On 11/4/13 11:24 AM, Matt Miller (mamille2) wrote: > >> On Nov 4, 2013, at 11:08 AM, Paul Hoffman >> wrote: > >>> Hi again. I have put in a room request for lunch on Thursday; >>> I'll let the list know when I get it. If you're at the >>> Vancouver IETF meeting and want to talk about DANE, hold the >>> date. We'll meet at 11:45 in order to give people time to run >>> out and get some food and bring it to the room; no food or >>> beverage will be provided. >>> > >> I would be interested. > > I am interested but I have a conflict. I securely delegate all > feedback to Matt. :-) In particular, I'm interested in moving the dane-srv document forward. If Tony doesn't have the cycles, I'd volunteer to help (because Matt and I need it to finish draft-ietf-xmpp-dna). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSeAGbAAoJEOoGpJErxa2pgC0QAI5rbzXTVtPF+ySsogQRVTm1 xjXC+ByEHKYBUmDc7QP1EKJcdSVP+3Ye9djXcOI9xYCH/qEFtb8NPS2e62ILhfJD y13Tr01NkVmtJUeXlXu2mSjUYiWq4MfQ6v2OPTfOpqca2wAJ0mw0sKHpMTxE3ci1 9ZiZPCI1NOSHTE4er0SY7dMY6B08xmEVUv6y2V2DNN7F3sjjS2gnqeyhhfOYdq/C 28vtlppkG5szHIEJf8eBZ+rv2xNF39k63CmkFetHlXdoTGCEc/aVowMDpFgM1nvM Gfuybj3N6aG1hTQUuXBBWXJ/ErODRbuizFFWLxfjTEtZQQ21PZLE8U/FlSCPPezq fDNLXngu++6Oos3TRYfFkPvRPWCk56Eratu6pev2/TUaOOhDHZr/qil7LURZrj6S FfIHs7C9+VCjpIq96oTC0I9IrkS36oE0twxhFk7fLWz+lx4X8LXOCPVKIXHQQsnF 1FLHdFX9DOQBOHCuAJO7FBy+Ps2LWQt0tPUcLIAtHaVZ9p1sLcEltUDVuQJe/jSO KJwE8NY3JStExozGVDyFPy0b1tKgiA+76JQ5ACBOseVxf9ye50/vKJn/M/iXgqbC 1LPaZnpazAUi910euWgn5pZ0yGl4RvIbFdg51lW/vhHVCTMw3RDMEYNlwlMx5wIe cquSHypQEInKN9J6BB+N =VQb0 -----END PGP SIGNATURE----- From ynir@checkpoint.com Mon Nov 4 13:10:09 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0789011E82DF for ; Mon, 4 Nov 2013 13:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.515 X-Spam-Level: X-Spam-Status: No, score=-10.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sn8YNYMx9cuo for ; Mon, 4 Nov 2013 13:10:03 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C285511E82D6 for ; Mon, 4 Nov 2013 13:09:58 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA4L9qPu030520; Mon, 4 Nov 2013 23:09:52 +0200 X-CheckPoint: {52780BC8-9-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 23:09:52 +0200 From: Yoav Nir To: Warren Kumari Thread-Topic: [dane] Informal lunch meeting in Vancouver on Thursday Thread-Index: AQHO2ZFYCu2znX5JDUSYO1NpZxC5N5oVXq+AgAARCgA= Date: Mon, 4 Nov 2013 21:09:51 +0000 Message-ID: <34609EE6-9B32-4A61-8C51-702CF019A711@checkpoint.com> References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <90B09F3E-2D11-4127-A5BB-9D243AB31097@kumari.net> In-Reply-To: <90B09F3E-2D11-4127-A5BB-9D243AB31097@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.194] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <9982D0811E44614893738B84709CE1FE@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , "dane@ietf.org list" Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:10:09 -0000 Me too. On Nov 4, 2013, at 12:08 PM, Warren Kumari wrote: >=20 > On Nov 4, 2013, at 11:08 AM, Paul Hoffman wrote: >=20 >> Hi again. I have put in a room request for lunch on Thursday; I'll let t= he list know when I get it. If you're at the Vancouver IETF meeting and wan= t to talk about DANE, hold the date. We'll meet at 11:45 in order to give p= eople time to run out and get some food and bring it to the room; no food o= r beverage will be provided. >=20 > Thank you. Will be there. >=20 > W From stephen.farrell@cs.tcd.ie Mon Nov 4 14:02:53 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315C221E81B8 for ; Mon, 4 Nov 2013 14:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RDl1AlM1NxN for ; Mon, 4 Nov 2013 14:02:48 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 32C0F21E8102 for ; Mon, 4 Nov 2013 14:02:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0453CBEB6; Mon, 4 Nov 2013 22:02:47 +0000 (GMT) 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 qCrxTCo-0XYc; Mon, 4 Nov 2013 22:02:45 +0000 (GMT) Received: from [31.133.161.177] (dhcp-a1b1.meeting.ietf.org [31.133.161.177]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 16FEBBEB0; Mon, 4 Nov 2013 22:02:44 +0000 (GMT) Message-ID: <52781983.4000609@cs.tcd.ie> Date: Mon, 04 Nov 2013 22:02:43 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Paul Hoffman , "dane@ietf.org list" References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> In-Reply-To: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------020305090306050402010401" Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:02:53 -0000 This is a multi-part message in MIME format. --------------020305090306050402010401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, Oops - our side-meetings conflict. Sorry about that. Not sure if we can at this point. S. On 11/04/2013 07:08 PM, Paul Hoffman wrote: > Hi again. I have put in a room request for lunch on Thursday; I'll > let the list know when I get it. If you're at the Vancouver IETF > meeting and want to talk about DANE, hold the date. We'll meet at > 11:45 in order to give people time to run out and get some food and > bring it to the room; no food or beverage will be provided. > > --Paul Hoffman _______________________________________________ dane > mailing list dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > --------------020305090306050402010401 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" X-Mozilla-Keys: Return-Path: X-Original-To: stephen.farrell@cs.tcd.ie Delivered-To: stephen.farrell@cs.tcd.ie Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 749F3BEB5 for ; Mon, 4 Nov 2013 21:42:00 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 uLyB27y5gwvT for ; Mon, 4 Nov 2013 21:41:59 +0000 (GMT) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C7D5DBE9C for ; Mon, 4 Nov 2013 21:41:58 +0000 (GMT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F9321E81C4; Mon, 4 Nov 2013 13:41:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1383601316; bh=nE3P5E4Ia7BZ1tMwSqhSwpELmiba+ehKAt5YQxWgmrI=; h=Message-ID:Date:From:MIME-Version:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=WWUujul6S17QgQgk4FfXUVYplNrugJIdD7G5JsgZfefxRUIobmIYHcGd7s5p1Lnlh h9r3G1PR4Jc9TxWuFSh2CE/vYJBoU+ysiu6JZT047zvm/gw1FrGSGa4HzxUYXWxL1m lyQUJ3x/fs3tgDZOoMtuRzHK7wN2jKhCv42kXhHE= X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E177521E81C1 for ; Mon, 4 Nov 2013 13:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYYPwAmLbrmu for ; Mon, 4 Nov 2013 13:41:43 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9CB21E81B4 for ; Mon, 4 Nov 2013 13:41:33 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id p9so3815980lbv.0 for ; Mon, 04 Nov 2013 13:41:32 -0800 (PST) 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:content-type:content-transfer-encoding; bh=tlkotds8DUcV+VkKMmZUHGK0PprX9ebX8zXxl+mCAow=; b=UX2FKr+mbJjkbEpYpvebHERe1QjJoKvOYLtTZG2bnKj2jaG93ymamVp4twfqOWWKy1 PsoerHh82/oZYTo9reIxx+Gp8mRAE7NaXoOXcw93Dogp1cl1UQflrqxrqFg9xpBiIFow ggXbIz+j8o7hYkXJ4eJulhicG01DWHlhRwhJfKs9LgbEA1ouIkr1+IXw0Fy3k+B4jWcY qFoe02EJh+xFHUJxFqTG0hy6bkHhqErydUhFAEaxhAHcoOLEyuaz0ikJrbzxYH7MH8kc 4WUQR1SGN9gzPFOPzTnuu+ifekLRgy55idM0idbU7HUGt/Dp2OJ5YI0/hth2FBn6Q660 2axQ== X-Gm-Message-State: ALoCoQlhEmHZI+mJD4Gf8vCGhgJlnfVTvmRljyRhrIamU3Il/OLAEDwr13vyi9dMwMffgjJzOQaP X-Received: by 10.152.22.198 with SMTP id g6mr13290812laf.5.1383601292759; Mon, 04 Nov 2013 13:41:32 -0800 (PST) Received: from [31.133.152.76] (dhcp-984c.meeting.ietf.org. [31.133.152.76]) by mx.google.com with ESMTPSA id go4sm1005679lbc.3.2013.11.04.13.41.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 13:41:31 -0800 (PST) Message-ID: <52781478.6010205@mnt.se> Date: Mon, 04 Nov 2013 22:41:12 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "perpass@ietf.org" X-Enigmail-Version: 1.6 Subject: [perpass] informal meeting on open-hardware crypto X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: perpass-bounces@ietf.org Errors-To: perpass-bounces@ietf.org Folks, Recent revelations have called into question the integrity of some of the implementations of basic cryptographic functions and devices used to secure communications on the Internet. There are questions about some algorithms but more particularly about implementations of algorithms in software and hardware. The Internet community can and must deal with these implementation issues. A few individuals and organizations are therefore embarking on an effort to investigate and promote the development of an open-source hardware cryptographic engine that meets the needs of high assurance Internet infrastructure that use cryptography. Such an engine must also be of general use to the broad Internet community, covering the cryptographic needs for applications such as secure email, web, DNS, PKIs, etc. We are therefore hosting an informal discussion focusing on gathering use-cases for such an engine/module. Time: Thursday Lunch (11:30) Place: Plaza B Randy Bush Stephen Farrell Leif Johansson Lucy Lynch Linus Nordberg _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass --------------020305090306050402010401-- From smccammon@amsl.com Mon Nov 4 13:46:53 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C34B21E81BB for ; Mon, 4 Nov 2013 13:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MR1C3Wp7g4ET for ; Mon, 4 Nov 2013 13:46:52 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:126c::1:15]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2DC21E81CD for ; Mon, 4 Nov 2013 13:46:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c9a.amsl.com (Postfix) with ESMTP id 07FD6A7273 for ; Mon, 4 Nov 2013 13:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c9a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3d8xkAgLvXDb for ; Mon, 4 Nov 2013 13:44:17 -0800 (PST) Received: from dhcp-ac21.meeting.ietf.org (dhcp-ac21.meeting.ietf.org [31.133.172.33]) by c9a.amsl.com (Postfix) with ESMTPSA id ACB30A6211 for ; Mon, 4 Nov 2013 13:44:17 -0800 (PST) From: Stephanie McCammon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Nov 2013 13:46:42 -0800 Message-Id: To: dane@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Mailman-Approved-At: Mon, 04 Nov 2013 14:11:50 -0800 Subject: [dane] DANE Meeting Room for Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:46:53 -0000 Hello everyone! The DANE informal lunch meeting will take place in the Cypress room on = the 34th floor, Thursday, November 7th from 1130 - 1300. Please let me = know if you need anything else! Sincerely, Stephanie McCammon IETF Project Manager 48377 Fremont Blvd, Ste. 117 Fremont, CA 94538 T: +1.510.492.4081 F: +1.510.492.4001 Association Management Solutions (AMS) Forum Management, Meeting, and Event Planning www.amsl.com From dan-ietf@danyork.org Mon Nov 4 14:15:05 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9577811E8200 for ; Mon, 4 Nov 2013 14:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99lH3jFBQq6t for ; Mon, 4 Nov 2013 14:15:00 -0800 (PST) Received: from mail-vb0-f42.google.com (mail-vb0-f42.google.com [209.85.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4571E21E8256 for ; Mon, 4 Nov 2013 14:14:14 -0800 (PST) Received: by mail-vb0-f42.google.com with SMTP id p14so1877461vbm.1 for ; Mon, 04 Nov 2013 14:14:13 -0800 (PST) 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=9j09y6frSPDVWBYtKP9T/Yyl8CTPO4l+WkzVgCu9JPI=; b=dkegb+AbSPlC18Naz3i6IqiCSgYujgT7Ujs7mjPKT+fQHERCS8qTeCSTkvoKAfL1aR M4MahtmisAMeiBRdjg4zMI2D3Kpf7v9znHCAsAguFQHvXLUs7m8g0U70EqQxGG29tqNT P+eySQFbtfBy0tsE9r6VFtTkhWZwy3iprw9qm+XdhCeyx/1clfMm50Or7no164j12cfL Ywx3JEjDgG2YLTCZp3xDQ+VR1UTvcCJDqis5QEYu41NqVaCzaxPXzvsXjDOyKxm9/VLn dqZDh4p7wezAktHCSb/pM6x+Y01Fwnvrqghl4BoggSdOwrR2HAWKrzN6Fk+YV0NvAKBB t87A== X-Gm-Message-State: ALoCoQmt48p5y87P6MXZEjbpMJ51P6KXvnXTFktMjvGWUc28bCOFZnNC7SpgNpUdETK9LaSQwOnx MIME-Version: 1.0 X-Received: by 10.221.54.129 with SMTP id vu1mr5109847vcb.20.1383603253517; Mon, 04 Nov 2013 14:14:13 -0800 (PST) Received: by 10.58.67.135 with HTTP; Mon, 4 Nov 2013 14:14:13 -0800 (PST) X-Originating-IP: [31.133.161.88] In-Reply-To: <90B09F3E-2D11-4127-A5BB-9D243AB31097@kumari.net> References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <90B09F3E-2D11-4127-A5BB-9D243AB31097@kumari.net> Date: Mon, 4 Nov 2013 14:14:13 -0800 Message-ID: From: Dan York To: Warren Kumari Content-Type: multipart/alternative; boundary=001a113387426fbdaf04ea613c03 Cc: Paul Hoffman , "dane@ietf.org list" Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:15:05 -0000 --001a113387426fbdaf04ea613c03 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 4, 2013 at 12:08 PM, Warren Kumari wrote: > > On Nov 4, 2013, at 11:08 AM, Paul Hoffman wrote: > > > Hi again. I have put in a room request for lunch on Thursday; I'll let > the list know when I get it. If you're at the Vancouver IETF meeting and > want to talk about DANE, hold the date. We'll meet at 11:45 in order to > give people time to run out and get some food and bring it to the room; no > food or beverage will be provided. > > Thank you. Will be there. Yes, thanks for organizing, Paul. I will plan to be there, too. Dan -- -- Dan York, dan-ietf@danyork.org http://danyork.me http://twitter.com/danyork --001a113387426fbdaf04ea613c03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 4, 2013 at 12:08 PM= , Warren Kumari <warren@kumari.net> wrote:

On Nov 4, 2013, at 11:08 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> Hi again. I have put in a room request for lun= ch on Thursday; I'll let the list know when I get it. If you're at = the Vancouver IETF meeting and want to talk about DANE, hold the date. We&#= 39;ll meet at 11:45 in order to give people time to run out and get some fo= od and bring it to the room; no food or beverage will be provided.

Thank you. Will be there.

Yes, = thanks for organizing, Paul. =A0I will plan to be there, too.

Dan
=A0
--
--001a113387426fbdaf04ea613c03-- From ondrej.sury@nic.cz Mon Nov 4 14:27:56 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250E221E8206 for ; Mon, 4 Nov 2013 14:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.303 X-Spam-Level: X-Spam-Status: No, score=-0.303 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR+Wo5QEtlX1 for ; Mon, 4 Nov 2013 14:27:55 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A32C921E817D for ; Mon, 4 Nov 2013 14:27:51 -0800 (PST) Received: from [192.168.100.101] (unknown [64.114.24.114]) by mail.nic.cz (Postfix) with ESMTPSA id 8359913F853; Mon, 4 Nov 2013 23:27:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383604070; bh=5UrA4Rh0n1XKyEIL9lP+8ksfcN8A2Ns6l+BWC5PFWIk=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=vJRge074a/xfnp5OPqcg2OJAlTXSSRVnFL3IN9D96c1eU113TLPdtCOR892y+A7bF I3n0VyUux85q98JBpAr3zKH1bLdbKoM9QOubitrmA0nB7Q+AIgcJ7VoZbMV9EzGZYb JvkddQYLIBbpNv5DLJXBQWFtTLJ9pynb4Vc/rw/Y= References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <90B09F3E-2D11-4127-A5BB-9D243AB31097@kumari.net> Mime-Version: 1.0 (1.0) In-Reply-To: <90B09F3E-2D11-4127-A5BB-9D243AB31097@kumari.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B511) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Date: Mon, 4 Nov 2013 14:27:47 -0800 To: Warren Kumari X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: Paul Hoffman , "dane@ietf.org list" Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:27:56 -0000 +1 -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, CZE mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- > On 4. 11. 2013, at 12:08, Warren Kumari wrote: >=20 >=20 >> On Nov 4, 2013, at 11:08 AM, Paul Hoffman wrote: >>=20 >> Hi again. I have put in a room request for lunch on Thursday; I'll let th= e list know when I get it. If you're at the Vancouver IETF meeting and want t= o talk about DANE, hold the date. We'll meet at 11:45 in order to give peopl= e time to run out and get some food and bring it to the room; no food or bev= erage will be provided. >=20 > Thank you. Will be there. >=20 > W >=20 >>=20 >> --Paul Hoffman >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 > -- > "Real children don't go hoppity-skip unless they are on drugs." >=20 > -- Susan, the ultimate sensible governess (Terry Pratchett, Hogfather) >=20 >=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From dev+ietf@seantek.com Mon Nov 4 14:30:48 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7544621E8173 for ; Mon, 4 Nov 2013 14:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKa4AQ0pQpdJ for ; Mon, 4 Nov 2013 14:30:43 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 8D72321E80E1 for ; Mon, 4 Nov 2013 14:30:36 -0800 (PST) Received: from dhcp-a65b.meeting.ietf.org (unknown [31.133.166.91]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6950F509B6 for ; Mon, 4 Nov 2013 17:30:34 -0500 (EST) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_C6211D79-1E77-4AE3-A503-55F289501C81"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Mon, 4 Nov 2013 14:30:26 -0800 References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <52781983.4000609@cs.tcd.ie> To: "dane@ietf.org list" In-Reply-To: <52781983.4000609@cs.tcd.ie> X-Mailer: Apple Mail (2.1510) Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:30:48 -0000 --Apple-Mail=_C6211D79-1E77-4AE3-A503-55F289501C81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Is there any way the DANE meeting can happen on Wednesday or Friday at = lunch? -Sean On Nov 4, 2013, at 2:02 PM, Stephen Farrell = wrote: >=20 > Hi all, >=20 > Oops - our side-meetings conflict. Sorry about that. > Not sure if we can at this point. >=20 > S. >=20 > On 11/04/2013 07:08 PM, Paul Hoffman wrote: >> Hi again. I have put in a room request for lunch on Thursday; I'll >> let the list know when I get it. If you're at the Vancouver IETF >> meeting and want to talk about DANE, hold the date. We'll meet at >> 11:45 in order to give people time to run out and get some food and >> bring it to the room; no food or beverage will be provided. >>=20 >> --Paul Hoffman _______________________________________________ dane >> mailing list dane@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/dane >>=20 >>=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --Apple-Mail=_C6211D79-1E77-4AE3-A503-55F289501C81 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO2TCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwn VmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49c NfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWON GoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAU iYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1Ud DwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhXVW0z f0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm 0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8 mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKd RU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ 1eBDQEIwvuql55TSsP7zdfl/bucwggUpMIIEEaADAgECAhBnqxWWtMRiPAtoE+jFTARpMA0GCSqG SIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMTEyOTAw MDAwMFoXDTEzMTEyOTIzNTk1OVowJTEjMCEGCSqGSIb3DQEJARYUZGV2K2lldGZAc2VhbnRlay5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPifbSoA7NS0LWg3PnOBOfLQlEETWY lmzNXazoS6tqEo++S7sT662cuFxo1qEBavahmB4Ir26ESqKNoLiotkeca3/6WduxC2OYwmtwULOE NmMM4l1jOa5LZxS9mpjtjDMIbqNJ+ziDA2H7b0xLp9pjq5ydxud872sEHTG7kYh0jcHOw81icAI2 UFhTvDhfgYDT8zA0Bps2EODFTZPDV+XnDVW37rFFNcGTpX3cvJVk33AEg6mvYy6GgIksdmsuKu/+ ZtATlqjimQktH+zJiFLUqjgxKImZHe6Ao+TESjoNmS4mt9yTfqEua0yjfK7OLuGReYPM8qR0uU2P 5d6TUZa3AgMBAAGjggHkMIIB4DAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNV HQ4EFgQUGmbl3vLw8FPo2qchVt80ryFuk8YwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAw IAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNV HSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21v ZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01P RE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8 MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0BAQUF AAOCAQEABjcZ+BfSkuzPqoQ44bX3USBhdIKkpbvTBIWBJ77sB6dlPzx3+bzDRi184VUPv73h01Qs Ocfg/qwPvSF1rLv+R7i5h+BRHHKB6Yo3bopXdPvAHDxZtlJOZgmmHNKipQrkhKxA3Atop/jJOakB 70hHUCNlc/egBm+xG+lkO2JpQtD4d8VPKksOyesDuxO2hW2Ksl0iYYFMexW1n4YRCWG64nobVwif M3EhvGCct2fikUXzYU/rRKxnFpbZVGoMrsJsclfgtQf6gnqSn2rEXkj9EgCFEd3eUx5earq9k9uc xQ2EnJQLpNtiKl7XX5UMU8aIdkT/7LpExK5Gd6knMTg8sDGCA6swggOnAgEBMIGoMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBnqxWWtMRiPAtoE+jFTARpMAkGBSsOAwIaBQCg ggHXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTEwNDIyMzAz M1owIwYJKoZIhvcNAQkEMRYEFFjoBcNesRZlNIvPRzBOSyD8oDGUMIG5BgkrBgEEAYI3EAQxgasw gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEGerFZa0xGI8C2gT6MVMBGkw gbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhBnqxWWtMRiPAtoE+jFTARpMA0GCSqGSIb3DQEBAQUABIIBAJJ/CUvHnGqcCIH4kOT+IetGDIc1 +hbeY4TiIDWEfgCYBX7fGBRxQiuOnuLJ8IvE65j7T72SOStLXiPAenCrmXt0d7wb3Ac2DeoeDdi5 rC5s8B2aj0f8lh70g/3oAB2uLUTc0jw/ZrkhHu26gH/okz7gmuhiLXkvihw67y0Jn1VKflj7MctK QR1hJwJVlw4syKjFMq0G4MthQ03jQ5PMrxO9+esUm0GCZ5C4NMF3zLwAbDSisoNbwICnGwrkEY2x +63eLnWR2fZryTHWV7U1OK2ZKt6dC1Lk9XixbGC/7ZAq6KDtd16DDUqLju0R4KOjG6nh0QfjCk+c DCEMGwHUs9YAAAAAAAA= --Apple-Mail=_C6211D79-1E77-4AE3-A503-55F289501C81-- From viktor1dane@dukhovni.org Mon Nov 4 14:32:34 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3703711E8185 for ; Mon, 4 Nov 2013 14:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnkUlfF0b197 for ; Mon, 4 Nov 2013 14:32:28 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEA111E81ED for ; Mon, 4 Nov 2013 14:32:26 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 751462AB125; Mon, 4 Nov 2013 22:32:19 +0000 (UTC) Date: Mon, 4 Nov 2013 22:32:19 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131104223219.GP2976@mournblade.imrryr.org> References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] Digest algorithm agility (possible discussion topic for: Informal lunch meeting in Vancouver on Thursday) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:32:34 -0000 On Mon, Nov 04, 2013 at 11:08:46AM -0800, Paul Hoffman wrote: > If you're at the Vancouver IETF meeting and want to talk about > DANE, hold the date. Though I am not attending the Vancouver IETF meeting, I am interested in feedback on the below DANE-related issue: - Suppose some day we discover that SHA256 is flawed and is subject to effective second-preimage attacks. - Suppose that hypothetically SHA512 remains secure. - How would clients and servers gracefully cut-over to only use SHA512 and avoid SHA256? My proposal is as follows: When a TLSA RRset contains multiple RRs of the form: _._tcp.server.example.com. IN TLSA with the same values of "U" and "S" but different values of the matching type, a client MAY ignore a "weaker" matching type (deprecated digest algorithm) when a "stronger" matching type for the same usage and selector is present. Which matching types are considered "weaker" is generally at the client's discretion. Rationale: Avoid algorithm switch flag days. Once a widely used digest algorithm is deemed no longer robust, servers continue to include it in their TLSA records along with stronger digests. Correctly configured clients use only the stronger digests and are not exposed to the flaws of weaker algorithms. Eventually, (once few clients remain that don't support strong digests) servers stop including weak digests in their TLSA RRsets. Consequences: - TLSA records that specify multiple certificates or public keys for a single (U,S) combination (e.g. multiple trust anchors, or multiple EE certificates during key roll-over) MUST use the same set of matching types for all of them! Otherwise, clients may fail to support one of the desired certificates, when they choose to support only the RRs with the strongest matching type. - Changes in the mixture of matching types (digest algorithms) used in a given TLSA RRset should be made when the set of keys is stable. In other words, do either key rotation or change of digest algorithms, but not both at the same time. (Recall, that with key rotation, one must publish TLSA RRs for new keys before they are deployed in the field, as clients may for a short time see only the old RRs due to DNS caching). Alternative: - Clients always accept all supported digests, without pruning for the strongest. - But then there is no good way to obsolete an algorithm, a server publishing a "weaker" digest exposes all clients risk. A server publishing only the strongest digests risks not interoperating with many clients (flag day). - To avoid flag days, we need multiple strong *mandatory* to implement digest algorithms, and rely on them not all failing at the same time. - At this time RFC 6698 only mandates SHA256, so we don't have digest algorithm agility. -- Viktor. From wjhns1@hardakers.net Tue Nov 5 13:22:01 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671DF21E8094 for ; Tue, 5 Nov 2013 13:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.169 X-Spam-Level: X-Spam-Status: No, score=-3.169 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ww+T1vsIYNet for ; Tue, 5 Nov 2013 13:21:50 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 17CA311E8156 for ; Tue, 5 Nov 2013 13:21:50 -0800 (PST) Received: from localhost (unknown [IPv6:2001:67c:370:136:b52e:7b12:da40:9c66]) by mail.hardakers.net (Postfix) with ESMTPSA id E66952C361; Tue, 5 Nov 2013 13:21:48 -0800 (PST) From: Wes Hardaker To: Paul Hoffman References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> Date: Tue, 05 Nov 2013 13:21:46 -0800 In-Reply-To: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> (Paul Hoffman's message of "Mon, 4 Nov 2013 11:08:46 -0800") Message-ID: <0lk3gm8ryt.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "dane@ietf.org list" Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 21:22:01 -0000 Paul Hoffman writes: > Hi again. I have put in a room request for lunch on Thursday; I'll let > the list know when I get it. If you're at the Vancouver IETF meeting > and want to talk about DANE, hold the date. We'll meet at 11:45 in > order to give people time to run out and get some food and bring it to > the room; no food or beverage will be provided. I'll definitely be there, and thank you for putting it together Paul. Viktor and I have a few things to bring up and was disappointed that there was no DANE meeting this time, especially in light of the Wednesday discussions and how much DANE has been talked about in light of the perforce work. If possible, there is one particular topic I'd like to take some time for on Thursday if you're carving off blocks (15 minutes or so). -- Wes Hardaker Parsons From paul.hoffman@vpnc.org Tue Nov 5 14:21:05 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4429C11E8103 for ; Tue, 5 Nov 2013 14:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YS7TCLGqcgQh for ; Tue, 5 Nov 2013 14:21:04 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A41DF11E80E3 for ; Tue, 5 Nov 2013 14:21:04 -0800 (PST) Received: from dhcp-b88d.meeting.ietf.org (dhcp-b88d.meeting.ietf.org [31.133.184.141]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rA5ML2ZY097635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 5 Nov 2013 15:21:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Paul Hoffman In-Reply-To: <0lk3gm8ryt.fsf@wjh.hardakers.net> Date: Tue, 5 Nov 2013 14:21:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7A8915B0-5CE9-4A20-A35A-DECE61D4F516@vpnc.org> References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <0lk3gm8ryt.fsf@wjh.hardakers.net> To: "dane@ietf.org list" X-Mailer: Apple Mail (2.1816) Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:21:05 -0000 Just to be clear, there is no agenda: note the first word in the subject = line. This is a good place to talk, clear up misconceptions, and maybe foment = new work. --Paul Hoffman= From viktor1dane@dukhovni.org Tue Nov 5 16:19:01 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E1721E80CD for ; Tue, 5 Nov 2013 16:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQmU6Wr-jvED for ; Tue, 5 Nov 2013 16:18:54 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id B93C311E8169 for ; Tue, 5 Nov 2013 16:18:54 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9D6F12AB128; Wed, 6 Nov 2013 00:18:49 +0000 (UTC) Date: Wed, 6 Nov 2013 00:18:49 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131106001849.GV2976@mournblade.imrryr.org> References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <0lk3gm8ryt.fsf@wjh.hardakers.net> <7A8915B0-5CE9-4A20-A35A-DECE61D4F516@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7A8915B0-5CE9-4A20-A35A-DECE61D4F516@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:19:01 -0000 On Tue, Nov 05, 2013 at 02:21:00PM -0800, Paul Hoffman wrote: > Just to be clear, there is no agenda: note the first word in the subject line. > > This is a good place to talk, clear up misconceptions, and maybe foment new work. Noted. If Thursday lunch is not a good opportunity to provide feedback on the digest algorithm agility question, I am of course more than happy to receive feedback via this list that is not based on intruding on a pleasant lunch. :-) -- Viktor. From viktor1dane@dukhovni.org Tue Nov 5 16:27:43 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA74A11E8163 for ; Tue, 5 Nov 2013 16:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THk2TqfHB48c for ; Tue, 5 Nov 2013 16:27:38 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id B1B7621F9D28 for ; Tue, 5 Nov 2013 16:27:38 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5D88E2AB128; Wed, 6 Nov 2013 00:27:38 +0000 (UTC) Date: Wed, 6 Nov 2013 00:27:38 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131106002737.GW2976@mournblade.imrryr.org> References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <5277FB66.406@stpeter.im> <5278019B.8040601@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5278019B.8040601@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:27:43 -0000 On Mon, Nov 04, 2013 at 12:20:43PM -0800, Peter Saint-Andre wrote: > In particular, I'm interested in moving the dane-srv document forward. > If Tony doesn't have the cycles, I'd volunteer to help (because Matt > and I need it to finish draft-ietf-xmpp-dna). It seems most likely that Tony does not. In which case, I'd like to ask you to read the closely related new (Hardaker/Dukhovni) SMTP draft, and, if you're willing, to negotiate some Skype or Google Hangout time to discuss how much of that is generally applicable (not just to SMTP) to protocols that use SRV or similar (e.g. MX) indirection. Drop Wes and me an off-list email when you're ready to move forward. -- Viktor. From stpeter@stpeter.im Tue Nov 5 16:38:25 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F0121E80BA for ; Tue, 5 Nov 2013 16:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZjHeGQjETOx for ; Tue, 5 Nov 2013 16:38:19 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 018D921F9F86 for ; Tue, 5 Nov 2013 16:38:19 -0800 (PST) Received: from sjc-vpn3-1085.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5459E4032B; Tue, 5 Nov 2013 17:38:18 -0700 (MST) Message-ID: <52798F79.5090804@stpeter.im> Date: Tue, 05 Nov 2013 16:38:17 -0800 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: dane@ietf.org References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <5277FB66.406@stpeter.im> <5278019B.8040601@stpeter.im> <20131106002737.GW2976@mournblade.imrryr.org> In-Reply-To: <20131106002737.GW2976@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:38:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/5/13 4:27 PM, Viktor Dukhovni wrote: > On Mon, Nov 04, 2013 at 12:20:43PM -0800, Peter Saint-Andre wrote: > >> In particular, I'm interested in moving the dane-srv document >> forward. If Tony doesn't have the cycles, I'd volunteer to help >> (because Matt and I need it to finish draft-ietf-xmpp-dna). > > It seems most likely that Tony does not. In which case, I'd like > to ask you to read the closely related new (Hardaker/Dukhovni) > SMTP draft, Just to be sure, that is draft-ietf-dane-smtp-with-dane, right? Thanks for your work on this topic. > and, if you're willing, to negotiate some Skype or Google Hangout > time to discuss how much of that is generally applicable (not just > to SMTP) to protocols that use SRV or similar (e.g. MX) > indirection. Yes, I will investigate that. As far as I know, the main technologies under consideration here are SMTP/IMAP/POP and XMPP (which uses SRV). Do we know of others we need to consider? > Drop Wes and me an off-list email when you're ready to move > forward. I can finish re-reading your spec tonight or tomorrow morning and we can chat this week (or at least I can chat with Wes, because I know I've seen him in the hallways in Vancouver). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSeY95AAoJEOoGpJErxa2pSesP/jWUtwVKHqzkgV/OyZbRRinh YUoxq3KZiI3FYq3TfJUmZp3zPJ15ATTZd5hASaytyJNTXiryEfr7Y/PgD3G8U1ah 1HRi5NEgZ/7i49bmIIw4UptbnfssSRFKe6QnjQEOnzv29oH/HI1guwb6pI2CxV0A qsGza8q/T3+/dS0m6X2+QKTy1Y/+ZHY5qj4vh+eZgTv9tYubIR7EuN2p/PtlEjp1 0puxCX6JZrsUu98CnxpLzwjRaSaaaXYF4OjS1ypsafAwJv6GcVl3NCOV5PDcP+/L bBu3uIlkMsgZytdBB+IFYYZGna7DH4lsb3yVL4j7BmT7pVY1f8imh73AWVeelusw zZ97/GZFqmnKMuDGZmJCzzwjDTESMu+TLvc+9Njb1wwayKJ4tHQMwwobL+sTgfdS KCdFuCK2sjvvdvMtdMWmtLq6hxRwEwieS29Ow46UCT8b7FZHtbBi5s6KWMn5GLjr 5O1uyv7wMpQzgRf//lPt2K47twYgyAb3QX1+B6SSD3LBUBi/ny8tT0B6QOJjWcTz H97W64VuxxtWa4wMhHXhU5JBlrc1KCHo5fxipA/0BliJzxwU5TtZY9LyEjQYvuni IuAqoF5gOOwfoe5r7NMWGli3lmCGob4K+FE9Z2zyx7BU6QZtUOgyxbPeGC17TJlj tj4Nr9e1ZagXVUMczfIN =U4vV -----END PGP SIGNATURE----- From wjhns1@hardakers.net Tue Nov 5 16:59:17 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F43D11E81C3 for ; Tue, 5 Nov 2013 16:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XesoC7RNw-cX for ; Tue, 5 Nov 2013 16:59:17 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD38311E8199 for ; Tue, 5 Nov 2013 16:59:16 -0800 (PST) Received: from localhost (dhcp-a727.meeting.ietf.org [31.133.167.39]) by mail.hardakers.net (Postfix) with ESMTPSA id D4FC12DE5D; Tue, 5 Nov 2013 16:59:12 -0800 (PST) From: Wes Hardaker To: Viktor Dukhovni References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <0lk3gm8ryt.fsf@wjh.hardakers.net> <7A8915B0-5CE9-4A20-A35A-DECE61D4F516@vpnc.org> <20131106001849.GV2976@mournblade.imrryr.org> Date: Tue, 05 Nov 2013 16:58:54 -0800 In-Reply-To: <20131106001849.GV2976@mournblade.imrryr.org> (Viktor Dukhovni's message of "Wed, 6 Nov 2013 00:18:49 +0000") Message-ID: <0lbo1y73ch.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dane@ietf.org Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:59:17 -0000 Viktor Dukhovni writes: > Noted. If Thursday lunch is not a good opportunity to provide > feedback on the digest algorithm agility question, I am of course > more than happy to receive feedback via this list that is not based > on intruding on a pleasant lunch. :-) That wasn't even what I was going to bring up :-) (but the list is the right place to discuss *any* final solution, obviously) -- Wes Hardaker Parsons From paul@cypherpunks.ca Tue Nov 5 17:01:57 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B8A21F9CA0 for ; Tue, 5 Nov 2013 17:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66BVbc7ozMXY for ; Tue, 5 Nov 2013 17:01:52 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7B121F9CBF for ; Tue, 5 Nov 2013 17:01:52 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3dDqFn1bv0z7q; Tue, 5 Nov 2013 20:01:49 -0500 (EST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ihkD_iB1FJ2Z; Tue, 5 Nov 2013 20:01:46 -0500 (EST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 5 Nov 2013 20:01:45 -0500 (EST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 0D436807CA; Tue, 5 Nov 2013 20:01:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EBF6E800A9; Tue, 5 Nov 2013 20:01:45 -0500 (EST) Date: Tue, 5 Nov 2013 20:01:45 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Paul Hoffman In-Reply-To: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> Message-ID: References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "dane@ietf.org list" Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:01:57 -0000 On Mon, 4 Nov 2013, Paul Hoffman wrote: > Hi again. I have put in a room request for lunch on Thursday; I'll let the list know when I get it. If you're at the Vancouver IETF meeting and want to talk about DANE, hold the date. We'll meet at 11:45 in order to give people time to run out and get some food and bring it to the room; no food or beverage will be provided. Will be there. Very happy to explain, comment, take questions on: http://tools.ietf.org/html/draft-wouters-dane-otrfp-01 http://tools.ietf.org/html/draft-wouters-dane-openpgp-01 Paul From ogud@ogud.com Tue Nov 5 17:08:30 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9535E11E818C for ; Tue, 5 Nov 2013 17:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cWd7B7F2JIE for ; Tue, 5 Nov 2013 17:08:26 -0800 (PST) Received: from smtp156.ord.emailsrvr.com (smtp156.ord.emailsrvr.com [173.203.6.156]) by ietfa.amsl.com (Postfix) with ESMTP id 7851711E8163 for ; Tue, 5 Nov 2013 17:08:26 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 1665D198615 for ; Tue, 5 Nov 2013 20:08:26 -0500 (EST) X-Virus-Scanned: OK Received: by smtp24.relay.ord1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id D7755198258 for ; Tue, 5 Nov 2013 20:08:25 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: Date: Tue, 5 Nov 2013 17:08:24 -0800 Cc: "dane@ietf.org list" Content-Transfer-Encoding: quoted-printable Message-Id: References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> X-Mailer: Apple Mail (2.1510) Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:08:30 -0000 I will be there,=20 Olafur On Nov 5, 2013, at 5:01 PM, Paul Wouters wrote: > On Mon, 4 Nov 2013, Paul Hoffman wrote: >=20 >> Hi again. I have put in a room request for lunch on Thursday; I'll = let the list know when I get it. If you're at the Vancouver IETF meeting = and want to talk about DANE, hold the date. We'll meet at 11:45 in order = to give people time to run out and get some food and bring it to the = room; no food or beverage will be provided. >=20 > Will be there. Very happy to explain, comment, take questions on: >=20 > http://tools.ietf.org/html/draft-wouters-dane-otrfp-01 >=20 > http://tools.ietf.org/html/draft-wouters-dane-openpgp-01 >=20 > Paul > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From chris.newman@oracle.com Tue Nov 5 17:12:51 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C22721E80E2 for ; Tue, 5 Nov 2013 17:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSNo9o723gNF for ; Tue, 5 Nov 2013 17:12:45 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2E021E80CA for ; Tue, 5 Nov 2013 17:12:43 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA61CgfS006620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 6 Nov 2013 01:12:42 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA61Cfcg011651 for ; Wed, 6 Nov 2013 01:12:41 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.121.65] (dhcp-amer-vpn-rmdc-anyconnect-10-159-121-65.vpn.oracle.com [10.159.121.65]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPA id <0MVT00L8HI10MZ00@gotmail.us.oracle.com> for dane@ietf.org; Tue, 05 Nov 2013 17:12:40 -0800 (PST) Date: Tue, 05 Nov 2013 17:01:54 -0800 From: Chris Newman To: dane@ietf.org Message-id: <789202E67F7415FC98D8FECF@96B2F16665FF96BAE59E9B90> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [dane] review of draft-ietf-dane-smtp-with-dane-02.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:12:51 -0000 I have read draft-ietf-dane-smtp-with-dane-02.txt and support advancing it on standards track if three changes* are made to the document as mentioned in my comments below. I believe this is a plausible strategy to improve security/privacy for SMTP relay and is close to ready for publication. Page 6: > or all destinations, in which case mail delivery will be deferred > when "secure" TLSA records are absent. *1* This should state whether the error is permanent or temporary (deferred implies a temporary error but it'd be nice to make it explicit). An SMTP enhanced status code should be defined and registered for this error condition. The registry was introduced by RFC 5248. Here's the IANA link: http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml#smtp-enhanced-status-codes-3 I suggest a new X.7.X code would be appropriate for this case. A few lines of text describing the meaning of the code in an IANA Considerations section is all that's needed. Page 9: > Note: CNAMEs are not legal in the exchange field of MX records, thus > MTAs are not obligated to perform MX exchange CNAME expansion. If an > MTA does not perform CNAME expansion, there is potential risk, that > the MTA may fail to notice that it is one of the MX hosts for the > destination and that it must skip MX records with equal or worse > (numerically higher precedence). If an MTA does allow CNAMEs to be > used in MX records, it SHOULD process them recursively as described > above to determine the most appropriate TLSA RRset base domain. This document is a bit long. I suggest dropping all text after the first sentence in this paragraph. I don't think it's worth the words to describe how to accommodate misconfigured deployments. > with custom routes specified by the MTA administrator or when an MUA > connects to a submission server on port 587. The SMTP client MUST *2* I believe it's undesirable to attempt to deploy DANE TLSA for submission services (port 587 or de-facto port 465) as it may cause confusion and possibly harm to the MUA infrastructure more than it causes benefit. I'd prefer for submission clients to implement the same TLS certificate algorithm for all three of POP, IMAP and Submission. The current algorithm described in RFC 3501 (similar to RFC 6125) is what many implement. A compromise position would be to link the DANE TLSA lookup with an attempted MX lookup. That is, if a submission client looks for MX records with the submission server's name (a practice that is uncommon), then it should also look for DANE TLSA. Otherwise traditional TLS verification should be used by submission clients. The MUA infrastructure is much more fragile than the MTA infrastructure when it comes to security. And it's often subject to the whims and limitations of client-OS-provided SSL libraries; having two different ways to validate certificates at the client side is more likely to break things than to improve them. For MTA relay, the opposite is true both due to the use of MX records and because traditional TLS server authentication is generally not used for relay. Page 12: > anchor certificates in server trust chains. SMTP client > implementations SHOULD support these TLSA RRs, unless, despite the > above warning, a non-trivial fraction of server operators fail to > publish certificate chains that include the required TA > certificate. It sounds like you really want this to deploy (because it simplifies the operator's job) but you're worried it won't due to operator CA management errors. So how about adding a requirement for server implementers so the management error is likely to be noticed by the right people. Something like: "SMTP servers implementing DANE TLSA SHOULD verify that the CA for a server certificate that will be provided by TLS is installed on the server and SHOULD log an error or disable TLS support if the required CA is missing." Speaking with my server implementer hat on, I think I know how to write that code, but I won't be able to justify the time to do so unless it's at least a recommendation in a spec we claim to implement. > or "1". SMTP clients cannot be expected to be configured with a ^ relay >... > public CAs, SMTP clients cannot (without relying on DNSSEC for secure ^ relay I disagree that this statement is true for submission clients. > SMTP client treatment of TLSA RRs with certificate usages "0" or "1" ^ relay > MX: If the TLSA base domain was obtained indirectly via an MX lookup > (it is the name of an MX exchange that may be securely CNAME > expanded), then the initial query name used in the MX lookup > SHOULD be accepted in the peer certificate. The CNAME-expanded > initial query name SHOULD also be accepted if different from the > initial query name. This text makes me quite uncomfortable and I think some discussion is merited. I'm not sure if all TLS stacks support certificate validation against more than one name. And having a single name is a common simplification in higher-level TLS APIs. I'd prefer an algorithm where only one name is valid. Common TLS practice has been that the name that was used prior to any DNS or remote lookup (regardless of record type) is the only valid name. This issue isn't a show stopper issue to me, but it may be a deployment barrier and I want as few of those as possible. Page 14: > The client may even offer to use anonymous TLS ciphersuites and > servers SHOULD support these. No security is gained by sending a *3* This paragraph needs to be removed. Here are my reasons: 1. For clients, using a regular cipher suite means the client has the option of pinning the server certificate and then it can at least record in an audit log if it's talking to the same server as last time (even if it continues sending if the certificate changes). 2. TLS stacks are complex and the more code they contain the more risk there is of a vulnerability. As clients have the option of ignoring server certificate validation (or doing 1), there's no functionality gain by having anonymous cipher suites in the stack. But there is increased security risk by having that code present. Some TLS stacks are removing anonymous cipher suites (or never included them) for this reason. 3. The TLS protocol has interoperability problems if the client hello has too many cipher suites in it. So some TLS stacks are busily discussing which cipher suites to trim out of the default client hello so that they can get a good "moving window" of security technology allowing backwards compatibility and upgrade to strong modern cipher suites. Enabling the anonymous cipher suites would cause the moving window to be smaller and thus deter upgrading to better cipher suites. As for the auditing benefit of anonymous cipher suites, I agree but I believe there's a better way to address that issue that can be handled in the document Keith & I are writing. >3. Opportunistic TLS for Submission *2* For reasons stated above I believe this section should be removed. Page 17: > Opportunistic SMTP TLS depends critically on DNSSEC for downgrade > resistance and secure resolution of the destination name. If DNSSEC > is compromised, it is not possible to fall back on the public CA PKI > to prevent MITM attacks. A successful breach of DNSSEC enables the > attacker to publish TLSA usage 3 certificate associations, and > thereby bypass any security benefit the legitimate domain owner might > hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of > public CA PKI support in existing MTA deployments, deprecating > certificate usages 0 and 1 in this specifications improves > interoperability without degrading security. For SMTP relay, this is not a problem because there is near zero deployment of RFC 6125 certificate verification in that context. However, for SMTP submission, RFC 6125 verification is deployed somewhat and works reasonably well (assuming one doesn't use SRV records or does not mind a one-time MITM risk during account setup). So the introduction of DANE TLSA to SMTP submission adds a this new serious vulnerability that was not previously present. So this is now another reason I oppose recommending DANE TLSA for submission. - Chris From matt@mattmccutchen.net Tue Nov 5 17:42:19 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F47221E818E for ; Tue, 5 Nov 2013 17:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOWkLw8d10Wh for ; Tue, 5 Nov 2013 17:42:14 -0800 (PST) Received: from homiemail-a10.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 061F721E81A9 for ; Tue, 5 Nov 2013 17:40:47 -0800 (PST) Received: from homiemail-a10.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTP id 2E57C28006C for ; Tue, 5 Nov 2013 17:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=bByf3WTfdWyxdNUxQtnyulNOSTA=; b=rfWdtXpQ4H zPFPAyYpfMEZLA/0lZx9ikAojo0kx24Xd1szmh8DD5rYjKrAQxZbpO9AwDc5KuV4 yWKxvJr28eCijrBmujlJo0RolE0Egj4FsFl50YFtMyn6DsnynDoJundRZaH/Utgj hRBhguRbiz4bTanvpx5mPn9T41YU6tiew= Received: from [192.168.58.221] (unknown [216.239.55.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTPSA id 0EB81280063 for ; Tue, 5 Nov 2013 17:40:19 -0800 (PST) Message-ID: <1383702043.26498.20.camel@localhost> From: Matt McCutchen To: dane@ietf.org Date: Tue, 05 Nov 2013 17:40:43 -0800 In-Reply-To: <20131104223219.GP2976@mournblade.imrryr.org> References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <20131104223219.GP2976@mournblade.imrryr.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Digest algorithm agility (possible discussion topic for: Informal lunch meeting in Vancouver on Thursday) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:42:19 -0000 On Mon, 2013-11-04 at 22:32 +0000, Viktor Dukhovni wrote: > Though I am not attending the Vancouver IETF meeting, I am interested > in feedback on the below DANE-related issue: > > - Suppose some day we discover that SHA256 is flawed and is > subject to effective second-preimage attacks. > > - Suppose that hypothetically SHA512 remains secure. > > - How would clients and servers gracefully cut-over to only > use SHA512 and avoid SHA256? > > My proposal is as follows: > > When a TLSA RRset contains multiple RRs of the form: > > _._tcp.server.example.com. IN TLSA > > with the same values of "U" and "S" but different values of the > matching type, a client MAY ignore a "weaker" matching type > (deprecated digest algorithm) when a "stronger" matching type for > the same usage and selector is present. Which matching types are > considered "weaker" is generally at the client's discretion. > - TLSA records that specify multiple certificates or public > keys for a single (U,S) combination (e.g. multiple trust > anchors, or multiple EE certificates during key roll-over) > MUST use the same set of matching types for all of them! > > Otherwise, clients may fail to support one of the desired > certificates, when they choose to support only the RRs with > the strongest matching type. I.e., the same solution that is de facto used by DNSSEC DS records (https://www.ietf.org/mail-archive/web/dnsext/current/msg11008.html). I believe in the need for algorithm agility and proposed three possible solutions including the above during the original design process (https://trac.tools.ietf.org/wg/dane/trac/ticket/22), but got no traction. Matt From mglt.ietf@gmail.com Tue Nov 5 17:52:41 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817B321F9D9C for ; Tue, 5 Nov 2013 17:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.802 X-Spam-Level: X-Spam-Status: No, score=-1.802 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i53YMY-3Cgxj for ; Tue, 5 Nov 2013 17:52:41 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id D42EB21F9D55 for ; Tue, 5 Nov 2013 17:52:35 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hn9so3007289wib.17 for ; Tue, 05 Nov 2013 17:50:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=rvNiIQMa+AfMCQXCSyRQU+U4j1a9+VAvqq+cQYXbSYo=; b=aEWn7AFXGCG0pGBQLz6wx0xqk062ayiCwy34XKPDA2Eepkmz4CUFApq3N3Fhq5r6yt Ykg0WHkTRQ7ojWYaUz1CrVeL2zh2Y8c8yLsCy3wVQZOxB5ko6DI8j9ePe6J5Zn3mu3pG 0UFHqZD+Lx0KHwxge0Tw5K5eVBRP913B1YQiZjJNgc9yD97sKu4GIa7J2EEOeUYgniXu BRepJapqznzR5DOgo9+dBrbnIErisHE1dTbgvXP8ZIifClFrM2gcyWMG+ou11SqeNqvf xfdhBe4cAgRjarf53jAAVv0ooPlP5aBhpgT6nOLCpbFEJEqLRRJp/QV+GMmJkpQNoJRZ qCUw== MIME-Version: 1.0 X-Received: by 10.180.93.137 with SMTP id cu9mr19176556wib.40.1383702652122; Tue, 05 Nov 2013 17:50:52 -0800 (PST) Received: by 10.194.41.138 with HTTP; Tue, 5 Nov 2013 17:50:52 -0800 (PST) In-Reply-To: References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> Date: Wed, 6 Nov 2013 02:50:52 +0100 Message-ID: From: Daniel Migault Cc: "dane@ietf.org list" Content-Type: multipart/alternative; boundary=f46d043c80ae0dfcb604ea78618c Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:52:41 -0000 --f46d043c80ae0dfcb604ea78618c Content-Type: text/plain; charset=ISO-8859-1 I will try to make it. Thanks Paul for organizing it. BR Daniel On Wed, Nov 6, 2013 at 2:08 AM, Olafur Gudmundsson wrote: > I will be there, > > Olafur > > On Nov 5, 2013, at 5:01 PM, Paul Wouters wrote: > > > On Mon, 4 Nov 2013, Paul Hoffman wrote: > > > >> Hi again. I have put in a room request for lunch on Thursday; I'll let > the list know when I get it. If you're at the Vancouver IETF meeting and > want to talk about DANE, hold the date. We'll meet at 11:45 in order to > give people time to run out and get some food and bring it to the room; no > food or beverage will be provided. > > > > Will be there. Very happy to explain, comment, take questions on: > > > > http://tools.ietf.org/html/draft-wouters-dane-otrfp-01 > > > > http://tools.ietf.org/html/draft-wouters-dane-openpgp-01 > > > > Paul > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --f46d043c80ae0dfcb604ea78618c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I will try to make it. Thanks Paul for organizing it.
= BR
Daniel


On Wed, Nov 6, 2013 at 2:08 AM, Olafur Gudmundsson <ogud@ogu= d.com> wrote:
I will be there,

=A0 =A0 =A0 =A0 Olafur

On Nov 5, 2013, at 5:01 PM, Paul Wouters <paul@cypherpunks.ca> wrote:

> On Mon, 4 Nov 2013, Paul Hoffman wrote:
>
>> Hi again. I have put in a room request for lunch on Thursday; I= 9;ll let the list know when I get it. If you're at the Vancouver IETF m= eeting and want to talk about DANE, hold the date. We'll meet at 11:45 = in order to give people time to run out and get some food and bring it to t= he room; no food or beverage will be provided.
>
> Will be there. Very happy to explain, comment, take questions on:
>
> http://tools.ietf.org/html/draft-wouters-dane-otrfp-01 >
> http://tools.ietf.org/html/draft-wouters-dane-openpgp-01
>
> Paul
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane

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



--
= Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
--f46d043c80ae0dfcb604ea78618c-- From bdickson@verisign.com Tue Nov 5 18:11:03 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCA821F9E1D for ; Tue, 5 Nov 2013 18:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU5VHzaoPIJG for ; Tue, 5 Nov 2013 18:10:58 -0800 (PST) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0167221F9DAD for ; Tue, 5 Nov 2013 18:10:11 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUnmlA+3MGkvPrnUx1Pe+IuBGithY9BFQ@postini.com; Tue, 05 Nov 2013 18:10:31 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id rA62AASp018219 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 21:10:10 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 5 Nov 2013 21:10:10 -0500 From: "Dickson, Brian" To: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= Thread-Topic: [dane] Informal lunch meeting in Vancouver on Thursday Thread-Index: AQHO2ZFW/Yy+S0hINU6vunynPJDoc5oV1AiAgAAm04CAAXylUw== Date: Wed, 6 Nov 2013 02:10:09 +0000 Message-ID: References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <90B09F3E-2D11-4127-A5BB-9D243AB31097@kumari.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , "dane@ietf.org list" Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 02:11:03 -0000 +1 Brian Sent from my iPhone > On Nov 4, 2013, at 2:28 PM, "Ond=F8ej Sur=FD" wrote: >=20 > +1 >=20 > -- > Ond=F8ej Sur=FD -- Chief Science Officer > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > Americka 23, 120 00 Praha 2, CZE > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 >=20 >> On 4. 11. 2013, at 12:08, Warren Kumari wrote: >>=20 >>=20 >>> On Nov 4, 2013, at 11:08 AM, Paul Hoffman wrote= : >>>=20 >>> Hi again. I have put in a room request for lunch on Thursday; I'll let = the list know when I get it. If you're at the Vancouver IETF meeting and wa= nt to talk about DANE, hold the date. We'll meet at 11:45 in order to give = people time to run out and get some food and bring it to the room; no food = or beverage will be provided. >>=20 >> Thank you. Will be there. >>=20 >> W >>=20 >>>=20 >>> --Paul Hoffman >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>=20 >> -- >> "Real children don't go hoppity-skip unless they are on drugs." >>=20 >> -- Susan, the ultimate sensible governess (Terry Pratchett, Hogfather) >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From thomasvo@thomasvo.net Tue Nov 5 23:05:48 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E459B21E80C2 for ; Tue, 5 Nov 2013 23:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAPgF60WnWgq for ; Tue, 5 Nov 2013 23:05:44 -0800 (PST) Received: from makalu.thomasvo.net (makalu.thomasvo.net [80.67.176.126]) by ietfa.amsl.com (Postfix) with ESMTP id 9548C21E80B5 for ; Tue, 5 Nov 2013 23:05:44 -0800 (PST) Received: from makalu.thomasvo.net (localhost [127.0.0.1]) by makalu.thomasvo.net (Postfix) with ESMTP id 533EC5F820 for ; Wed, 6 Nov 2013 08:05:34 +0100 (CET) Date: Wed, 6 Nov 2013 08:05:29 +0100 From: Thomas vO To: dane@ietf.org Message-ID: <20131106070528.GA27430@m2687.in.ac-grenoble.fr> References: <20131021221932.32482.68614.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <20131021221932.32482.68614.idtracker@ietfa.amsl.com> User-Agent: Mutt X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-02.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 07:05:49 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, Le lundi 21 oct. 2013 =C3=A0 15:19:32 (-0700), internet-drafts@ietf.org a = =C3=A9crit : > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DNS-based Authentication of Named Entit= ies Working Group of the IETF. >=20 > Title : SMTP security via opportunistic DANE TLS > Author(s) : Viktor Dukhovni > Wes Hardaker > Filename : draft-ietf-dane-smtp-with-dane-02.txt > Pages : 18 > Date : 2013-10-21 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-02 I'm new down here, so I'm not sure it's the right way to do, but I noticed a mistake/typo at beginning of section 1.2: SMTP means "Simple Mail Transfer Protocol", not "Simple Mail Transport Protocol". Regards, --=20 Thomas vO - GPG Key Id: 0x4F2DEA02 --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJSeeo4AAoJEBMUQXVPLeoCvW8QAIdpjPpHW5iygBVA3q24E6QG AT8FJQ4WBTtFzZ4uBh4k7NfvC12GeJDF0zMwrD8MOC1FBVJt5E7xASUykWOUoymP YAEd0P4NI9MoSvlCCkuy0K5eErQieIZyUzVQRH9HwRnRiIojLVYLQbuy+oXahMpM VS028Zl5OyGjKJheig/ZhMOfqrU1uAIVmyk9oS17fSJOSihs7STq2Ddew9BOSG4/ IhFtfRpUxqAEzL95WQ2ZmSRCjcbECkdPx/Kbeb49M0CbmDQvgL1Z5TBLWinAaBDW MveaLOl9ZhikscRCmahmlKFxqTi1vQD/uqfBG2qWQE8hp8IzGqIrd6oAVpZY56nB 6N2mp9VcKafm0/0v75lovBtjb3RZNpb/Zs8MSd9gMC0r3OAU37pSg5jcMWofL+Pl JE7bVufjtfbA3jZ3Doi/txkHjqpeYzwiSIwWq7AQARXWr4qx5m3hoRcnfaeypcHU Z9ghJXXT0GvG5tEI0ttQ3+XLIWrbwvN5eqqds+k+Um0Ey6r83+N0vYBjoxXSkI1s cm5ATnXxxYFK/KlAJu3U7l720dJ0hIEXKGmDhL9lT8CO1OUfj6s04KAwRugRf2jb r/cljsIfABTtOG4GXOaPA7jTRL4A07EbSHJBgQFoCvEbkji0OeAi3+q2IlqK51LX zuZQIvwuzU9HsI08o169 =KnYf -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From cloos@jhcloos.com Wed Nov 6 05:35:35 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F3711E81AC for ; Wed, 6 Nov 2013 05:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHBwTS+74v42 for ; Wed, 6 Nov 2013 05:35:35 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id 2825311E81A9 for ; Wed, 6 Nov 2013 05:35:35 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id D536B1E107; Wed, 6 Nov 2013 13:35:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1383744932; bh=zuUdVPUmzoPVsOkB9QsFVhw4RrXU6Od3kRZwBwm4J6U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZlujqlZl30hgdQ7wf4JWxX9r9AVyhDDID56W9MxxPMeGVh9n31svmGAtv09HgtreK FhIuu5peppqR95GprBxNbncIYLnadeJKFH8jJaeDvCWPnxQk+aPLgS15jEPFIWmm4x 6jSbqbG/6/PvkSr1r6doGzBjT6bWc2mhGEjt2PQwjdQ== Received: by carbon.jhcloos.org (Postfix, from userid 500) id D3C1A60022; Wed, 6 Nov 2013 13:33:14 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <789202E67F7415FC98D8FECF@96B2F16665FF96BAE59E9B90> (Chris Newman's message of "Tue, 05 Nov 2013 17:01:54 -0800") References: <789202E67F7415FC98D8FECF@96B2F16665FF96BAE59E9B90> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 06 Nov 2013 08:33:14 -0500 Message-ID: Lines: 19 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:131106:dane@ietf.org::3S/aKZ7tQtYXo8+g:000L/eDx X-Hashcash: 1:28:131106:chris.newman@oracle.com::C0qOTLK19q3BJDwk:0000000000000000000000000000000000000G6bKw Subject: Re: [dane] review of draft-ietf-dane-smtp-with-dane-02.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 13:35:35 -0000 >>>>> "CN" == Chris Newman writes: CN> *2* I believe it's undesirable to attempt to deploy DANE TLSA for CN> submission services (port 587 or de-facto port 465) TLSA SHOULD be checked for *all* TLS connections by clients. We should not have any RFCs which try to exempt certain ports, nor recommend avoiding DANE for certain ports or services. We want the TLS libraries to implement it (as gnutls has done) and for applications to take advantage of DANE whenever they initiate TLS sockets. The only real question is what to do when provided just an ip address. Should the TLSA be checked in arpa., or should it look under the name returned by a PTR lookup? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From stephen.nightingale@nist.gov Wed Nov 6 08:59:07 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0763921E8151 for ; Wed, 6 Nov 2013 08:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE6p9G19rlRb for ; Wed, 6 Nov 2013 08:59:01 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id D20D521E8115 for ; Wed, 6 Nov 2013 08:58:51 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 Nov 2013 11:58:33 -0500 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 6 Nov 2013 11:58:50 -0500 Received: from [127.0.0.1] (31-140.antd.nist.gov [129.6.140.31]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id rA6GwbrO015251; Wed, 6 Nov 2013 11:58:38 -0500 Message-ID: <527A753A.4040800@nist.gov> Date: Wed, 6 Nov 2013 11:58:34 -0500 From: Stephen Nightingale Organization: NIST User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: Subject: [dane] NIST DANE Tester Announcement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: night@nist.gov List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:00:57 -0000 For those DANEs who are in Vancouver, you can talk to Scott Rose or Doug Montgomery about this. Doug will be at the informal DANE lunch tomorrow. ======== NIST has developed a test system for the RFC 6698 DANE protocol. DANE seeks to verify PKIX certificate based Transport Layer Security (RFC 5246 TLS) connections using the Domain Name System as secured by DNSSEC. https://www.had-pilot.com/dane/danelaw.html The NIST DANE test system has three modes of operation: - Test your DANE enabled site: Enter the URL of a site for which a DANE TLSA resource record is provisioned. The system will negotiate the connection, verify with DANE and get the web page - or provide failure diagnostics. - A reference test set to test your browser in response to all possible DANE configurations. - If your browser is NOT DANE enabled, a reference test set to test a DANE client's response to all possible configurations and return the results to your browser. The site is up and available for testing - But it is still early days and there may be occasional outages. Please be patient and/or let us know. Stephen Nightingale, NIST HAD Pilot Program From bdickson@verisign.com Wed Nov 6 10:33:55 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6542511E8115 for ; Wed, 6 Nov 2013 10:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l979plW8QvqF for ; Wed, 6 Nov 2013 10:33:50 -0800 (PST) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6938011E815A for ; Wed, 6 Nov 2013 10:33:40 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUnqLhI/32Qgz+cjG3aUcgRDUB+y9l3Qm@postini.com; Wed, 06 Nov 2013 10:33:44 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id rA6IXcxc018167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 13:33:39 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 6 Nov 2013 13:33:38 -0500 From: "Dickson, Brian" To: James Cloos Thread-Topic: [dane] review of draft-ietf-dane-smtp-with-dane-02.txt Thread-Index: AQHO2o1Ul+ge8hzrak2w7zmU4/qW4ZoYNRIPgABTPls= Date: Wed, 6 Nov 2013 18:33:37 +0000 Message-ID: References: <789202E67F7415FC98D8FECF@96B2F16665FF96BAE59E9B90>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dane@ietf.org" Subject: Re: [dane] review of draft-ietf-dane-smtp-with-dane-02.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:33:55 -0000 Sent from my iPhone On Nov 6, 2013, at 5:35 AM, "James Cloos" wrote: >>>>>> "CN" =3D=3D Chris Newman writes: >=20 > CN> *2* I believe it's undesirable to attempt to deploy DANE TLSA for > CN> submission services (port 587 or de-facto port 465)=20 >=20 > TLSA SHOULD be checked for *all* TLS connections by clients. We should > not have any RFCs which try to exempt certain ports, nor recommend > avoiding DANE for certain ports or services. >=20 > We want the TLS libraries to implement it (as gnutls has done) and for > applications to take advantage of DANE whenever they initiate TLS sockets= . >=20 > The only real question is what to do when provided just an ip address. > Should the TLSA be checked in arpa., or should it look under the name > returned by a PTR lookup? >=20 I think, even if no TLSA records are found via those ways, that IF a cert i= s presented, a corresponding TLSA query should be made. That way, even if a= random IP wants to pretend to be FOO, that FOO has the implicit opportunit= y to assert that the IP is not presenting the real cert for FOO. Brian > -JimC > --=20 > James Cloos OpenPGP: 1024D/ED7DAEA6 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From anton@ministry.int.ru Wed Nov 6 11:52:42 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D9011E80D9 for ; Wed, 6 Nov 2013 11:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.229 X-Spam-Level: X-Spam-Status: No, score=-0.229 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDkq-nmBLcBR for ; Wed, 6 Nov 2013 11:52:38 -0800 (PST) Received: from leaf.named.informdeskmedia.ru (leaf.named.informdeskmedia.ru [85.17.236.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4D021E8142 for ; Wed, 6 Nov 2013 11:52:36 -0800 (PST) Received: from [2001:67c:370:144:21c:bfff:fe21:269e] (account postmaster@leaf.named.informdeskmedia.ru HELO firepaw) by leaf.named.informdeskmedia.ru (CommuniGate Pro SMTP 6.0.4 _community_) with ESMTPSA id 2300224; Wed, 06 Nov 2013 23:52:33 +0400 Date: Wed, 6 Nov 2013 21:52:28 +0200 From: Anton Baskov To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Message-Id: <20131106215228.dd601e0390c0b0939ec9866a@ministry.int.ru> In-Reply-To: References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <90B09F3E-2D11-4127-A5BB-9D243AB31097@kumari.net> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Paul Hoffman , "dane@ietf.org list" Subject: Re: [dane] Informal lunch meeting in Vancouver on Thursday X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 19:52:42 -0000 And me. -- Anton Baskov On Mon, 4 Nov 2013 14:27:47 -0800 Ondřej Surý wrote: > +1 > > -- > Ondřej Surý -- Chief Science Officer > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC > Americka 23, 120 00 Praha 2, CZE > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > > > > On 4. 11. 2013, at 12:08, Warren Kumari wrote: > > > > > >> On Nov 4, 2013, at 11:08 AM, Paul Hoffman wrote: > >> > >> Hi again. I have put in a room request for lunch on Thursday; I'll let the list know when I get it. If you're at the Vancouver IETF meeting and want to talk about DANE, hold the date. We'll meet at 11:45 in order to give people time to run out and get some food and bring it to the room; no food or beverage will be provided. > > > > Thank you. Will be there. > > > > W > > > >> > >> --Paul Hoffman > >> _______________________________________________ > >> dane mailing list > >> dane@ietf.org > >> https://www.ietf.org/mailman/listinfo/dane > > > > -- > > "Real children don't go hoppity-skip unless they are on drugs." > > > > -- Susan, the ultimate sensible governess (Terry Pratchett, Hogfather) > > > > > > > > > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From viktor1dane@dukhovni.org Wed Nov 6 14:14:50 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D82421E8095 for ; Wed, 6 Nov 2013 14:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnT8VTqtCxHc for ; Wed, 6 Nov 2013 14:14:46 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 43DB321F9FC8 for ; Wed, 6 Nov 2013 14:14:45 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B54842AB121; Wed, 6 Nov 2013 22:14:42 +0000 (UTC) Date: Wed, 6 Nov 2013 22:14:42 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131106221442.GB5561@mournblade.imrryr.org> References: <527A753A.4040800@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <527A753A.4040800@nist.gov> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] NIST DANE Tester Announcement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 22:14:50 -0000 On Wed, Nov 06, 2013 at 11:58:34AM -0500, Stephen Nightingale wrote: > https://www.had-pilot.com/dane/danelaw.html > > The NIST DANE test system has three modes of operation: > > - Test your DANE enabled site: > Enter the URL of a site for which a DANE TLSA resource record is > provisioned. The system will negotiate the connection, verify with > DANE and get the web page - or provide failure diagnostics. > > - A reference test set to test your browser in response to all > possible DANE configurations. > > - If your browser is NOT DANE enabled, a reference test set to test > a DANE client's response to all possible configurations and return > the results to your browser. > > The site is up and available for testing - But it is still early > days and there may be occasional outages. Please be patient and/or > let us know. Yet none of the major browsers are as ye showing interest in DANE. Perhaps a test-bed for DANE SMTP sites would be more useful in the near-term, as there is now at least one DANE capable MTA (Postfix), and another (Exim) coming soon. If they are interested in test case suggestions, they can get in touch with me off list. I am also interested in finding out which DANE client toolkit they are using. Publishing that code could help steer other implementations in the right direction, or help identify potential problems. -- Viktor. From stephen.nightingale@nist.gov Wed Nov 6 14:26:59 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C2D21F9B0E for ; Wed, 6 Nov 2013 14:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1OFBYOHJQTK for ; Wed, 6 Nov 2013 14:26:43 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 2A67511E814D for ; Wed, 6 Nov 2013 14:26:39 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 Nov 2013 17:26:16 -0500 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 6 Nov 2013 17:26:33 -0500 Received: from [127.0.0.1] (31-140.antd.nist.gov [129.6.140.31]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id rA6MQQww005414 for ; Wed, 6 Nov 2013 17:26:27 -0500 Message-ID: <527AC20E.3000204@nist.gov> Date: Wed, 6 Nov 2013 17:26:22 -0500 From: Stephen Nightingale Organization: NIST User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <527A753A.4040800@nist.gov> <20131106221442.GB5561@mournblade.imrryr.org> In-Reply-To: <20131106221442.GB5561@mournblade.imrryr.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: Subject: Re: [dane] NIST DANE Tester Announcement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: night@nist.gov List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 22:26:59 -0000 On 11/6/2013 5:14 PM, Viktor Dukhovni wrote: > On Wed, Nov 06, 2013 at 11:58:34AM -0500, Stephen Nightingale wrote: > >> https://www.had-pilot.com/dane/danelaw.html >> >> The NIST DANE test system has three modes of operation: >> >> - Test your DANE enabled site: >> Enter the URL of a site for which a DANE TLSA resource record is >> provisioned. The system will negotiate the connection, verify with >> DANE and get the web page - or provide failure diagnostics. >> >> - A reference test set to test your browser in response to all >> possible DANE configurations. >> >> - If your browser is NOT DANE enabled, a reference test set to test >> a DANE client's response to all possible configurations and return >> the results to your browser. >> >> The site is up and available for testing - But it is still early >> days and there may be occasional outages. Please be patient and/or >> let us know. > Yet none of the major browsers are as ye showing interest in DANE. > Perhaps a test-bed for DANE SMTP sites would be more useful in the > near-term, as there is now at least one DANE capable MTA (Postfix), > and another (Exim) coming soon. DANE SMTP (and SMIMEA) is coming soon. > > If they are interested in test case suggestions, they can get in > touch with me off list. I am also interested in finding out which > DANE client toolkit they are using. Publishing that code could > help steer other implementations in the right direction, or help > identify potential problems. The NIST DANE tester is implemented in Python over tlslite. I adapted the Checker function to do DANE. We'll offer to bundle it with tlslite once it's a bit more robust. We can probably make it available directly on the site as well. I'm looking into gnutls too, but more interested in pygnutls than C. Stephen. From Marco.Davids@sidn.nl Wed Nov 6 15:29:51 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3369521E80BD for ; Wed, 6 Nov 2013 15:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eupRmvofoCQr for ; Wed, 6 Nov 2013 15:29:47 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 4633C11E8113 for ; Wed, 6 Nov 2013 15:29:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=N5enkTdicS85tUFWbrzJ8fMy47QnjTBTFxQIXAnpgbs=; b=ZYlflZJchgn9clY5RNz9GC76j2SWq7MibKcBC6cZ/FdhGWe82GAkv+t67/sVVCPL0nVVSe1N9+El5RjwX3vFZGfuUu3UogQmBxnvxJfdcu56XJf8WrtEsp1/AgDdTg1a88YTj2tW3Iivbng6KSOZM27Y6p3guPmh/qgqUtMvwIQ= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id rA6NTZko003795-rA6NTZkq003795 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 7 Nov 2013 00:29:35 +0100 Received: from dhcp-ac6c.meeting.ietf.org (94.198.152.220) by kahubcasn02.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 00:29:34 +0100 Message-ID: <527AD0D7.4030000@sidn.nl> Date: Wed, 6 Nov 2013 15:29:27 -0800 From: "Marco Davids (SIDN)" Organization: SIDN User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: References: <527A753A.4040800@nist.gov> <20131106221442.GB5561@mournblade.imrryr.org> In-Reply-To: <20131106221442.GB5561@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.220] Subject: Re: [dane] NIST DANE Tester Announcement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 23:29:51 -0000 On 06/11/13 14:14, Viktor Dukhovni wrote: > On Wed, Nov 06, 2013 at 11:58:34AM -0500, Stephen Nightingale wrote: > >> https://www.had-pilot.com/dane/danelaw.html For those of you who prefer a somewhat more simple approach, there is still: https://check.sidnlabs.nl/dane/ -- Marco From Marco.Davids@sidn.nl Wed Nov 6 15:59:47 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B717D21E8159 for ; Wed, 6 Nov 2013 15:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CusxuU15X8e7 for ; Wed, 6 Nov 2013 15:59:41 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 964E321F9F96 for ; Wed, 6 Nov 2013 15:59:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=T5w5twFk/LjnzlqXZ+pgrPqvYlaLr2vmAT+x6l7hyZ4=; b=nopx9ZUO4f611d7EJ6dgusCGW3ZTdwcVoWup4zMgHXtr9nnMQnMoCFDJX69sV9jpcqiMCfrFaoxiJg/pinihAARlo0fIpbCw8TjfNmIBM88PThM664/HXt99CRh7+W54ivYzjSq++oFmSm4pbW4TZAs109agSYd0F4GwT7hjXoY= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id rA6NxUkO004680-rA6NxUkQ004680 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 7 Nov 2013 00:59:30 +0100 Received: from dhcp-ac6c.meeting.ietf.org (94.198.152.220) by kahubcasn02.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 00:59:30 +0100 Message-ID: <527AD7DB.3020201@sidn.nl> Date: Wed, 6 Nov 2013 15:59:23 -0800 From: "Marco Davids (SIDN)" Organization: SIDN User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: References: <527A753A.4040800@nist.gov> <20131106221442.GB5561@mournblade.imrryr.org> In-Reply-To: <20131106221442.GB5561@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.220] Subject: Re: [dane] NIST DANE Tester Announcement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 23:59:47 -0000 > On Wed, Nov 06, 2013 at 11:58:34AM -0500, Stephen Nightingale wrote: > >> https://www.had-pilot.com/dane/danelaw.html I don't quite get it... the test-domains.... they don't do DNSSEC properly? _443._tcp.000.tlsa.good.test.had-pilot.biz for example.... no DS in had-pilot.biz and no DS in biz? -- Marco From scottr.nist@gmail.com Wed Nov 6 20:39:38 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24AE11E811D for ; Wed, 6 Nov 2013 20:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHSktoVEQoYv for ; Wed, 6 Nov 2013 20:39:33 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id BB75011E80F5 for ; Wed, 6 Nov 2013 20:39:32 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id e14so37118iej.36 for ; Wed, 06 Nov 2013 20:39:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=okRCGJLq/hlJBGcl5Q2C9cOr8EZjP1tzVD4kb0PGEGc=; b=ffwcUSS0PNKoKb22p+q1A3JfpGL/ZrQsFhFL8qNyImUMnMu7vvD+5olmuuc6qvljlX LJ+LYfLguvNwtJ14NJfVo0EvKmOwGe1SNjiRetOTNktakimo9dhG1UXvPUWDCb24NSO2 7YFQY9gWG3JziwAcsgZUlx7WWzmsnHSHGzJnktRbXVmfNeCQdvDSVuTuULx4H5tSuacM j+XMhLP3k1WG+rhanhAXu66k9EwyJovJDKJ60vjHYxrI7qfRQDm+RR+aMWiqdvDOyBcJ 4EPTCdkjasNqU3t6SAiZXt9q3msi7wBjDmJUi5JpH/Uk5M/1Bf/2fzTo0FirgfOaqTTj KsRQ== MIME-Version: 1.0 X-Received: by 10.50.40.37 with SMTP id u5mr663386igk.29.1383799172043; Wed, 06 Nov 2013 20:39:32 -0800 (PST) Received: by 10.50.138.161 with HTTP; Wed, 6 Nov 2013 20:39:31 -0800 (PST) Date: Wed, 6 Nov 2013 20:39:31 -0800 Message-ID: From: Scott Rose To: dane@ietf.org Content-Type: multipart/mixed; boundary=089e0122f4f0177f5004ea8edae5 Subject: [dane] SMIMEA draft suggestion X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: scott.rose@nist.gov List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 04:39:38 -0000 --089e0122f4f0177f5004ea8edae5 Content-Type: multipart/alternative; boundary=089e0122f4f0177f4a04ea8edae3 --089e0122f4f0177f4a04ea8edae3 Content-Type: text/plain; charset=ISO-8859-1 Although I can't make the lunch meeting, there is other work going on at NIST to add some functionality to SMIMEA that we would like to propose. Attached is the (current) draft with added text. In summary, the new additions are: - a naming convention to distinguish digital signature and encryption key certs - a field to flag "revoked", used to signal that a user's SMIME certs have been revoked. An example of that is included at the end. - a field to indicate another certificate publication mechanism is in use (e.g. Webfinger) and that the SMIMEA RR can be used to validate the cert. We're not entirely sure if that is useful, but something we kicked around here based on other systems that are currently deployed. Others from our division should be at the meeting, but I'll be on a plane. NIST would be willing to take over editorship of the SMIMEA draft if that is desired - we just want to see this advanced. Scott --089e0122f4f0177f4a04ea8edae3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Although I can't make the lunch meeting, there is othe= r work going on at NIST to add some functionality to SMIMEA that we would l= ike to propose.

Attached is the (current) draft with add= ed text. =A0In summary, the new additions are:

- a naming convention to distinguish digital signature = and encryption key certs

- a field to flag "r= evoked", used to signal that a user's SMIME certs have been revoke= d. =A0An example of that is included at the end.

- a field to indicate another certificate publication m= echanism is in use (e.g. Webfinger) and that the SMIMEA RR can be used to v= alidate the cert. =A0We're not entirely sure if that is useful, but som= ething we kicked around here based on other systems that are currently depl= oyed.

Others from our division should be at the meeting, but = I'll be on a plane. =A0NIST would be willing to take over editorship of= the SMIMEA draft if that is desired - we just want to see this advanced.= =A0

Scott
--089e0122f4f0177f4a04ea8edae3-- --089e0122f4f0177f5004ea8edae5 Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-dane-smime-02.txt" Content-Disposition: attachment; filename="draft-ietf-dane-smime-02.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hnpi8z8s0 CgoKREFORSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBQLiBIb2ZmbWFuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBWUE4gQ29uc29ydGl1bQpJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSi4gU2NobHl0ZXIKRXhwaXJl czogQXByaWwgMywgMjAxNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEtpcmVpIEFCCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgUy4gUm9zZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5JU1QKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDMwLCAyMDEz CgoKVXNpbmcgU2VjdXJlIEROUyB0byBBc3NvY2lhdGUgQ2VydGlmaWNhdGVzIHdpdGggRG9tYWlu IE5hbWVzIEZvciBTL01JTUUKICAgICAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1kYW5l LXNtaW1lLTAyCgpBYnN0cmFjdAoKICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRvIHVz ZSBzZWN1cmUgRE5TIHRvIGFzc29jaWF0ZSBhbiBTL01JTUUKICAgdXNlcidzIGNlcnRpZmljYXRl IHdpdGggdGhlIGludGVuZGVkIGRvbWFpbiBuYW1lLCBzaW1pbGFyIHRvIHRoZSB3YXkKICAgdGhh dCBEQU5FIChSRkMgNjY5OCkgZG9lcyBmb3IgVExTLiAgU3BlY2lmaWMgbWVjaGFuaXNtcyBhcmUg aW5jbHVkZWQKICAgdG8gYWNjb21tb2RhdGUgc2VwYXJhdGUgZW5jcnlwdGlvbiBhbmQgc2lnbmF0 dXJlIGNlcnRpZmljYXRlcy4KClJlcXVpcmVtZW50cyBMYW5ndWFnZQoKICAgVGhlIGtleSB3b3Jk cyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAog ICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTk9UIFJFQ09NTUVOREVE IiwgIk1BWSIsIGFuZAogICAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGlu dGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbgogICBbUkZDMjExOV0uCgogICBUaGlzIGRvY3VtZW50 IGFsc28gbWFrZXMgdXNlIG9mIHN0YW5kYXJkIFBLSVgsIEROU1NFQywgYW5kIFMvTUlNRQogICB0 ZXJtaW5vbG9neS4gIFNlZSBbUkZDNTI4MF0sIFtSRkM0MDMzXSwgW1JGQzQwMzRdLCBbUkZDNDAz NV0sIGFuZAogICBbUkZDNTc1MV0gcmVzcGVjdGl2ZWx5LCBmb3IgdGhlc2UgdGVybXMuCgpTdGF0 dXMgb2YgVGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBm dWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1Ag NzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRl cm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBn cm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5l dC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMgYXQg aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4KCiAgIEludGVybmV0 LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1v bnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3Ro ZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0g b3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGlzIEludGVybmV0LURyYWZ0 IHdpbGwgZXhwaXJlIG9uIEFwcmlsIDMsIDIwMTQuCgpDb3B5cmlnaHQgTm90aWNlCgoKCkhvZmZt YW4sIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAzLCAyMDE0ICAgICAgICAgICAgICAg ICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICBETlMtQmFzZWQgQXV0aGVudGljYXRpb24g Zm9yIFMvTUlNRSAgICBTZXB0ZW1iZXIgMjAxMwoKCiAgIENvcHlyaWdodCAoYykgMjAxMyBJRVRG IFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBhdXRo b3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0 byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxhdGlu ZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1p bmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1 bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAgIGNhcmVmdWxseSwgYXMgdGhl eSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdAogICB0 byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9j dW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNj cmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5k IGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2lt cGxpZmllZCBCU0QgTGljZW5zZS4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKSG9mZm1hbiwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDMsIDIwMTQgICAgICAg ICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgIEROUy1CYXNlZCBBdXRoZW50 aWNhdGlvbiBmb3IgUy9NSU1FICAgIFNlcHRlbWJlciAyMDEzCgoKVGFibGUgb2YgQ29udGVudHMK CiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgNAogICAgIDEuMS4gIFNjb3BlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKCiAgIDIuICBUaGUgU01JTUVBIFJlc291 cmNlIFJlY29yZCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAgIDIu MS4gIFNNSU1FQSBSREFUQSBGaWVsZHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDUKICAgICAgIDIuMS4xLiAgVGhlIENlcnRpZmljYXRlIFVzYWdlIEZpZWxkICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgICAgICAyLjEuMi4gIFRoZSBTZWxlY3RvciBGaWVs ZCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNwogICAgICAgMi4xLjMuICBU aGUgTWF0Y2hpbmcgVHlwZSBGaWVsZCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcK ICAgICAgIDIuMS40LiAgQ2VydGlmaWNhdGUgQWNjZXNzIEZpZWxkIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA3CiAgICAgICAyLjEuNS4gIFRoZSBDZXJ0aWZpY2F0ZSBBc3NvY2lhdGlv biBEYXRhIEZpZWxkIC4gLiAuIC4gLiAuIC4gLiAgOAogICAgIDIuMi4gIFNNSU1FQSBSUiBQcmVz ZW50YXRpb24gRm9ybWF0ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAgICAyLjMu ICBTTUlNRUEgUlIgRXhhbXBsZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA5CgogICAzLiAgRG9tYWluIE5hbWVzIGZvciBTL01JTUUgQ2VydGlmaWNhdGUgQXNzb2Np YXRpb25zIC4gLiAuIC4gLiAuIC4gIDkKICAgICAzLjEuICBEb21haW4gTmFtZSBQcmVwYXJhdGlv biAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgICAgMy4yLiAgRG9tYWlu IE5hbWUgRXhhbXBsZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMAoK ICAgNC4gIFVzZSBvZiBTTUlNRUEgUmVjb3JkcyBpbiBTTUlNRSAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDExCiAgICAgNC4xLiAgVXNhYmxlIENlcnRpZmljYXRlIEFzc29jaWF0aW9u cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQoKICAgNS4gIE1hbmRhdG9yeS10by1JbXBs ZW1lbnQgRmVhdHVyZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyCgogICA2LiAg SUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTIKICAgICA2LjEuICBTTUlNRUEgUlJ0eXBlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyCiAgICAgNi4yLiAgU01JTUVBIENlcnRpZmljYXRlIFVz YWdlIFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICAgIDYuMy4gIFNNSU1F QSBTZWxlY3RvcnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMK ICAgICA2LjQuICBTTUlNRUEgTWF0Y2hpbmcgVHlwZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDE0CiAgICAgNi41LiAgQ2VydGlmaWNhdGUgQWNjZXNzIEZpZWxkIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNAoKICAgNy4gIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0CgogICA4LiAg QWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTUKCiAgIDkuICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQogICAgIDkuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2Vz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUKICAgICA5LjIuICBJbmZv cm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3 CgogICBBcHBlbmRpeCBBLiAgT3BlcmF0aW9uYWwgQ29uc2lkZXJhdGlvbnMgZm9yIERlcGxveWlu ZyBTTUlNRUEKICAgICAgICAgICAgICAgIFJlY29yZHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4CiAgICAgQS4xLiAgUHJvdmlzaW9uaW5nIFNNSU1FQSBS ZWNvcmRzIGluIEROUyB3aXRoIEFsaWFzZXMgYW5kCiAgICAgICAgICAgV2lsZGNhcmRzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOAogICAgICAgQS4x LjEuICBQcm92aXNpb25pbmcgU01JTUVBIHdpdGggRE5BTUUgUmVjb3JkcyAuIC4gLiAuIC4gLiAu IC4gMTgKICAgICAgIEEuMS4yLiAgUHJvdmlzaW9uaW5nIFNNSU1FQSB3aXRoIENOQU1FIFJlY29y ZHMgLiAuIC4gLiAuIC4gLiAuIDE5CiAgICAgICBBLjEuMy4gIFByb3Zpc2lvbmluZyBTTUlNRUEg UmVjb3JkcyB3aXRoIFdpbGRjYXJkcyAuIC4gLiAuIC4gLiAxOQogICAgICAgICBBLjEuMy4xLiAg V2lsZGNhcmQgZm9yIEFsbCBJbnZhbGlkIFVzZXJzIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjAKICAg ICAgICAgQS4xLjMuMi4gIE9yZ2FuaXphdGlvbiBUQSBXaWxkY2FyZCAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDIwCgoKCkhvZmZtYW4sIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAz LCAyMDE0ICAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICBETlMt QmFzZWQgQXV0aGVudGljYXRpb24gZm9yIFMvTUlNRSAgICBTZXB0ZW1iZXIgMjAxMwoKCjEuICBJ bnRyb2R1Y3Rpb24KCiAgIFMvTUlNRSBbUkZDNTc1MV0gbWVzc2FnZXMgb2Z0ZW4gY29udGFpbiBh IGNlcnRpZmljYXRlLiAgVGhpcwogICBjZXJ0aWZpY2F0ZSBhc3Npc3RzIGluIGF1dGhlbnRpY2F0 aW5nIHRoZSBzZW5kZXIgb2YgdGhlIG1lc3NhZ2UgYW5kCiAgIGNhbiBiZSB1c2VkIGZvciBlbmNy eXB0aW5nIG1lc3NhZ2VzIHRoYXQgd2lsbCBiZSBzZW50IGluIHJlcGx5LiAgSW4KICAgb3JkZXIg Zm9yIHRoZSBTL01JTUUgcmVjZWl2ZXIgdG8gYXV0aGVudGljYXRlIHRoYXQgYSBtZXNzYWdlIGlz IHRoZQogICBzZW5kZXIgd2hvIGlzIGlkZW50aWZpZWQgaW4gdGhlIG1lc3NhZ2UsIHRoZSByZWNl aXZlcidzIG1haWwgdXNlcgogICBhZ2VudCAoTVVBKSBtdXN0IHZhbGlkYXRlIHRoYXQgdGhpcyBj ZXJ0aWZpY2F0ZSBpcyBhc3NvY2lhdGVkIHdpdGgKICAgdGhlIHB1cnBvcnRlZCBzZW5kZXIuICBD dXJyZW50bHksIHRoZSBNVUEgbXVzdCB0cnVzdCBhIHRydXN0IGFuY2hvcgogICB1cG9uIHdoaWNo IHRoZSBzZW5kZXIncyBjZXJ0aWZpY2F0ZSBpcyByb290ZWQsIGFuZCBtdXN0IHN1Y2Nlc3NmdWxs eQogICB2YWxpZGF0ZSB0aGUgY2VydGlmaWNhdGUuCgogICBTb21lIHBlb3BsZSB3YW50IHRvIGF1 dGhlbnRpY2F0ZSB0aGUgYXNzb2NpYXRpb24gb2YgdGhlIHNlbmRlcidzCiAgIGNlcnRpZmljYXRl IHdpdGggdGhlIHNlbmRlciB3aXRob3V0IHRydXN0aW5nIGEgY29uZmlndXJlZCB0cnVzdAogICBh bmNob3IuICBHaXZlbiB0aGF0IHRoZSBETlMgYWRtaW5pc3RyYXRvciBmb3IgYSBkb21haW4gbmFt ZSBpcwogICBhdXRob3JpemVkIHRvIGdpdmUgaWRlbnRpZnlpbmcgaW5mb3JtYXRpb24gYWJvdXQg dGhlIHpvbmUsIGl0IG1ha2VzCiAgIHNlbnNlIHRvIGFsbG93IHRoYXQgYWRtaW5pc3RyYXRvciB0 byBhbHNvIG1ha2UgYW4gYXV0aG9yaXRhdGl2ZQogICBiaW5kaW5nIGJldHdlZW4gZW1haWwgbWVz c2FnZXMgcHVycG9ydGluZyB0byBjb21lIGZyb20gdGhlIGRvbWFpbgogICBuYW1lIGFuZCBhIGNl cnRpZmljYXRlIHRoYXQgbWlnaHQgYmUgdXNlZCBieSBzb21lb25lIGF1dGhvcml6ZWQgdG8KICAg c2VuZCBtYWlsIGZyb20gdGhvc2Ugc2VydmVycy4gIFRoZSBlYXNpZXN0IHdheSB0byBkbyB0aGlz IGlzIHRvIHVzZQogICB0aGUgRE5TLgoKICAgVG8gc2VuZCBTL01JTUUgZW5jcnlwdGVkIG1lc3Nh Z2VzIHRvIGFub3RoZXIgdXNlciwgaXQgaXMgbmVjZXNzYXJ5IHRvCiAgIGhhdmUgdGhlIGludGVu ZGVkIHJlY2lwaWVudCdzIGVuY3J5cHRpb24gY2VydGlmaWNhdGUuICBJZiB0aGUgdXNlcnMKICAg ZG8gbm90IHNoYXJlIGEgY29tbW9uIGNlcnRpZmljYXRlIGRpcmVjdG9yeSwgdGhlIGludGVuZGVk IHJlY2lwaWVudAogICBtdXN0IHByb3ZpZGUgaGlzL2hlciBjZXJ0aWZpY2F0ZSBwcmlvciB0byBz dWNjZXNzZnVsIGVuY3J5cHRpb24uICBUaGUKICAgRE5TIGlzIGEgZ29vZCB3YXkgdG8gcHVibGlz aCB0aGVzZSBjZXJ0aWZpY2F0ZXMgb3IgdG8gYWR2ZXJ0aXNlIGEKICAgbG9jYXRpb24gZm9yIGFj Y2Vzc2luZyB0aGVtLgoKICAgUy9NSU1FIGJlc3QgcHJhY3RpY2VzIHJlcXVpcmUgc2VwYXJhdGUg cHVibGljIGtleXMgZm9yIGVuY3J5cHRpb24gYW5kCiAgIFNpZ25hdHVyZXMgW05JU1QuODAwLTU3 LTFdLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHN0cnVjdHVyZXMgdG8KICAgYWNjb21tb2RhdGUg ZGlzdGluY3QgY2VydGlmaWNhdGVzIGZvciBTTUlNRSBlbmNyeXB0aW9uIGFuZCBzaWduYXR1cmUK ICAgb3BlcmF0aW9ucy4KCiAgIFRoaXMgc3RhbmRhcmQgaXMgbGFyZ2VseSBiYXNlZCBvbiBEQU5F IGZvciBUTFMgW1JGQzY2OThdIGFuZCB1c2VzCiAgIHRlcm1pbm9sb2d5IGZyb20gW0ktRC5kcmFm dC1pZXRmLWRhbmUtcmVnaXN0cnktYWNyb255bXNdLgoKMS4xLiAgU2NvcGUKCiAgIFRoaXMgZG9j dW1lbnQgZGVmaW5lcyBhIG1lY2hhbmlzbSB0byBlbXBsb3kgRE5TL0ROU1NFQyB0byBkaXNjb3Zl cgogICBhbmQgdmFsaWRhdGUgdXNlcnMnIFMvTUlNRSBlbmNyeXB0aW9uIGNlcnRpZmljYXRlcyBh bmQgdG8gdmFsaWRhdGUKICAgY2VydGlmaWNhdGVzIGluIFMvTUlNRSBkaWdpdGFsIHNpZ25hdHVy ZXMuICBJdCBkb2VzIG5vdCBhbHRlcgogICBzdGFuZGFyZHMgZm9yIFMvTUlNRSBbUkZDNTc1MV0g b3IgYW55IGVtYWlsIG9yIG1lc3NhZ2UgcmVsYXRlZAogICBwcm90b2NvbC4KCiAgIFRoaXMgZG9j dW1lbnQgZG9lcyBub3QgcHJvcG9zZSB0byBkZXNpZ25hdGUgb3IgdXNlIHRoZSBETlMgYXMgYQog ICBoaXN0b3JpY2FsIGFyY2hpdmUgb2YgdXNlciBhbmQgdHJ1c3QgYW5jaG9yIGNlcnRpZmljYXRl cy4KICAgQ2VydGlmaWNhdGVzIG1hZGUgYXZhaWxhYmxlIHZpYSBEQU5FIGFyZSBhc3NlcnRlZCB0 byBiZSB2YWxpZC4gIFRoaXMKCgoKSG9mZm1hbiwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEFw cmlsIDMsIDIwMTQgICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAg IEROUy1CYXNlZCBBdXRoZW50aWNhdGlvbiBmb3IgUy9NSU1FICAgIFNlcHRlbWJlciAyMDEzCgoK ICAgbWVjaGFuaXNtIGNhbiBiZSB1c2VkIHRvIGZhY2lsaXRhdGUga2V5IHJvbGxvdmVycywgYnV0 IHdpbGwgbm90CiAgIGFkZHJlc3MgdGhlIGlzc3VlIG9mIHByb3ZpZGluZyBvciB2YWxpZGF0aW5n IGV4cGlyZWQgY2VydGlmaWNhdGVzLgoKMi4gIFRoZSBTTUlNRUEgUmVzb3VyY2UgUmVjb3JkCgog ICBUaGUgU01JTUVBIEROUyByZXNvdXJjZSByZWNvcmQgKFJSKSBpcyB1c2VkIHRvIGFzc29jaWF0 ZSBhbiBlbmQKICAgZW50aXR5IGNlcnRpZmljYXRlIG9yIHB1YmxpYyBrZXkgd2l0aCB0aGUgYXNz b2NpYXRlZCBlbWFpbCBhZGRyZXNzLAogICB0aHVzIGZvcm1pbmcgYSAiU01JTUVBIGNlcnRpZmlj YXRlIGFzc29jaWF0aW9uIi4KCiAgIFRoZSB0eXBlIHZhbHVlIGZvciB0aGUgU01JTUVBIFJSIHR5 cGUgaXMgdG8gYmUgYXNzaWduZWQuCgogICBUaGUgU01JTUVBIFJSIGlzIGNsYXNzIGluZGVwZW5k ZW50LgoKICAgVGhlIFNNSU1FQSBSUiBoYXMgbm8gc3BlY2lhbCBUVEwgcmVxdWlyZW1lbnRzLgoK Mi4xLiAgU01JTUVBIFJEQVRBIEZpZWxkcwoKICAgVGhlIFJEQVRBIGZvciB0aGUgU01JTUVBIFJS IGNvbnNpc3RzIG9mIGEgb25lLW9jdGV0IGNlcnRpZmljYXRlIHVzYWdlCiAgIGZpZWxkLCBhIG9u ZS1vY3RldCBzZWxlY3RvciBmaWVsZCwgYSBvbmUtb2N0ZXQgbWF0Y2hpbmcgdHlwZSBmaWVsZCwg YQogICBvbmUtb2N0ZXQgY2VydGlmaWNhdGUgYWNjZXNzIGZpZWxkLCBhbmQgdGhlIGNlcnRpZmlj YXRlIGFzc29jaWF0aW9uCiAgIGRhdGEgZmllbGQuCgogICAgICAgICAgICAgICAgICAgICAgICAg ICAxIDEgMSAxIDEgMSAxIDEgMSAxIDIgMiAyIDIgMiAyIDIgMiAyIDIgMyAzCiAgICAgICAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsKICAgICAgfCAgQ2VydC4gVXNhZ2UgIHwgICBTZWxlY3RvciAgICB8 IE1hdGNoaW5nIFR5cGUgfCBDZXJ0LiBBY2Nlc3MgIHwKICAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgLyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC8KICAgICAgLyAgICAgICAgICAgICAgICAgQ2VydGlmaWNhdGUgQXNzb2NpYXRpb24gRGF0 YSAgICAgICAgICAgICAgICAgIC8KICAgICAgLyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8KICAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCgoKMi4x LjEuICBUaGUgQ2VydGlmaWNhdGUgVXNhZ2UgRmllbGQKCiAgIEEgb25lLW9jdGV0IHZhbHVlLCBj YWxsZWQgImNlcnRpZmljYXRlIHVzYWdlIiwgc3BlY2lmaWVzIHRoZSBwcm92aWRlZAogICBhc3Nv Y2lhdGlvbiB0aGF0IHdpbGwgYmUgdXNlZCB0byB2YWxpZGF0ZSB0aGUgY2VydGlmaWNhdGUuICBU aGlzCiAgIHZhbHVlIHdpbGwgYmUgZGVmaW5lZCBpbiBhIG5ldyBJQU5BIHJlZ2lzdHJ5IGluIG9y ZGVyIHRvIG1ha2UgaXQKICAgZWFzaWVyIHRvIGFkZCBhZGRpdGlvbmFsIGNlcnRpZmljYXRlIHVz YWdlcyBpbiB0aGUgZnV0dXJlLiAgRm91ciBvZgogICB0aGUgaW5pdGlhbCB1c2FnZXMgZGVmaW5l ZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBzaW1pbGFyIHRvIHRoZSBmaXJzdAogICBmb3VyIFRMU0Eg W1JGQzY2OThdIGNlcnRpZmljYXRlIHVzYWdlcy4gIFRoZSBjZXJ0aWZpY2F0ZSB1c2FnZSB2YWx1 ZXMKICAgYXJlOgoKICAgICAgMCBvciBQS0lYLUNBIC0tIFBLSVgtQ0EgaXMgdXNlZCB0byBzcGVj aWZ5IGEgQ0EgY2VydGlmaWNhdGUsIG9yCiAgICAgIHRoZSBwdWJsaWMga2V5IG9mIHN1Y2ggYSBj ZXJ0aWZpY2F0ZSwgdGhhdCBNVVNUIGJlIGZvdW5kIGluIGFueSBvZgogICAgICB0aGUgUEtJWCBj ZXJ0aWZpY2F0aW9uIHBhdGhzIGZvciB0aGUgdXNlci4gIFRoaXMgY2VydGlmaWNhdGUgdXNhZ2UK ICAgICAgaXMgc29tZXRpbWVzIHJlZmVycmVkIHRvIGFzICJDQSBjb25zdHJhaW50IiBiZWNhdXNl IGl0IGxpbWl0cwoKCgpIb2ZmbWFuLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXByaWwgMywg MjAxNCAgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgRE5TLUJh c2VkIEF1dGhlbnRpY2F0aW9uIGZvciBTL01JTUUgICAgU2VwdGVtYmVyIDIwMTMKCgogICAgICB3 aGljaCBDQSBjYW4gYmUgdXNlZCB0byBpc3N1ZSBjZXJ0aWZpY2F0ZXMgZm9yIGEgZ2l2ZW4gdXNl ci4gIFRoZQogICAgICBwcmVzZW50ZWQgY2VydGlmaWNhdGUgTVVTVCBwYXNzIFBLSVggY2VydGlm aWNhdGlvbiBwYXRoCiAgICAgIHZhbGlkYXRpb24sIGFuZCBhIENBIGNlcnRpZmljYXRlIHRoYXQg bWF0Y2hlcyB0aGUgU01JTUVBIHJlY29yZAogICAgICBNVVNUIGJlIGluY2x1ZGVkIGFzIHBhcnQg b2YgYSB2YWxpZCBjZXJ0aWZpY2F0aW9uIHBhdGguICBCZWNhdXNlCiAgICAgIHRoaXMgY2VydGlm aWNhdGUgdXNhZ2UgYWxsb3dzIGJvdGggdHJ1c3QgYW5jaG9ycyBhbmQgQ0EKICAgICAgY2VydGlm aWNhdGVzLCB0aGUgY2VydGlmaWNhdGUgbWlnaHQgb3IgbWlnaHQgbm90IGhhdmUgdGhlCiAgICAg IGJhc2ljQ29uc3RyYWludHMgZXh0ZW5zaW9uIHByZXNlbnQuCgogICAgICAxIG9yIFBLSVgtRUUg LS0gUEtJWC1FRSBpcyB1c2VkIHRvIHNwZWNpZnkgYW4gZW5kIGVudGl0eQogICAgICBjZXJ0aWZp Y2F0ZSwgb3IgdGhlIHB1YmxpYyBrZXkgb2Ygc3VjaCBhIGNlcnRpZmljYXRlLCB0aGF0IE1VU1Qg YmUKICAgICAgbWF0Y2hlZCB3aXRoIHRoZSBlbmQgZW50aXR5IGNlcnRpZmljYXRlIGZvciB0aGUg U01JTUUgdXNlci4gIFRoaXMKICAgICAgY2VydGlmaWNhdGUgdXNhZ2UgaXMgc29tZXRpbWVzIHJl ZmVycmVkIHRvIGFzICJ1c2VyIGNlcnRpZmljYXRlCiAgICAgIGNvbnN0cmFpbnQiIGJlY2F1c2Ug aXQgbGltaXRzIHdoaWNoIGVuZCBlbnRpdHkgY2VydGlmaWNhdGUgY2FuIGJlCiAgICAgIHVzZWQg YnkgYSBnaXZlbiB1c2VyLiAgVGhlIHRhcmdldCB1c2VyIGNlcnRpZmljYXRlIE1VU1QgcGFzcyBQ S0lYCiAgICAgIGNlcnRpZmljYXRpb24gcGF0aCB2YWxpZGF0aW9uIGFuZCBNVVNUIG1hdGNoIHRo ZSBTTUlNRUEgcmVjb3JkLgoKICAgICAgMiBvciBEQU5FLVRBIC0tIERBTkUtVEEgaXMgdXNlZCB0 byBzcGVjaWZ5IGEgY2VydGlmaWNhdGUsIG9yIHRoZQogICAgICBwdWJsaWMga2V5IG9mIHN1Y2gg YSBjZXJ0aWZpY2F0ZSwgdGhhdCBNVVNUIGJlIHVzZWQgYXMgdGhlIHRydXN0CiAgICAgIGFuY2hv ciB3aGVuIHZhbGlkYXRpbmcgdGhlIFNNSU1FIHVzZXIgY2VydGlmaWNhdGUuICBUaGlzCiAgICAg IGNlcnRpZmljYXRlIHVzYWdlIGlzIHNvbWV0aW1lcyByZWZlcnJlZCB0byBhcyAidHJ1c3QgYW5j aG9yCiAgICAgIGFzc2VydGlvbiIgYW5kIGFsbG93cyBhIGRvbWFpbiBuYW1lIGFkbWluaXN0cmF0 b3IgdG8gc3BlY2lmeSBhIG5ldwogICAgICB0cnVzdCBhbmNob3IgLS0gZm9yIGV4YW1wbGUsIGlm IHRoZSBkb21haW4gaXNzdWVzIGl0cyBvd24KICAgICAgY2VydGlmaWNhdGVzIHVuZGVyIGl0cyBv d24gQ0EgdGhhdCBpcyBub3QgZXhwZWN0ZWQgdG8gYmUgaW4gdGhlCiAgICAgIGVuZCB1c2Vycycg Y29sbGVjdGlvbiBvZiB0cnVzdCBhbmNob3JzLiAgVGhlIHRhcmdldCB1c2VyCiAgICAgIGNlcnRp ZmljYXRlIE1VU1QgcGFzcyBQS0lYIGNlcnRpZmljYXRpb24gcGF0aCB2YWxpZGF0aW9uLCB3aXRo IGFueQogICAgICBjZXJ0aWZpY2F0ZSBtYXRjaGluZyB0aGUgU01JTUVBIHJlY29yZCBjb25zaWRl cmVkIHRvIGJlIGEgdHJ1c3QKICAgICAgYW5jaG9yIGZvciB0aGlzIGNlcnRpZmljYXRpb24gcGF0 aCB2YWxpZGF0aW9uLgoKICAgICAgMyBvciBEQU5FLUVFIC0tIERBTkUtRUUgaXMgdXNlZCB0byBz cGVjaWZ5IGEgY2VydGlmaWNhdGUsIG9yIHRoZQogICAgICBwdWJsaWMga2V5IG9mIHN1Y2ggYSBj ZXJ0aWZpY2F0ZSwgdGhhdCBNVVNUIG1hdGNoIHRoZSBTTUlNRSB1c2VyJ3MKICAgICAgY2VydGlm aWNhdGUuICBUaGlzIGNlcnRpZmljYXRlIHVzYWdlIGlzIHNvbWV0aW1lcyByZWZlcnJlZCB0byBh cwogICAgICAiZG9tYWluLWlzc3VlZCBjZXJ0aWZpY2F0ZSIgYmVjYXVzZSBpdCBhbGxvd3MgZm9y IGEgZG9tYWluIG5hbWUKICAgICAgYWRtaW5pc3RyYXRvciB0byBpc3N1ZSBjZXJ0aWZpY2F0ZXMg Zm9yIGEgZG9tYWluIHdpdGhvdXQgaW52b2x2aW5nCiAgICAgIGEgdGhpcmQtcGFydHkgQ0EuICBU aGUgdGFyZ2V0IHVzZXIgY2VydGlmaWNhdGUgTVVTVCBtYXRjaCB0aGUKICAgICAgU01JTUVBIHJl Y29yZC4gIFRoZSBkaWZmZXJlbmNlIGJldHdlZW4gY2VydGlmaWNhdGUgdXNhZ2UgMSBhbmQKICAg ICAgY2VydGlmaWNhdGUgdXNhZ2UgMyBpcyB0aGF0IGNlcnRpZmljYXRlIHVzYWdlIDEgcmVxdWly ZXMgdGhhdCB0aGUKICAgICAgY2VydGlmaWNhdGUgcGFzcyBQS0lYIHZhbGlkYXRpb24sIGJ1dCBQ S0lYIHZhbGlkYXRpb24gaXMgbm90CiAgICAgIHRlc3RlZCBmb3IgY2VydGlmaWNhdGUgdXNhZ2Ug My4KCiAgICAgIDQgb3IgUkVKRUNUIC0tIFJFSkVDVCBpcyB1c2VkIGJ5IHRoZSBkb21haW4gb3du ZXIgdG8gYXNzZXJ0IHRoYXQKICAgICAgdGhpcyB1c2VyJ3MgY2VydGlmaWNhdGUgTVVTVCBiZSBj b25zaWRlcmVkIGludmFsaWQgZm9yIHRoZQogICAgICByZXF1ZXN0ZWQgZnVuY3Rpb24gKGkuZS4g c2lnbmF0dXJlIG9yIGVuY3J5cHRpb24pLiAgVGhpcyBpcyBhCiAgICAgIHN0cm9uZ2VyIGFzc2Vy dGlvbiB0aGFuIGEgZmFpbGVkIGNlcnRpZmljYXRlIHZhbGlkYXRpb24gY2hlY2suCiAgICAgIFBv c3NpYmxlIHVzYWdlIHNjZW5hcmlvcyBpbmNsdWRlIHVucmVjb2duaXplZCB1c2VyIG5hbWVzIGFu ZAogICAgICByZXZva2VkIHVzZXIgY2VydGlmaWNhdGVzLiAgVmFsdWVzIGluIGFsbCBvdGhlciBS REFUQSBmaWVsZHMgTUFZCiAgICAgIGJlIGlnbm9yZWQgYnV0IGFsbCBmaWVsZHMgTVVTVCBiZSBw b3B1bGF0ZWQgdG8gY29tcGx5IHdpdGggU01JTUVBCiAgICAgIFJEQVRBIHBhcnNpbmcgcmVxdWly ZW1lbnRzLgoKCgoKSG9mZm1hbiwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDMsIDIw MTQgICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgIEROUy1CYXNl ZCBBdXRoZW50aWNhdGlvbiBmb3IgUy9NSU1FICAgIFNlcHRlbWJlciAyMDEzCgoKICAgVGhlIGNl cnRpZmljYXRlIHVzYWdlcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgZXhwbGljaXRseSBvbmx5 IGFwcGx5CiAgIHRvIFBLSVgtZm9ybWF0dGVkIGNlcnRpZmljYXRlcyBpbiBERVIgZW5jb2Rpbmcg W0lUVS5YNjkwLjIwMDJdLiAgSWYKICAgU01JTUUgYWxsb3dzIG90aGVyIGZvcm1hdHMgbGF0ZXIs IG9yIGlmIGV4dGVuc2lvbnMgdG8gdGhpcyBSUiB0eXBlCiAgIGFyZSBtYWRlIHRoYXQgYWNjZXB0 IG90aGVyIGZvcm1hdHMgZm9yIGNlcnRpZmljYXRlcywgdGhvc2UKICAgY2VydGlmaWNhdGVzIHdp bGwgbmVlZCB0aGVpciBvd24gY2VydGlmaWNhdGUgdXNhZ2UgdmFsdWVzLgoKMi4xLjIuICBUaGUg U2VsZWN0b3IgRmllbGQKCiAgIEEgb25lLW9jdGV0IHZhbHVlLCBjYWxsZWQgInNlbGVjdG9yIiwg c3BlY2lmaWVzIHdoaWNoIHBhcnQgb2YgdGhlCiAgIFNNSU1FIGNlcnRpZmljYXRlIHByZXNlbnRl ZCBieSB0aGUgc2VydmVyIHdpbGwgYmUgbWF0Y2hlZCBhZ2FpbnN0IHRoZQogICBhc3NvY2lhdGlv biBkYXRhLiAgVGhpcyB2YWx1ZSB3aWxsIGJlIGRlZmluZWQgaW4gYSBuZXcgSUFOQSByZWdpc3Ry eS4KICAgVGhlIHNlbGVjdG9ycyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgYXJlOgoKICAgICAg MCBvciBDRVJUIC0tIEZ1bGwgY2VydGlmaWNhdGU6IHRoZSBDZXJ0aWZpY2F0ZSBiaW5hcnkgc3Ry dWN0dXJlIGFzCiAgICAgIGRlZmluZWQgaW4gW1JGQzUyODBdLgoKICAgICAgMSBvciBTUEtJIC0t IFN1YmplY3RQdWJsaWNLZXlJbmZvOiBERVItZW5jb2RlZCBiaW5hcnkgc3RydWN0dXJlIGFzCiAg ICAgIGRlZmluZWQgaW4gW1JGQzUyODBdLgoKICAgKE5vdGUgdGhhdCB0aGUgdXNlIG9mICJzZWxl Y3RvciIgaW4gdGhpcyBkb2N1bWVudCBpcyBjb21wbGV0ZWx5CiAgIHVucmVsYXRlZCB0byB0aGUg dXNlIG9mICJzZWxlY3RvciIgaW4gRG9tYWluS2V5cyBJZGVudGlmaWVkIE1haWwKICAgKERLSU0p IFtSRkM2Mzc2XS4pCgoyLjEuMy4gIFRoZSBNYXRjaGluZyBUeXBlIEZpZWxkCgogICBBIG9uZS1v Y3RldCB2YWx1ZSwgY2FsbGVkICJtYXRjaGluZyB0eXBlIiwgc3BlY2lmaWVzIGhvdyB0aGUKICAg Y2VydGlmaWNhdGUgYXNzb2NpYXRpb24gaXMgcHJlc2VudGVkLiAgVGhpcyB2YWx1ZSB3aWxsIGJl IGRlZmluZWQgaW4KICAgYSBuZXcgSUFOQSByZWdpc3RyeS4gIFRoZSB0eXBlcyBkZWZpbmVkIGlu IHRoaXMgZG9jdW1lbnQgYXJlOgoKICAgICAgMCBvciBGdWxsIC0tIEV4YWN0IG1hdGNoIG9uIHNl bGVjdGVkIGNvbnRlbnQKCiAgICAgIDEgb3IgU0hBMi0yNTYgLS0gU0hBLTI1NiBoYXNoIG9mIHNl bGVjdGVkIGNvbnRlbnQgW1JGQzYyMzRdCgogICAgICAyIG9yIFNIQTItNTEyIC0tIFNIQS01MTIg aGFzaCBvZiBzZWxlY3RlZCBjb250ZW50IFtSRkM2MjM0XQoKICAgSWYgdGhlIFNNSU1FQSByZWNv cmQncyBtYXRjaGluZyB0eXBlIGlzIGEgaGFzaCwgaGF2aW5nIHRoZSByZWNvcmQgdXNlCiAgIHRo ZSBzYW1lIGhhc2ggYWxnb3JpdGhtIHRoYXQgd2FzIHVzZWQgaW4gdGhlIHNpZ25hdHVyZSBpbiB0 aGUKICAgY2VydGlmaWNhdGUgKGlmIHBvc3NpYmxlKSB3aWxsIGFzc2lzdCBjbGllbnRzIHRoYXQg c3VwcG9ydCBhIHNtYWxsCiAgIG51bWJlciBvZiBoYXNoIGFsZ29yaXRobXMuCgoyLjEuNC4gIENl cnRpZmljYXRlIEFjY2VzcyBGaWVsZAoKICAgVGhpcyBvbmUgb2N0ZXQgdmFsdWUgaW5kaWNhdGVz IGFuIGFsdGVybmF0aXZlIG1ldGhvZCBmb3IgY2VydGlmaWNhdGUKICAgZGlzY292ZXJ5LiAgU29t ZSBkb21haW4gb3duZXJzIG1heSBub3Qgd2FudCB0byBwdWJsaXNoIHVzZXIKICAgY2VydGlmaWNh dGVzIHZpYSBETlMgYnV0IG1heSB3YW50IHRvIHVzZSB0aGUgRE5TIHRvIGFkdmVydGlzZSB0aGUK ICAgbWVhbnMgdG8gYWNjZXNzIHRoZW0uICBJZiBmdWxsIHVzZXIgY2VydGlmaWNhdGVzIGFyZSBu b3QgaW5jbHVkZWQgaW4KICAgdGhlIENlcnRpZmljYXRlIEFzc29jaWF0aW9uIERhdGEgdGhpcyBm aWVsZCBNQVkgYmUgdXNlZCB0byBpbmRpY2F0ZQogICBob3cgdGhlIHVzZXIncyBjZXJ0aWZpY2F0 ZSBjYW4gYmUgb2J0YWluZWQuICBUaGUgUkRBVEEgY2VydGlmaWNhdGUKCgoKSG9mZm1hbiwgZXQg YWwuICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDMsIDIwMTQgICAgICAgICAgICAgICAgIFtQYWdl IDddCgwKSW50ZXJuZXQtRHJhZnQgICAgIEROUy1CYXNlZCBBdXRoZW50aWNhdGlvbiBmb3IgUy9N SU1FICAgIFNlcHRlbWJlciAyMDEzCgoKICAgYXNzb2NpYXRpb24gZGF0YSBNVVNUIGJlIHVzZWQg dG8gdmFsaWRhdGUgY2VydGlmaWNhdGVzIG9idGFpbmVkIGJ5CiAgIHRoZSBhbHRlcm5hdGl2ZSBt ZXRob2QuCgogICAgICAwIG9yIE5POiBObyBhbHRlcm5hdGl2ZSBtZXRob2QgYWR2ZXJ0aXNlZC4K CiAgICAgIDEgb3IgTkFQVFIgOiBOQVBUUiByZWNvcmQgYXZhaWxhYmxlLiAgVGhlIHNhbWUgZG9t YWluIG5hbWUgdXNlZAogICAgICBmb3IgdGhpcyBTTUlNRUEgcmVxdWVzdCBNQVkgYmUgdXNlZCBh Z2FpbiB3aXRoIHR5cGUgTkFQVFIKICAgICAgW1JGQzM0MDNdIHRvIHJldHJpZXZlIHRoZSBVUkkg Zm9yIGNlcnRpZmljYXRlIGFjY2Vzcy4KCiAgICAgIDIgb3IgV0Y6IFguNTA5IGNlcnRpZmljYXRl cyBhdmFpbGFibGUgaW4gV2ViRmluZ2VyIFtSRkM3MDMzXS4KCjIuMS41LiAgVGhlIENlcnRpZmlj YXRlIEFzc29jaWF0aW9uIERhdGEgRmllbGQKCiAgIFRoaXMgZmllbGQgc3BlY2lmaWVzIHRoZSAi Y2VydGlmaWNhdGUgYXNzb2NpYXRpb24gZGF0YSIgdG8gYmUKICAgbWF0Y2hlZC4gIFRoZXNlIGJ5 dGVzIGFyZSBlaXRoZXIgcmF3IGRhdGEgKHRoYXQgaXMsIHRoZSBmdWxsCiAgIGNlcnRpZmljYXRl IG9yIGl0cyBTdWJqZWN0UHVibGljS2V5SW5mbywgZGVwZW5kaW5nIG9uIHRoZSBzZWxlY3RvcikK ICAgZm9yIG1hdGNoaW5nIHR5cGUgRnVsbCAoMCksIG9yIHRoZSBoYXNoIG9mIHRoZSByYXcgZGF0 YSBmb3IgbWF0Y2hpbmcKICAgdHlwZXMgU0hBMi0yNTYgKDEpIGFuZCBTSEEyLTUxMiAoMikuICBU aGUgZGF0YSByZWZlcnMgdG8gdGhlCiAgIGNlcnRpZmljYXRlIGluIHRoZSBhc3NvY2lhdGlvbiwg bm90IHRvIHRoZSBBU04uMSBDZXJ0aWZpY2F0ZSBvYmplY3QuCiAgIEZvciBjZXJ0aWZpY2F0ZSB1 c2FnZSB0eXBlIFJFSkVDVCAoNCkgYXQgbGVhc3Qgb25lIGJ5dGUgb2YgZGF0YSBpcwogICBSRVFV SVJFRCBidXQgdGhlIHZhbHVlIE1VU1QgYmUgaWdub3JlZC4KCjIuMi4gIFNNSU1FQSBSUiBQcmVz ZW50YXRpb24gRm9ybWF0CgogICBUaGUgcHJlc2VudGF0aW9uIGZvcm1hdCBvZiB0aGUgUkRBVEEg cG9ydGlvbiAoYXMgZGVmaW5lZCBpbgogICBbUkZDMTAzNV0pIGlzIGFzIGZvbGxvd3M6CgogICBv ICBUaGUgY2VydGlmaWNhdGUgdXNhZ2UgZmllbGQgTVVTVCBiZSByZXByZXNlbnRlZCBlaXRoZXIg YXMgYQogICAgICBjZXJ0aWZpY2F0ZSB1c2FnZSBtbmVtb25pYyBvciBhbiA4LWJpdCB1bnNpZ25l ZCBpbnRlZ2VyLgoKICAgbyAgVGhlIHNlbGVjdG9yIGZpZWxkIE1VU1QgYmUgcmVwcmVzZW50ZWQg ZWl0aGVyIGFzIGEgc2VsZWN0b3IgZmllbGQKICAgICAgbW5lbW9uaWMgb3IgYW4gOC1iaXQgdW5z aWduZWQgaW50ZWdlci4KCiAgIG8gIFRoZSBtYXRjaGluZyB0eXBlIGZpZWxkIE1VU1QgYmUgcmVw cmVzZW50ZWQgZWl0aGVyIGFzIGEgbWF0Y2hpbmcKICAgICAgdHlwZSBtbmVtb25pYyBvciBhbiA4 LWJpdCB1bnNpZ25lZCBpbnRlZ2VyLgoKICAgbyAgVGhlIGNlcnRpZmljYXRlIGFjY2VzcyBmaWVs ZCBNVVNUIGJlIHJlcHJlc2VudGVkIGVpdGhlciBhcyBhCiAgICAgIGNlcnRpZmljYXRlIGFjY2Vz cyBtbmVtb25pYyBvciBhbiA4LWJpdCB1bnNpZ25lZCBpbnRlZ2VyLgoKICAgbyAgVGhlIGNlcnRp ZmljYXRlIGFzc29jaWF0aW9uIGRhdGEgZmllbGQgTVVTVCBiZSByZXByZXNlbnRlZCBhcyBhCiAg ICAgIHN0cmluZyBvZiBoZXhhZGVjaW1hbCBjaGFyYWN0ZXJzLiAgV2hpdGVzcGFjZSBpcyBhbGxv d2VkIHdpdGhpbgogICAgICB0aGUgc3RyaW5nIG9mIGhleGFkZWNpbWFsIGNoYXJhY3RlcnMsIGFz IGRlc2NyaWJlZCBpbiBbUkZDMTAzNV0uCgogICBXaGVyZSBwcmFjdGljYWwsIHRoZSBtbmVtb25p YyBmb3JtIFNIT1VMRCBiZSB1c2VkIGluIG9yZGVyIHRvIHByb3ZpZGUKICAgY2xhcml0eS4KCgoK CgoKSG9mZm1hbiwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDMsIDIwMTQgICAgICAg ICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQgICAgIEROUy1CYXNlZCBBdXRoZW50 aWNhdGlvbiBmb3IgUy9NSU1FICAgIFNlcHRlbWJlciAyMDEzCgoKMi4zLiAgU01JTUVBIFJSIEV4 YW1wbGVzCgogICBJbiB0aGUgZm9sbG93aW5nIGV4YW1wbGVzLCB0aGUgZG9tYWluIG5hbWUgaXMg Zm9ybWVkIHVzaW5nIHRoZSBydWxlcwogICBpbiBTZWN0aW9uIDMuCgogICBBbiBleGFtcGxlIG9m IGEgaGFzaGVkIChTSEEyLTI1NikgYXNzb2NpYXRpb24gb2YgYSBGdWxsIFBLSVgtQ0EKICAgY2Vy dGlmaWNhdGUgaW4gdGhlIFBLSVggdmFsaWRhdGlvbiBwYXRoIG9mIGEgY2VydGlmaWNhdGUgdXNl ZCB0bwogICB2YWxpZGF0ZSBhIHNpZ25lZCBTL01JTUUgbWVzc2FnZS4gIE5vIGFsdGVybmF0aXZl IGNlcnRpZmljYXRlIGFjY2VzcwogICBpcyBhZHZlcnRpc2VkLgoKICAgICAgTUZXR1NZM0YuX3Np Z24uX3NtaW1lY2VydC5leGFtcGxlLmNvbS4gSU4gU01JTUVBICgKICAgICAgICAgMCAwIDEgMCBk MmFiZGUyNDBkN2NkM2VlNmI0YjI4YzU0ZGYwMzRiOQogICAgICAgICAgICAgICAgIDc5ODNhMWQx NmU4YTQxMGU0NTYxY2IxMDY2MThlOTcxICkKCiAgICBBbHRlcm5hdGl2ZWx5CgogICAgICBNRldH U1kzRi5fc2lnbi5fc21pbWVjZXJ0LmV4YW1wbGUuY29tLiBJTiBTTUlNRUEgKAogICAgICAgICBQ S0lYLUNBIEZVTEwgU0hBMi0yNTYgTk8gZDJhYmRlMjQwZDdjZDNlZTZiNGIyOGM1NGRmMDM0YjkK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDc5ODNhMWQxNmU4YTQxMGU0NTYxY2Ix MDY2MThlOTcxICkKCiAgIEFuIGV4YW1wbGUgcmVzb3VyY2UgcmVjb3JkIHByb3ZpZGluZyBGdWxs IHNlbGYtc2lnbmVkIGVuY3J5cHRpb24KICAgY2VydGlmaWNhdGU6CgogICAgICBNRldHU1kzRi5f ZW5jci5fc21pbWVjZXJ0LmV4YW1wbGUuY29tLiBJTiBTTUlNRUEgKAogICAgICAgICBEQU5FLUVF IENlcnQgRnVsbCBOTyAzMDgyMDMwNzMwODIwMWVmYTAwMzAyMDEwMjAyMC4uLiApCgogICBBbiBl eGFtcGxlIG9mIHJlc291cmNlIHJlY29yZCBpbnZhbGlkYXRpbmcgYWxsIGRpZ2l0YWwgc2lnbmF0 dXJlcyBieQogICBpZGVudGlmaWVkIHVzZXI6CgogICAgICBNTlVIS1kzTC5fc2lnbi5fc21pbWVj ZXJ0LmV4YW1wbGUuY29tLiBJTiBTTUlNRUEgKAogICAgICAgICAgICAgICAgICAgICAgICAgICAg UkVKRUNUIENlcnQgRnVsbCBOTyAwMCApCgozLiAgRG9tYWluIE5hbWVzIGZvciBTL01JTUUgQ2Vy dGlmaWNhdGUgQXNzb2NpYXRpb25zCgogICBTTUlNRUEgZG9tYWluIG5hbWVzIGluY2x1ZGUgZnVu Y3Rpb24gYW5kIHVzZXIgbGFiZWxzLiAgVGhlIHB1cnBvc2UgaXMKICAgdG8gaWRlbnRpZnkgdGhl IGZ1bmN0aW9uIHNwZWNpZmljIGNlcnRpZmljYXRlIGlmIGEgdXNlciBoYXMgbXVsdGlwbGUKICAg Y2VydGlmaWNhdGVzLiAgQWxpYXMgTUFZIGJlIHVzZWQgaWYgYSB1c2VyIGhhcyBhIGNvbW1vbiBj ZXJ0aWZpY2F0ZQogICBmb3IgYm90aCBmdW5jdGlvbnMKCjMuMS4gIERvbWFpbiBOYW1lIFByZXBh cmF0aW9uCgogICBEb21haW4gbmFtZXMgYXJlIHByZXBhcmVkIGZvciByZXF1ZXN0cyBpbiB0aGUg Zm9sbG93aW5nIG1hbm5lci4KCiAgIDEuICBUaGUgdXNlciBuYW1lICh0aGUgImxlZnQtaGFuZCBz aWRlIiBvZiB0aGUgZW1haWwgYWRkcmVzcywgY2FsbGVkCiAgICAgICB0aGUgImxvY2FsLXBhcnQi IGluIHRoZSBtYWlsIG1lc3NhZ2UgZm9ybWF0IGRlZmluaXRpb24gW1JGQzUzMjJdCiAgICAgICBh bmQgdGhlICJsb2NhbCBwYXJ0IiBpbiB0aGUgc3BlY2lmaWNhdGlvbiBmb3IgaW50ZXJuYXRpb25h bGl6ZWQKICAgICAgIGVtYWlsIFtSRkM2NTMwXSksIGlzIGVuY29kZWQgd2l0aCBCYXNlMzIgW1JG QzQ2NDhdLCB0byBiZWNvbWUgdGhlCiAgICAgICBsZWZ0LW1vc3QgbGFiZWwgaW4gdGhlIHByZXBh cmVkIGRvbWFpbiBuYW1lLiAgVGhpcyBkb2VzIG5vdAoKCgpIb2ZmbWFuLCBldCBhbC4gICAgICAg ICAgIEV4cGlyZXMgQXByaWwgMywgMjAxNCAgICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRl cm5ldC1EcmFmdCAgICAgRE5TLUJhc2VkIEF1dGhlbnRpY2F0aW9uIGZvciBTL01JTUUgICAgU2Vw dGVtYmVyIDIwMTMKCgogICAgICAgaW5jbHVkZSB0aGUgIkAiIGNoYXJhY3RlciB0aGF0IHNlcGFy YXRlcyB0aGUgbGVmdCBhbmQgcmlnaHQgc2lkZXMKICAgICAgIG9mIHRoZSBlbWFpbCBhZGRyZXNz LgoKICAgMi4gIFRoZSBzZWNvbmQgbGVmdC1tb3N0IGxhYmVsIGlzIHRoZSBmdW5jdGlvbiBzcGVj aWZpYyBsYWJlbAogICAgICAgc2VnbWVudC4gIEl0IGlzIHNlbGVjdGVkIGJhc2VkIG9uIHRoZSBT L01JTUUgZnVuY3Rpb24gdGhlIE1VQSBpcwogICAgICAgcGVyZm9ybWluZy4gIFZhbHVlcyBhcmU6 CgogICAgICAgICAgIl9lbmNyIiBmb3Igb2J0YWluaW5nIG9yIHZhbGlkYXRpbmcgYSBjZXJ0aWZp Y2F0ZSBvciBwdWJsaWMKICAgICAgICAgIGtleSB0byBiZSB1c2VkIHRvIGVuY3J5cHQgYSBtZXNz YWdlLgoKICAgICAgICAgICJfc2lnbiIgZm9yIGNlcnRpZmljYXRlIHZhbGlkYXRpb24gZGF0YSB0 byB2ZXJpZnkgYSBkaWdpdGFsCiAgICAgICAgICBzaWduYXR1cmUuCgogICAgICAgRm9yIGNlcnRp ZmljYXRlIHVzZSBjYXNlcyBYWFhYLUVFICgxIGFuZCAzKSB0aGUgZnVuY3Rpb24gc3BlY2lmaWMK ICAgICAgIGxhYmVsIFNIT1VMRCBiZSBjb25zaXN0ZW50IHdpdGggdGhlIEtleSBVc2FnZSBmaWVs ZCAoZGVmaW5lZCBpbgogICAgICAgc2VjdGlvbiA0LjIuMS4zIG9mIFtSRkM1MjgwXSkgb2YgdGhl IGFzc29jaWF0ZWQgY2VydGlmaWNhdGUuCgogICAzLiAgVGhlIHN0cmluZyAiX3NtaW1lY2VydCIg YmVjb21lcyB0aGUgdGhpcmQgbGVmdC1tb3N0IGxhYmVsIGluIHRoZQogICAgICAgcHJlcGFyZWQg ZG9tYWluLiAgVGhlIGZ1bmN0aW9uIHNwZWNpZmljIGxhYmVsIHNlZ21lbnQgaXMgc2VwYXJhdGUK ICAgICAgIHRvIGVuYWJsZSBkZWxlZ2F0aW9uIG9mIGEgc2luZ2xlIF9zbWltZWNlcnQgem9uZSBj dXQuCgogICA0LiAgVGhlIGRvbWFpbiBuYW1lICh0aGUgInJpZ2h0LWhhbmQgc2lkZSIgb2YgdGhl IGVtYWlsIGFkZHJlc3MsCiAgICAgICBjYWxsZWQgdGhlICJkb21haW4iIGluIFtSRkM1MzIyXSkg aXMgYXBwZW5kZWQgdG8gdGhlIHJlc3VsdCBvZgogICAgICAgc3RlcCAzIHRvIGNvbXBsZXRlIHRo ZSBwcmVwYXJlZCBkb21haW4gbmFtZS4KCiAgIERlc2lnbiBub3RlOiBFbmNvZGluZyB0aGUgdXNl ciBuYW1lIHdpdGggQmFzZTMyIGFsbG93cyBsb2NhbCBwYXJ0cwogICB0aGF0IGhhdmUgY2hhcmFj dGVycyB0aGF0IHdvdWxkIHByZXZlbnQgdGhlaXIgdXNlIGluIGRvbWFpbiBuYW1lcy4KICAgRm9y IGV4YW1wbGUsIGEgcGVyaW9kICgiLiIpIGlzIGEgdmFsaWQgY2hhcmFjdGVyIGluIGEgbG9jYWwg cGFydCwgYnV0CiAgIHdvdWxkIHdyZWFrIGhhdm9jIGluIGEgZG9tYWluIG5hbWUuICBTaW1pbGFy bHksIFJGQyA2NTMwIGFsbG93cyBub24tCiAgIEFTQ0lJIGNoYXJhY3RlcnMgaW4gbG9jYWwgcGFy dHMsIGFuZCBlbmNvZGluZyBhIGxvY2FsIHBhcnQgd2l0aCBub24tCiAgIEFTQ0lJIGNoYXJhY3Rl cnMgd2l0aCBCYXNlMzIgcmVuZGVycyB0aGUgbmFtZSB1c2FibGUgaW4gdGhlIEROUy4KICAgQmFz ZTMyIGVuY29kaW5nIGlzIGNhc2Ugc2Vuc2l0aXZlIHNvICJhbGljZSIgZW5jb2RlcyB0byAiTUZX R1NZM0YiCiAgIHdoZXJlYXMgIkFsaWNlIiBlbmNvZGVzIHRvICJJRldHU1kzRiIuICBDb21wbGlh bnQgTVVBcyBTSE9VTEQgYmUKICAgYXdhcmUgdGhhdCB1c2VyLXByb3ZpZGVkIGFkZHJlc3NlcyBt aWdodCBub3QgbWF0Y2ggdGhlIGNhc2Ugb2YgdGhlaXIKICAgaW50ZW5kZWQgcmVjaXBpZW50J3Mg dHJ1ZSBhZGRyZXNzLgoKMy4yLiAgRG9tYWluIE5hbWUgRXhhbXBsZXMKCiAgIEV4YW1wbGUgMS4g IFNpZ25hdHVyZSBjZXJ0aWZpY2F0ZSB2ZXJpZmljYXRpb246IHRvIHJlcXVlc3QgYW4gU01JTUVB CiAgIHJlc291cmNlIHJlY29yZCB0byB2ZXJpZnkgYSBzaWduYXR1cmUgY2VydGlmaWNhdGUgZm9y IGEgdXNlciB3aG9zZQogICBhZGRyZXNzIGlzICJhbGljZUBleGFtcGxlLmNvbSIsIHlvdSB3b3Vs ZCB1c2U6CgogICAgICAgICAgICAiTUZXR1NZM0YuX3NpZ24uX3NtaW1lY2VydC5leGFtcGxlLmNv bSIKCgoKCgoKCgpIb2ZmbWFuLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXByaWwgMywgMjAx NCAgICAgICAgICAgICAgICBbUGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgRE5TLUJhc2Vk IEF1dGhlbnRpY2F0aW9uIGZvciBTL01JTUUgICAgU2VwdGVtYmVyIDIwMTMKCgogICBFeGFtcGxl IDIuICBFbmNyeXB0aW9uIGtleSBkaXNjb3Zlcnk6IHRvIHJlcXVlc3QgYW4gU01JTUVBIHJlc291 cmNlCiAgIHJlY29yZCBmb3IgZW5jcnlwdGluZyBhbiBlbWFpbCB0byB1c2VyICJib2JAZXhhbXBs ZS5jb20iIHlvdSB3b3VsZAogICB1c2U6CgogICAgICAgICAgICAiTUpYV0U9PT0uX2VuY3IuX3Nt aW1lY2VydC5leGFtcGxlLmNvbSIKCjQuICBVc2Ugb2YgU01JTUVBIFJlY29yZHMgaW4gU01JTUUK CiAgIFNNSU1FQSByZWNvcmRzIGFyZSB1c2VkIHRvIHB1Ymxpc2ggdXNlciBjZXJ0aWZpY2F0ZXMg b3IgdmFsaWRhdGUgdXNlcgogICBjZXJ0aWZpY2F0ZXMgYWNxdWlyZWQgYnkgb3RoZXIgbWVhbnMu ICBUeXBpY2FsbHkgdGhlc2UgdXNlIGNhc2VzIGFyZQogICBhc3NvY2lhdGVkIHdpdGggbWVzc2Fn ZSBlbmNyeXB0aW9uIGFuZCBzaWduYXR1cmUgdmFsaWRhdGlvbiBwcm9jZXNzZXMKICAgcmVzcGVj dGl2ZWx5LiAgU2VjdGlvbiAyLjEgb2YgdGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBtYW5kYXRv cnkKICAgbWF0Y2hpbmcgcnVsZXMgZm9yIHRoZSBkYXRhLiAgV2hlcmUgcG9zc2libGUsIGNvbnNp c3RlbmN5IHdpdGgKICAgW1JGQzY2OThdIGlzIG1haW50YWluZWQuCgo0LjEuICBVc2FibGUgQ2Vy dGlmaWNhdGUgQXNzb2NpYXRpb25zCgogICBBbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGlzIHByb3Rv Y29sIG1ha2VzIGEgRE5TIHF1ZXJ5IGZvciBTTUlNRUEKICAgcmVjb3JkcywgdmFsaWRhdGVzIHRo ZXNlIHJlY29yZHMgdXNpbmcgRE5TU0VDLCBhbmQgdXNlcyB0aGUgcmVzdWx0aW5nCiAgIFNNSU1F QSByZWNvcmRzIGFuZCB2YWxpZGF0aW9uIHRvIG1vZGlmeSBTL01JTUUgbWVzc2FnZSBwcm9jZXNz aW5nCiAgIGJlaGF2aW9yLgoKICAgRGV0ZXJtaW5pbmcgd2hldGhlciBhbiBTTUlNRUEgUlJTZXQg Y2FuIGJlIHVzZWQgTVVTVCBiZSBiYXNlZCBvbiB0aGUKICAgRE5TU0VDIHZhbGlkYXRpb24gc3Rh dGUgKGFzIGRlZmluZWQgaW4gW1JGQzQwMzVdKS4KCiAgIG8gIEFuIFNNSU1FQSBSUlNldCB3aG9z ZSBETlNTRUMgdmFsaWRhdGlvbiBzdGF0ZSBpcyBzZWN1cmUgTVVTVCBiZQogICAgICB1c2VkIGFz IGEgY2VydGlmaWNhdGUgYXNzb2NpYXRpb24gZm9yIFMvTUlNRSB1bmxlc3MgYSBsb2NhbCBwb2xp Y3kKICAgICAgd291bGQgcHJvaGliaXQgdGhlIHVzZSBvZiB0aGUgc3BlY2lmaWMgY2VydGlmaWNh dGUgYXNzb2NpYXRpb24gaW4KICAgICAgdGhlIHNlY3VyZSBTTUlNRUEgUlJTZXQuCgogICBvICBJ ZiB0aGUgRE5TU0VDIHZhbGlkYXRpb24gc3RhdGUgb24gdGhlIHJlc3BvbnNlIHRvIHRoZSByZXF1 ZXN0IGZvcgogICAgICB0aGUgU01JTUVBIFJSU2V0IGlzIGJvZ3VzIHRoZW4gdGhlIFJSU2V0IE1V U1QgYmUgZGlzcmVnYXJkZWQgYW5kCiAgICAgIGNvbnNpZGVyZWQgdW51c2FibGUuICBBZGRpdGlv bmFsIFNNSU1FQSBxdWVyaWVzIG1heSBiZSBpbml0aWF0ZWQuCgogICBvICBJZiB0aGUgRE5TU0VD IHZhbGlkYXRpb24gc3RhdGUgaXMgaW5kZXRlcm1pbmF0ZSBvciBpbnNlY3VyZSB0aGVuCiAgICAg IHRoZSBTTUlNRUEgUlJTZXQgTVVTVCBiZSBkaXNyZWdhcmRlZCBhbmQgY29uc2lkZXJlZCB1bnVz YWJsZS4KCiAgIE1VQXMgdGhhdCByZWx5IG9uIGFub3RoZXIgZW50aXR5IHRvIHBlcmZvcm0gdGhl IEROU1NFQyBzaWduYXR1cmUKICAgdmFsaWRhdGlvbiBTSE9VTEQgdXNlIGEgc2VjdXJlIG1lY2hh bmlzbSBiZXR3ZWVuIHRoZW1zZWx2ZXMgYW5kIHRoZQogICB2YWxpZGF0b3IuICBFeGFtcGxlcyBv ZiBzZWN1cmUgdHJhbnNwb3J0cyB0byBvdGhlciBob3N0cyBpbmNsdWRlIFRTSUcKICAgW1JGQzI4 NDVdLCBTSUcoMCkgW1JGQzI5MzFdLCBhbmQgSVBzZWMgW1JGQzYwNzFdLiAgTm90ZSB0aGF0IGl0 IGlzCiAgIG5vdCBzdWZmaWNpZW50IHRvIHVzZSBzZWN1cmUgdHJhbnNwb3J0IHRvIGEgRE5TIHJl c29sdmVyIHRoYXQgZG9lcwogICBub3QgZG8gRE5TU0VDIHNpZ25hdHVyZSB2YWxpZGF0aW9uLgoK ICAgSWYgYSBjZXJ0aWZpY2F0ZSBhc3NvY2lhdGlvbiBjb250YWlucyBhIGNlcnRpZmljYXRlIHVz YWdlLCBzZWxlY3RvciwKICAgb3IgbWF0Y2hpbmcgdHlwZSB0aGF0IGlzIG5vdCB1bmRlcnN0b29k IGJ5IHRoZSBNVUEsIHRoYXQgY2VydGlmaWNhdGUKICAgYXNzb2NpYXRpb24gTVVTVCBiZSBjb25z aWRlcmVkIHVudXNhYmxlLiAgSWYgdGhlIGNvbXBhcmlzb24gZGF0YSBmb3IKICAgYSBjZXJ0aWZp Y2F0ZSBpcyBtYWxmb3JtZWQsIHRoZSBjZXJ0aWZpY2F0ZSBhc3NvY2lhdGlvbiBNVVNUIGJlCgoK CkhvZmZtYW4sIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAzLCAyMDE0ICAgICAgICAg ICAgICAgIFtQYWdlIDExXQoMCkludGVybmV0LURyYWZ0ICAgICBETlMtQmFzZWQgQXV0aGVudGlj YXRpb24gZm9yIFMvTUlNRSAgICBTZXB0ZW1iZXIgMjAxMwoKCiAgIGNvbnNpZGVyZWQgdW51c2Fi bGUuCgogICBJZiBhIGNlcnRpZmljYXRlIGFzc29jaWF0aW9uIGNvbnRhaW5zIGEgbWF0Y2hpbmcg dHlwZSBvciBjZXJ0aWZpY2F0ZQogICBhc3NvY2lhdGlvbiBkYXRhIHRoYXQgdXNlcyBhIGNyeXB0 b2dyYXBoaWMgYWxnb3JpdGhtIHRoYXQgaXMKICAgY29uc2lkZXJlZCB0b28gd2VhayBmb3IgdGhl IE1VQSdzIGxvY2FsIHBvbGljeSwgdGhlIGNlcnRpZmljYXRlCiAgIGFzc29jaWF0aW9uIE1VU1Qg YmUgY29uc2lkZXJlZCB1bnVzYWJsZS4KCiAgIElmIGEgTVVBIHJlY2VpdmVzIHplcm8gdXNhYmxl IGNlcnRpZmljYXRlIGFzc29jaWF0aW9ucyBmcm9tIGEgRE5TCiAgIHJlcXVlc3Qgb3IgZnJvbSBp dHMgY2FjaGUsIGl0IHByb2Nlc3NlcyBTL01JTUUgcmVxdWVzdHMgaW4gdGhlIG5vcm1hbAogICBm YXNoaW9uIHdpdGhvdXQgYW55IGlucHV0IGZyb20gdGhlIFNNSU1FQSByZWNvcmRzLgoKICAgSWYg YSBNVUEgcGVyZm9ybWluZyBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uIHJlY2VpdmVzIG9uZSBvciBt b3JlCiAgIHVzYWJsZSBjZXJ0aWZpY2F0ZSBhc3NvY2lhdGlvbnMgdGhlbiBpdCBNVVNUIGF0dGVt cHQgdG8gbWF0Y2ggZWFjaAogICBjZXJ0aWZpY2F0ZSBhc3NvY2lhdGlvbiB3aXRoIHRoZSB1c2Vy J3MgY2VydGlmaWNhdGUgdW50aWwgYQogICBzdWNjZXNzZnVsIG1hdGNoIGlzIGZvdW5kLiAgSWYg bm8gY2VydGlmaWNhdGUgYXNzb2NpYXRpb25zIG1hdGNoIHRoZW4KICAgdGhlIGNlcnRpZmljYXRl IE1VU1QgYmUgY29uc2lkZXJlZCBpbnZhbGlkLgoKICAgSWYgYSBNVUEgbWFrZXMgYW4gU01JTUVB IHJlcXVlc3QgZm9yIGFuIGVuY3J5cHRpb24gY2VydGlmaWNhdGUgYW5kCiAgIHRoZSByZXNwb25z ZSBpbmNsdWRlcyBtb3JlIHRoYW4gb25lIHZhbGlkIGNlcnRpZmljYXRlLCB0aGUKICAgY2VydGlm aWNhdGUgd2l0aCB0aGUgbW9zdCByZWNlbnQgIk5vdCBCZWZvcmUiIGRhdGEgU0hPVUxEIGJlCiAg IHNlbGVjdGVkLiBbIEFyZSB0aGVyZSBiZXR0ZXIgY3JpdGVyaWE/IF0KCjUuICBNYW5kYXRvcnkt dG8tSW1wbGVtZW50IEZlYXR1cmVzCgogICBTL01JTUUgTVVBcyBjb25mb3JtaW5nIHRvIHRoaXMg c3BlY2lmaWNhdGlvbiBNVVNUIGJlIGFibGUgdG8KICAgY29ycmVjdGx5IGludGVycHJldCBTTUlN RUEgcmVjb3JkcyB3aXRoIGNlcnRpZmljYXRlIHVzYWdlcyBQS0lYLUNBLAogICBQS0lYLUVFLCBE QU5FLVRBLCBEQU5FLUVFIGFuZCBSRUpFQ1QuICBTL01JTUUgTVVBcyBjb25mb3JtaW5nIHRvIHRo aXMKICAgc3BlY2lmaWNhdGlvbiBNVVNUIGJlIGFibGUgdG8gY29tcGFyZSBhIGNlcnRpZmljYXRl IGFzc29jaWF0aW9uIHdpdGgKICAgYSBjZXJ0aWZpY2F0ZSBvZmZlcmVkIGJ5IGFub3RoZXIgUy9N SU1FIE1VQSB1c2luZyBzZWxlY3RvciB0eXBlcyBGVUxMCiAgIGFuZCBTUEtJLCBhbmQgbWF0Y2hp bmcgdHlwZSBGVUxMIChubyBoYXNoIHVzZWQpIGFuZCBtYXRjaGluZyB0eXBlCiAgIFNIQTItMjU2 LCBhbmQgU0hPVUxEIGJlIGFibGUgdG8gbWFrZSBzdWNoIGNvbXBhcmlzb25zIHdpdGggbWF0Y2hp bmcKICAgdHlwZSBTSEEyLTUxMi4KCjYuICBJQU5BIENvbnNpZGVyYXRpb25zCgo2LjEuICBTTUlN RUEgUlJ0eXBlCgogICBUaGlzIGRvY3VtZW50IHVzZXMgYSBuZXcgRE5TIFJSIHR5cGUsIFNNSU1F QSwgd2hvc2UgdmFsdWUgd2lsbCBiZQogICBhbGxvY2F0ZWQgYnkgSUFOQSBmcm9tIHRoZSBSZXNv dXJjZSBSZWNvcmQgKFJSKSBUWVBFcyBzdWJyZWdpc3RyeSBvZgogICB0aGUgRG9tYWluIE5hbWUg U3lzdGVtIChETlMpIFBhcmFtZXRlcnMgcmVnaXN0cnkuCgoKCgoKCgoKCgoKSG9mZm1hbiwgZXQg YWwuICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDMsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2Ug MTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgIEROUy1CYXNlZCBBdXRoZW50aWNhdGlvbiBmb3IgUy9N SU1FICAgIFNlcHRlbWJlciAyMDEzCgoKNi4yLiAgU01JTUVBIENlcnRpZmljYXRlIFVzYWdlIFJl Z2lzdHJ5CgogICBUaGlzIGRvY3VtZW50IGNyZWF0ZXMgYSBuZXcgcmVnaXN0cnksICJTTUlNRUEg Q2VydGlmaWNhdGUgVXNhZ2VzIi4KICAgVGhlIHJlZ2lzdHJ5IHBvbGljeSBpcyAiUkZDIFJlcXVp cmVkIi4gIFRoZSBpbml0aWFsIGVudHJpZXMgaW4gdGhlCiAgIHJlZ2lzdHJ5IGFyZToKCiAgICAg Ky0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tKwogICAgIHwgVmFsdWUgfCBNbmVtb25pYyB8IFNob3J0IERlc2NyaXB0aW9uICAg ICAgICAgICAgICB8IFJlZmVyZW5jZSAgIHwKICAgICArLS0tLS0tLSstLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rCiAgICAgfCAgIDAgICB8 IFBLSVgtQ0EgIHwgQ0EgICAgICBjb25zdHJhaW50ICAgICAgICAgICAgIHwgW3RoaXMgZG9jXSAg fAogICAgIHwgICAxICAgfCBQS0lYLUVFICB8IFNlcnZpY2UgY2VydGlmaWNhdGUgY29uc3RyYWlu dCB8IFt0aGlzIGRvY10gIHwKICAgICB8ICAgMiAgIHwgREFORS1UQSAgfCBUcnVzdCBhbmNob3Ig YXNzZXJ0aW9uICAgICAgICAgfCBbdGhpcyBkb2NdICB8CiAgICAgfCAgIDMgICB8IERBTkUtRUUg IHwgRG9tYWluLWlzc3VlZCBjZXJ0aWZpY2F0ZSAgICAgIHwgW3RoaXMgZG9jXSAgfAogICAgIHwg ICA0ICAgfCBSRUpFQ1QgICB8IEludmFsaWQgQ2VydGlmaWNhdGUgb3IgVXNlciAgICB8IFt0aGlz IGRvY10gIHwKICAgICB8IDUtMjU0IHwgICAgICAgICAgfCBVbmFzc2lnbmVkICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICB8CiAgICAgfCAgMjU1ICB8IFByaXZDZXJ0IHwgUmVzZXJ2 ZWQgZm9yIFByaXZhdGUgVXNlICAgICAgIHwgW3RoaXMgZG9jXSAgfAogICAgICstLS0tLS0tKy0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSsK CgogICBBcHBsaWNhdGlvbnMgdG8gdGhlIHJlZ2lzdHJ5IGNhbiByZXF1ZXN0IHNwZWNpZmljIHZh bHVlcyB0aGF0IGhhdmUKICAgeWV0IHRvIGJlIGFzc2lnbmVkLgoKNi4zLiAgU01JTUVBIFNlbGVj dG9ycwoKICAgVGhpcyBkb2N1bWVudCBjcmVhdGVzIGEgbmV3IHJlZ2lzdHJ5LCAiVExTQSBTZWxl Y3RvcnMiLiAgVGhlIHJlZ2lzdHJ5CiAgIHBvbGljeSBpcyAiU3BlY2lmaWNhdGlvbiBSZXF1aXJl ZCIuICBUaGUgaW5pdGlhbCBlbnRyaWVzIGluIHRoZQogICByZWdpc3RyeSBhcmU6CgogICAgICAg ICAgKy0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tKwogICAgICAgICAgfCBWYWx1ZSB8IE1uZW1vbmljIHwgU2hvcnQgRGVzY3JpcHRpb24g ICAgICAgIHwgUmVmZXJlbmNlICAgfAogICAgICAgICAgKy0tLS0tLS0rLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKwogICAgICAgICAgfCAgIDAgICB8 IENlcnQgICAgIHwgRnVsbCBjZXJ0aWZpY2F0ZSAgICAgICAgIHwgW3RoaXMgZG9jXSAgfAogICAg ICAgICAgfCAgIDEgICB8IFNQS0kgICAgIHwgU3ViamVjdFB1YmxpY0tleUluZm8gICAgIHwgW3Ro aXMgZG9jXSAgfAogICAgICAgICAgfCAyLTI1NCB8ICAgICAgICAgIHwgVW5hc3NpZ25lZCAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgfAogICAgICAgICAgfCAgMjU1ICB8IFByaXZTZWwgIHwg UmVzZXJ2ZWQgZm9yIFByaXZhdGUgVXNlIHwgW3RoaXMgZG9jXSAgfAogICAgICAgICAgKy0tLS0t LS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKwoK CiAgIEFwcGxpY2F0aW9ucyB0byB0aGUgcmVnaXN0cnkgY2FuIHJlcXVlc3Qgc3BlY2lmaWMgdmFs dWVzIHRoYXQgaGF2ZQogICB5ZXQgdG8gYmUgYXNzaWduZWQuCgoKCgoKCgoKCgoKSG9mZm1hbiwg ZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDMsIDIwMTQgICAgICAgICAgICAgICAgW1Bh Z2UgMTNdCgwKSW50ZXJuZXQtRHJhZnQgICAgIEROUy1CYXNlZCBBdXRoZW50aWNhdGlvbiBmb3Ig Uy9NSU1FICAgIFNlcHRlbWJlciAyMDEzCgoKNi40LiAgU01JTUVBIE1hdGNoaW5nIFR5cGVzCgog ICBUaGlzIGRvY3VtZW50IGNyZWF0ZXMgYSBuZXcgcmVnaXN0cnksICJTTUlNRUEgTWF0Y2hpbmcg VHlwZXMiLiAgVGhlCiAgIHJlZ2lzdHJ5IHBvbGljeSBpcyAiU3BlY2lmaWNhdGlvbiBSZXF1aXJl ZCIuICBUaGUgaW5pdGlhbCBlbnRyaWVzIGluCiAgIHRoZSByZWdpc3RyeSBhcmU6CgogICAgICAg ICArLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tKwogICAgICAgICB8IFZhbHVlIHwgTW5lbW9uaWMgIHwgU2hvcnQgRGVzY3JpcHRpb24g ICAgICAgIHwgUmVmZXJlbmNlICAgfAogICAgICAgICArLS0tLS0tLSstLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKwogICAgICAgICB8ICAgMCAgIHwg RnVsbCAgICAgIHwgTm8gaGFzaCB1c2VkICAgICAgICAgICAgIHwgW3RoaXMgZG9jXSAgfAogICAg ICAgICB8ICAgMSAgIHwgU0hBMi0yNTYgIHwgMjU2IGJpdCBoYXNoIGJ5IFNIQTIgICAgIHwgW3Ro aXMgZG9jXSAgfAogICAgICAgICB8ICAgMiAgIHwgU0hBMi01MTIgIHwgNTEyIGJpdCBoYXNoIGJ5 IFNIQTIgICAgIHwgW3RoaXMgZG9jXSAgfAogICAgICAgICB8IDMtMjU0IHwgICAgICAgICAgIHwg VW5hc3NpZ25lZCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfAogICAgICAgICB8ICAyNTUg IHwgUHJpdk1hdGNoIHwgUmVzZXJ2ZWQgZm9yIFByaXZhdGUgVXNlIHwgW3RoaXMgZG9jXSAgfAog ICAgICAgICArLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tKwoKCiAgIEFwcGxpY2F0aW9ucyB0byB0aGUgcmVnaXN0cnkgY2FuIHJlcXVl c3Qgc3BlY2lmaWMgdmFsdWVzIHRoYXQgaGF2ZQogICB5ZXQgdG8gYmUgYXNzaWduZWQuCgo2LjUu ICBDZXJ0aWZpY2F0ZSBBY2Nlc3MgRmllbGQKCiAgIFRoaXMgZG9jdW1lbnQgY3JlYXRlcyBhIG5l dyByZWdpc3RyeSwgIlNNSU1FQSBDZXJ0aWZpY2F0ZSBBY2Nlc3MiLgogICBUaGUgcmVnaXN0cnkg cG9saWN5IGlzICJTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIi4gIFRoZSBpbml0aWFsIGVudHJpZXMK ICAgaW4gdGhlIHJlZ2lzdHJ5IGFyZToKCiAgICAgICAgICstLS0tLS0tKy0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKwogICAgICAgICB8IFZhbHVl IHwgTW5lbW9uaWMgIHwgU2hvcnQgRGVzY3JpcHRpb24gICAgICAgICB8IFJlZmVyZW5jZSAgIHwK ICAgICAgICAgKy0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0rCiAgICAgICAgIHwgICAwICAgfCBOTyAgICAgICAgfCBObyBBbHRlcm5h dGl2ZSBBZHZlcnRpc2VkIHwgW3RoaXMgZG9jXSAgfAogICAgICAgICB8ICAgMSAgIHwgTkFQVFIg ICAgIHwgTkFQVFIgICAgICAgICAgICAgICAgICAgICB8IFt0aGlzIGRvY10gIHwKICAgICAgICAg fCAgIDIgICB8IFdGICAgICAgICB8IFdlYkZpbmdlciAgICAgICAgICAgICAgICAgfCBbdGhpcyBk b2NdICB8CiAgICAgICAgIHwgMy0yNTQgfCAgICAgICAgICAgfCBVbmFzc2lnbmVkICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgfAogICAgICAgICB8ICAyNTUgIHwgUHJpdlVzZSAgIHwgUmVz ZXJ2ZWQgZm9yIFByaXZhdGUgVXNlICB8IFt0aGlzIGRvY10gIHwKICAgICAgICAgKy0tLS0tLS0r LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rCgoK ICAgQXBwbGljYXRpb25zIHRvIHRoZSByZWdpc3RyeSBjYW4gcmVxdWVzdCBzcGVjaWZpYyB2YWx1 ZXMgdGhhdCBoYXZlCiAgIHlldCB0byBiZSBhc3NpZ25lZC4KCjcuICBTZWN1cml0eSBDb25zaWRl cmF0aW9ucwoKICAgRE5TIHpvbmVzIHRoYXQgYXJlIHNpZ25lZCB3aXRoIEROU1NFQyB1c2luZyBO U0VDIGZvciBkZW5pYWwgb2YKICAgZXhpc3RlbmNlIGFyZSBzdXNjZXB0aWJsZSB0byB6b25lLXdh bGtpbmcsIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3cKICAgc29tZW9uZSB0byBlbnVtZXJhdGUgYWxs IHRoZSBuYW1lcyBpbiB0aGUgem9uZS4gIFNvbWVvbmUgd2hvIHdhbnRlZAogICB0byBjb2xsZWN0 IGVtYWlsIGFkZHJlc3NlcyBmcm9tIGEgem9uZSB0aGF0IHVzZXMgU01JTUVBIG1pZ2h0IHVzZQog ICBzdWNoIGEgbWVjaGFuaXNtLiAgRE5TU0VDLXNpZ25lZCB6b25lcyB1c2luZyBOU0VDMyBmb3Ig ZGVuaWFsIG9mCiAgIGV4aXN0ZW5jZSBhcmUgc2lnbmlmaWNhbnRseSBsZXNzIHN1c2NlcHRpYmxl IHRvIHpvbmUtd2Fsa2luZy4KCgoKSG9mZm1hbiwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEFw cmlsIDMsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgMTRdCgwKSW50ZXJuZXQtRHJhZnQgICAg IEROUy1CYXNlZCBBdXRoZW50aWNhdGlvbiBmb3IgUy9NSU1FICAgIFNlcHRlbWJlciAyMDEzCgoK ICAgU29tZW9uZSBjb3VsZCBzdGlsbCBhdHRlbXB0IGEgZGljdGlvbmFyeSBhdHRhY2sgb24gdGhl IHpvbmUgdG8gZmluZAogICBTTUlNRUEgcmVjb3JkcywganVzdCBhcyB0aGV5IGNhbiB1c2UgZGlj dGlvbmFyeSBhdHRhY2tzIG9uIGFuIFNNVFAKICAgc2VydmVyIHRvIHNlZSB3aGljaCBhZGRyZXNz ZXMgYXJlIHZhbGlkLgoKICAgQ2xpZW50IHRyZWF0bWVudCBvZiBhbnkgaW5mb3JtYXRpb24gaW5j bHVkZWQgaW4gdGhlIHRydXN0IGFuY2hvciBpcyBhCiAgIG1hdHRlciBvZiBsb2NhbCBwb2xpY3ku ICBUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFuZGF0ZSB0aGF0CiAgIHN1Y2ggaW5mb3Jt YXRpb24gYmUgaW5zcGVjdGVkIG9yIHZhbGlkYXRlZCBieSB0aGUgZG9tYWluIG5hbWUKICAgYWRt aW5pc3RyYXRvci4KCiAgIFNNSU1FL0Egc2lnbmVkIGRhdGEgaXMgY3VycmVudGx5IHN1YmplY3Qg dG8gZG93bmdyYWRlIGF0dGFjayBieQogICBzaW1wbHkgcmVtb3ZpbmcgdGhlIFNNSU1FIHdyYXBw ZXIuICBUZWNobmlxdWVzIGZvciBhIGRvbWFpbiBvd25lciB0bwogICBhc3NlcnQgcmVxdWlyZWQg dXNhZ2Ugb2YgUy9NSU1FIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KCjgu ICBBY2tub3dsZWRnZW1lbnRzCgogICBNaWVrIEdpZWJlbiwgTWFydGluIFBlbHMgYW5kIFRvZGQg TGFyc2VuIGNvbnRyaWJ1dGVkIHRlY2huaWNhbCBpZGVhcwogICBhbmQgc3VwcG9ydCB0byB0aGlz IGRvY3VtZW50LgoKOS4gIFJlZmVyZW5jZXMKCjkuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgog ICBbSS1ELmRyYWZ0LWlldGYtZGFuZS1yZWdpc3RyeS1hY3Jvbnltc10gIEd1ZG11bmRzc29uLCBP LiwgIkFkZGluZwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFj cm9ueW1zIHRvIHNpbXBsaWZ5IERBTkUKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBjb252ZXJzYXRpb25zIiwgZHJhZnQtaWV0Zi0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBkYW5lLXJlZ2lzdHJ5LWFjcm9ueW1zLTAwCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHdvcmsgaW4gcHJvZ3Jlc3Mp LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNlcHRlbWJlciAy MDEzLgoKICAgW0lUVS5YNjkwLjIwMDJdICAgICAgICAgICAgICAgICAgICAgICAgICBJbnRlcm5h dGlvbmFsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGVsZWNv bW11bmljYXRpb25zIFVuaW9uLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICJJbmZvcm1hdGlvbiBUZWNobm9sb2d5IC0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBBU04uMSBlbmNvZGluZyBydWxlczoKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIG9mIEJhc2ljCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRW5jb2RpbmcgUnVsZXMgKEJF UiksCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2Fub25pY2Fs IEVuY29kaW5nIFJ1bGVzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKENFUikgYW5kIERpc3Rpbmd1aXNoZWQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBFbmNvZGluZyBSdWxlcyAoREVSKSIsIElUVS0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUIFJlY29tbWVuZGF0aW9uIFguNjkwLAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bHkgMjAwMi4KCiAgIFtS RkMxMDM1XSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTW9ja2FwZXRyaXMsIFAuLCAi RG9tYWluCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmFtZXMg LSBpbXBsZW1lbnRhdGlvbiBhbmQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBzcGVjaWZpY2F0aW9uIiwgU1REIDEzLAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFJGQyAxMDM1LCBOb3ZlbWJlciAxOTg3LgoKICAgW1JGQzIxMTld ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBm b3IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1c2UgaW4gUkZD cyB0byBJbmRpY2F0ZQoKCgpIb2ZmbWFuLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXByaWwg MywgMjAxNCAgICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgRE5T LUJhc2VkIEF1dGhlbnRpY2F0aW9uIGZvciBTL01JTUUgICAgU2VwdGVtYmVyIDIwMTMKCgogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVs cyIsIEJDUCAxNCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBS RkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIFtSRkM0MDMzXSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQXJlbmRzLCBSLiwgQXVzdGVpbiwgUi4sCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgTGFyc29uLCBNLiwgTWFzc2V5LCBELiwgYW5kCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUy4gUm9zZSwgIkROUyBTZWN1cml0 eQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEludHJvZHVjdGlv biBhbmQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXF1aXJl bWVudHMiLCBSRkMgNDAzMywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBNYXJjaCAyMDA1LgoKICAgW1JGQzQwMzRdICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBcmVuZHMsIFIuLCBBdXN0ZWluLCBSLiwKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBMYXJzb24sIE0uLCBNYXNzZXksIEQuLCBhbmQKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTLiBSb3NlLCAiUmVzb3VyY2UgUmVjb3Jk cwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvciB0aGUgRE5T IFNlY3VyaXR5CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRXh0 ZW5zaW9ucyIsIFJGQyA0MDM0LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE1hcmNoIDIwMDUuCgogICBbUkZDNDAzNV0gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEFyZW5kcywgUi4sIEF1c3RlaW4sIFIuLAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIExhcnNvbiwgTS4sIE1hc3NleSwgRC4sIGFuZAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFMuIFJvc2UsICJQcm90b2NvbAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1vZGlmaWNhdGlvbnMgZm9y IHRoZSBETlMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTZWN1 cml0eSBFeHRlbnNpb25zIiwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBSRkMgNDAzNSwgTWFyY2ggMjAwNS4KCiAgIFtSRkM0NjQ4XSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgSm9zZWZzc29uLCBTLiwgIlRoZSBCYXNlMTYsCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmFzZTMyLCBhbmQgQmFzZTY0IERhdGEKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFbmNvZGluZ3MiLCBSRkMg NDY0OCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPY3RvYmVy IDIwMDYuCgogICBbUkZDNTI4MF0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENvb3Bl ciwgRC4sIFNhbnRlc3NvbiwgUy4sCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgRmFycmVsbCwgUy4sIEJvZXllbiwgUy4sCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgSG91c2xleSwgUi4sIGFuZCBXLiBQb2xrLAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJJbnRlcm5ldCBYLjUwOSBQdWJsaWMg S2V5CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSW5mcmFzdHJ1 Y3R1cmUgQ2VydGlmaWNhdGUKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBhbmQgQ2VydGlmaWNhdGUgUmV2b2NhdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIExpc3QgKENSTCkgUHJvZmlsZSIsCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgUkZDIDUyODAsIE1heSAyMDA4LgoKICAgW1JGQzU3 NTFdICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSYW1zZGVsbCwgQi4gYW5kIFMuIFR1 cm5lciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiU2VjdXJl L011bHRpcHVycG9zZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEludGVybmV0IE1haWwgRXh0ZW5zaW9ucwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIChTL01JTUUpIFZlcnNpb24gMy4yIE1lc3NhZ2UKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIiwgUkZDIDU3NTEsCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDEwLgoK ICAgW1JGQzY2OThdICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIb2ZmbWFuLCBQLiBh bmQgSi4gU2NobHl0ZXIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIlRoZSBETlMtQmFzZWQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBdXRoZW50aWNhdGlvbiBvZiBOYW1lZAoKCgpIb2ZmbWFuLCBldCBhbC4gICAgICAgICAg IEV4cGlyZXMgQXByaWwgMywgMjAxNCAgICAgICAgICAgICAgICBbUGFnZSAxNl0KDApJbnRlcm5l dC1EcmFmdCAgICAgRE5TLUJhc2VkIEF1dGhlbnRpY2F0aW9uIGZvciBTL01JTUUgICAgU2VwdGVt YmVyIDIwMTMKCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVu dGl0aWVzIChEQU5FKSBUcmFuc3BvcnQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBMYXllciBTZWN1cml0eSAoVExTKQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFByb3RvY29sOiBUTFNBIiwgUkZDIDY2OTgsCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTIuCgo5LjIuICBJbmZv cm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbTklTVC44MDAtNTctMV0gICAgICAgICAgICAgICAgICAg ICAgICAgIE5hdGlvbmFsIEluc3RpdHV0ZSBvZgogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neSwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiTklTVCBTcGVjaWFsIFB1YmxpY2F0aW9uCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgODAwLTU3IFJlY29tbWVu ZGF0aW9ucyBmb3IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBL ZXkgTWFuYWdlbWVudCAtIFBhcnQgMToKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBHZW5lcmFsIiwgTklTVCA4MDAtNTcgUGFydAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDEsIEp1bHkgMjAxMi4KCiAgIFtSRkMyODQ1XSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgVml4aWUsIFAuLCBHdWRtdW5kc3NvbiwgTy4sCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRWFzdGxha2UsIEQuLCBh bmQgQi4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBXZWxsaW5n dG9uLCAiU2VjcmV0IEtleQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFRyYW5zYWN0aW9uIEF1dGhlbnRpY2F0aW9uCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgZm9yIEROUyAoVFNJRykiLCBSRkMgMjg0NSwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXkgMjAwMC4KCiAgIFtSRkMyOTMxXSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRWFzdGxha2UsIEQuLCAiRE5TIFJlcXVlc3QK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbmQgVHJhbnNhY3Rp b24gU2lnbmF0dXJlcyAoCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgU0lHKDApcykiLCBSRkMgMjkzMSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBTZXB0ZW1iZXIgMjAwMC4KCiAgIFtSRkMzNDAzXSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTWVhbGxpbmcsIE0uLCAiRHluYW1pYwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIERlbGVnYXRpb24gRGlzY292ZXJ5IFN5c3RlbQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChERERTKSBQYXJ0IFRocmVl OiBUaGUKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEb21haW4g TmFtZSBTeXN0ZW0gKEROUykKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBEYXRhYmFzZSIsIFJGQyAzNDAzLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE9jdG9iZXIgMjAwMi4KCiAgIFtSRkM1MzIyXSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgUmVzbmljaywgUC4sIEVkLiwgIkludGVybmV0CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWVzc2FnZSBGb3JtYXQiLCBSRkMgNTMyMiwK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDgu CgogICBbUkZDNjA3MV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZyYW5rZWwsIFMu IGFuZCBTLiBLcmlzaG5hbiwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAiSVAgU2VjdXJpdHkgKElQc2VjKSBhbmQKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBJbnRlcm5ldCBLZXkgRXhjaGFuZ2UgKElLRSkKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEb2N1bWVudCBSb2FkbWFwIiwgUkZDIDYw NzEsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmVicnVhcnkg MjAxMS4KCiAgIFtSRkM2MjM0XSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRWFzdGxh a2UsIEQuIGFuZCBULiBIYW5zZW4sCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIlVTIFNlY3VyZSBIYXNoIEFsZ29yaXRobXMKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAoU0hBIGFuZCBTSEEtYmFzZWQgSE1BQyBhbmQKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIS0RGKSIsIFJGQyA2MjM0LCBN YXkgMjAxMS4KCgoKSG9mZm1hbiwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDMsIDIw MTQgICAgICAgICAgICAgICAgW1BhZ2UgMTddCgwKSW50ZXJuZXQtRHJhZnQgICAgIEROUy1CYXNl ZCBBdXRoZW50aWNhdGlvbiBmb3IgUy9NSU1FICAgIFNlcHRlbWJlciAyMDEzCgoKICAgW1JGQzYz NzZdICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDcm9ja2VyLCBELiwgSGFuc2VuLCBU LiwgYW5kCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gS3Vj aGVyYXd5LCAiRG9tYWluS2V5cwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIElkZW50aWZpZWQgTWFpbCAoREtJTSkKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBTaWduYXR1cmVzIiwgU1REIDc2LAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFJGQyA2Mzc2LCBTZXB0ZW1iZXIgMjAxMS4KCiAgIFtS RkM2NTMwXSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgS2xlbnNpbiwgSi4gYW5kIFku IEtvLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJPdmVydmll dyBhbmQgRnJhbWV3b3JrIGZvcgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEludGVybmF0aW9uYWxpemVkIEVtYWlsIiwKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBSRkMgNjUzMCwgRmVicnVhcnkgMjAxMi4KCiAgIFtSRkM3MDMz XSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSm9uZXMsIFAuLCBTYWxndWVpcm8sIEcu LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEpvbmVzLCBNLiwg YW5kIEouIFNtYXJyLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICJXZWJmaW5nZXIiLCBSRkMgNzAzMywKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBTZXB0ZW1iZXIgMjAxMy4KCkFwcGVuZGl4IEEuICBPcGVyYXRpb25hbCBDb25z aWRlcmF0aW9ucyBmb3IgRGVwbG95aW5nIFNNSU1FQSBSZWNvcmRzCgogICBBcHBlbmRpeCBBIGFu ZCBCIG9mIFtSRkM2Njk4XSBmb3IgREFORS9UTFNBIGFyZSBkaXJlY3RseSBhcHBsaWNhYmxlLAog ICBwYXJ0aWN1bGFybHkgcmVnYXJkaW5nIGNlcnRpZmljYXRlIHVzZSBjYXNlcy4gIEltcGxlbWVu dGVycyBzaG91bGQgYmUKICAgZmFtaWxpYXIgd2l0aCB0aGVzZSBzZWN0aW9ucy4gIFNNSU1FQSBz cGVjaWZpYyBwcm92aXNpb25pbmcgZXhhbXBsZXMKICAgYXJlIGluY2x1ZGVkIGhlcmUuCgpBLjEu ICBQcm92aXNpb25pbmcgU01JTUVBIFJlY29yZHMgaW4gRE5TIHdpdGggQWxpYXNlcyBhbmQgV2ls ZGNhcmRzCgpBLjEuMS4gIFByb3Zpc2lvbmluZyBTTUlNRUEgd2l0aCBETkFNRSBSZWNvcmRzCgog ICBBIEROQU1FIHJlY29yZCBhbGxvd3MgYSB6b25lIG93bmVyIHRvIGFsaWFzIGFuIGVudGlyZSBz dWJ0cmVlIG9mCiAgIG5hbWVzIGJlbG93IHRoZSBuYW1lIHRoYXQgaGFzIHRoZSBETkFNRS4gIFRo aXMgYWxsb3dzIHRoZSB3aG9sZXNhbGUKICAgYWxpYXNpbmcgb2YgcHJlZml4ZWQgcmVjb3Jkcy4g IElmIHRoZSBkb21haW4ncyB1c2VycyBlbXBsb3kgdGhlIHNhbWUKICAgY2VydGlmaWNhdGUgZm9y IGJvdGggZGlnaXRhbCBzaWduYXR1cmUgYW5kIGVuY3J5cHRpb24sIGEgRE5BTUUgcmVjb3JkCiAg IGVuYWJsZXMgYSBzaW5nbGUgUlIgZm9yIGVhY2ggdXNlci4gIE5vdGUgdGhhdCBpZiBDZXJ0aWZp Y2F0ZSBBY2Nlc3MgPQogICAiTk8iIHRoZSBmdWxsIGNlcnRpZmljYXRlIGlzIHJlcXVpcmVkIGlu IG9yZGVyIHRvIHN1cHBvcnQgZW5jcnlwdGlvbi4KCgoKCgoKCgoKCgoKCgoKCgoKSG9mZm1hbiwg ZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDMsIDIwMTQgICAgICAgICAgICAgICAgW1Bh Z2UgMThdCgwKSW50ZXJuZXQtRHJhZnQgICAgIEROUy1CYXNlZCBBdXRoZW50aWNhdGlvbiBmb3Ig Uy9NSU1FICAgIFNlcHRlbWJlciAyMDEzCgoKICAgIDsgRE5BTUUgZW5hYmxlcyBzaW5nbGUgU01J TUVBIGVudHJ5IGZvciBib3RoICJfZW5jciIgYW5kICJfc2lnbiIKICAgIDsgSW5kaXZpZHVhbCBy ZWNvcmRzIG9ubHkgcmVxdWlyZWQgZm9yICJfZW5jciIKICAgIDsKICAgIF9zaWduLl9zbWltZWNl cnQuZXhhbXBsZS5jb20uIElOIEROQU1FIF9lbmNyLl9zbWltZWNlcnQuZXhhbXBsZS5jb20uCgog ICAgOyBib2IKICAgIE1KWFdFPT09Ll9lbmNyLl9zbWltZWNlcnQuZXhhbXBsZS5jb20uIElOIFNN SU1FQSAoCiAgICAgICAgICAgICAgIERBTkUtRUUgQ2VydCBGdWxsIE5PIDMwODIwM2IzMzA4MjAy OWJhMDAzMDIwMTAyMDIwOTAwCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJh YjBiNGQ0ODJhZTQ4OWYzMDBkMDYwOTJhODYgLi4uICkKICAgIDsgYWxpY2UKICAgIE1GV0dTWTNG Ll9lbmNyLl9zbWltZWNlcnQuZXhhbXBsZS5jb20uIElOIFNNSU1FQSAoCiAgICAgICAgICAgICAg IERBTkUtRUUgQ2VydCBGdWxsIE5PIDMwODIwM2JiMzA4MjAyYTNhMDAzMDIwMTAyMDIwOTAwCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDgyZTlhMTc1MmQ1NmFlNTczMDBkMDYw OTJhODYgLi4uICkKCgpBLjEuMi4gIFByb3Zpc2lvbmluZyBTTUlNRUEgd2l0aCBDTkFNRSBSZWNv cmRzCgogICBDTkFNRSByZWNvcmRzIGFsbG93cyBhIHpvbmUgb3duZXIgdG8gYWxpYXMgbXVsdGlw bGUgZG9tYWluIG5hbWVzIHRvIGEKICAgc2luZ2xlIFNNSU1FQSByZXNvdXJjZSByZWNvcmQuICBU aGlzIG1heSBiZSBoZWxwZnVsIGZvciBjYWNoZXMgdG8KICAga2VlcCBhIHNpbmdsZSBjb3B5IG9m IGEgc2lnbmluZyBjZXJ0aWZpY2F0ZSBhbmQgdGhlbiBzdG9yZSBDTkFNRXMgZm9yCiAgIGluZGl2 aWR1YWwgdXNlcnMuCgoKICAgICAgOyBDTkFNRSBlbmFibGVzIHNpbmdsZSBTTUlNRUEgUlIgZm9y IFRBIHNpZ25pbmcgY2VydGlmaWNhdGUKICAgICAgOyBWYWxpZGF0aW9uIHJlcXVpcmVzIHNpZ25h dHVyZSBieSBpbmNsdWRlZCBnZW4tdXNlciBjZXJ0CiAgICAgIDsgT25seSBvbmUgY29weSBvZiBm dWxsIGNlcnRpZmljYXRlIGluIGxvY2FsIGNhY2hlcwogICAgICA7IEluZGl2aWR1YWwgcmVjb3Jk cyBqdXN0IENOQU1FCiAgICAgIDsKICAgICAgZ2VuLXVzZXIuX3NpZ24uX3NtaW1lY2VydC5leGFt cGxlLmNvbS4gIElOIFNNSU1FQSAoCiAgICAgICAgICAgICAgICAgREFORS1UQSBDZXJ0IEZ1bGwg Tk8gMzA4MjAyZDAzMDgyMDIzOWEwMDMwMjAxLi4uKQogICAgICA7CiAgICAgIE1OVUhFMkxULl9z aWduLl9zbWltZWNlcnQuZXhhbXBsZS5jb20uIElOIENOQU1FICAoCiAgICAgICAgICAgICAgICAg ICAgICAgICAgIGdlbi11c2VyLl9zaWduLl9zbWltZWNlcnQuZXhhbXBsZS5jb20uICkKICAgICAg OwogICAgICBNRldHU1kzRi5fc2lnbi5fc21pbWVjZXJ0LmV4YW1wbGUuY29tLiBJTiBDTkFNRSAg KAogICAgICAgICAgICAgICAgICAgICAgICAgICBnZW4tdXNlci5fc2lnbi5fc21pbWVjZXJ0LmV4 YW1wbGUuY29tLiApCgoKQS4xLjMuICBQcm92aXNpb25pbmcgU01JTUVBIFJlY29yZHMgd2l0aCBX aWxkY2FyZHMKCiAgIE5YRE9NQUlOIHJlc3BvbnNlIHRvIGFuIFNNSU1FQSByZXF1ZXN0IGhhcyBh biBhbWJpZ3VvdXMKICAgaW50ZXJwcmV0YXRpb24uICBJdCBjb3VsZCBiZSB0aGUgcmVzdWx0IG9m IHRoZSBETlMgem9uZSBub3QKICAgc3VwcG9ydGluZyBTTUlNRUEgcmVjb3JkcyBvciBpdCBjb3Vs ZCBiZSB0aGUgcmVzdWx0IG9mIGEgcXVlcnkgZm9yIGFuCiAgIGludmFsaWQgdXNlciAoaW5jbHVk aW5nIGNhc2Ugc2Vuc2l0aXZpdHkgbWlzbWF0Y2hlcykuICBXaWxkY2FyZHMgbWF5CiAgIGJlIHVz ZWQgdG8gcmVtb3ZlIHRoZSBhbWJpZ3VpdHkgYW5kIG1heSBhbHNvIGVhc2Ugc29tZSBhZG1pbmlz dHJhdGl2ZQogICB0YXNrcy4gIE5vdGUgdGhhdCB3aWxkY2FyZHMgcHJvdmlkZSBhIHJlc3BvbnNl IHRvIGFsbCBwb3NzaWJsZSB1c2VyCiAgIG5hbWVzIGFuZCB0aHVzIGluY3JlYXNlIHRoZSByaXNr IGZvciB1c2UgYXMgYSBERG9TIGFtcGxpZmljYXRpb24KICAgdmVjdG9yLiAgVHdvIGV4YW1wbGUg c2NlbmFyaW9zIGFyZSBwcm92aWRlZCB0aGF0IGVzdGFibGlzaCBmYWN0IG9mCgoKCkhvZmZtYW4s IGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAzLCAyMDE0ICAgICAgICAgICAgICAgIFtQ YWdlIDE5XQoMCkludGVybmV0LURyYWZ0ICAgICBETlMtQmFzZWQgQXV0aGVudGljYXRpb24gZm9y IFMvTUlNRSAgICBTZXB0ZW1iZXIgMjAxMwoKCiAgIHpvbmUncyBzdXBwb3J0IGZvciBEQU5FL1NN SU1FIGFuZCBlbmFibGUgY2VydGlmaWNhdGUgcmV2b2NhdGlvbi4KCkEuMS4zLjEuICBXaWxkY2Fy ZCBmb3IgQWxsIEludmFsaWQgVXNlcnMKCiAgIDEuICAxLiAgVGhlIGRvbWFpbiBhZG1pbmlzdHJh dG9yIGNyZWF0ZXMgdXNlciBkb21haW5zIGFuZCB1bmlxdWUKICAgICAgIFNNSU1FQSB6b25lIGVu dHJ5IGZvciBlYWNoIHZhbGlkIHVzZXIgY29ycmVzcG9uZGluZyB0byB1c2VycycKICAgICAgIGNl cnRpZmljYXRlcy4KCiAgIDIuICAyLiAgVGhlIGFkbWluaXN0cmF0b3IgY3JlYXRlcyBhIHdpbGRj YXJkIGRvbWFpbiBTTUlNRUEgZW50cnkgdG8KICAgICAgIGFjdCBhcyBkZWZhdWx0IGZvciBhbGwg dXNlciBuYW1lcyB3aXRob3V0IGFuIGV4cGxpY2l0IHpvbmUgZW50cnkuCiAgICAgICBSREFUQSBp biB0aGUgd2lsZGNhcmQgZG9tYWluIGVudHJ5IGlzIGRlc2lnbmVkIHRvIGNhdXNlCiAgICAgICBj ZXJ0aWZpY2F0ZSBtYXRjaCBmYWlsdXJlcyBmb3IgYWxsIGNlcnRpZmljYXRlIGNoZWNrcy4KCiAg IDMuICAzLiAgVG8gcmV2b2tlIGEgdXNlcidzIGNlcnRpZmljYXRlLCB0aGUgdXNlcidzIGVudHJ5 IGlzIHJlbW92ZWQKICAgICAgIGZyb20gdGhlIHpvbmUuCgoKICAgICAgOwogICAgICA7IFdpbGRj YXJkIGV4YW1wbGUgd2l0aCB0d28gdmFsaWQgc2lnbmluZyBjZXJ0aWZpY2F0ZSB1c2VycwogICAg ICA7IEFsbCBvdGhlciAuZXhhbXBsZS5jb20gYWRkcmVzc2VzIHJlY2VpdmUgSU5WQUxJRCBDRVJU SUZJQ0FURQogICAgICA7CiAgICAgIE1GV0dTWTNGLl9zaWduLl9zbWltZWNlcnQuZXhhbXBsZS5j b20uIElOIFNNSU1FQSAoCiAgICAgICAgICAgICAgICAgUEtJWC1FRSBDZXJ0IFNIQTItMjU2IE5P IDhjMzQwMjI3ZmY5NjEyOGYKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJlMzc2 NGM5YjhjNWFmODQ2ZDA4MWZhYwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNzJj MjRhZjZhNTg5MWY2ZTE5YjFkODQ3ICkKICAgICAgOwogICAgICBNSlhXRT09PS5fc2lnbi5fc21p bWVjZXJ0LmV4YW1wbGUuY29tLiBJTiBTTUlNRUEgKAogICAgICAgICAgICAgICAgIFBLSVgtRUUg Q2VydCBTSEEyLTI1NiBOTyAwMjFlNDg3NGIwN2MyMTM3CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBhNWZlOTVkOWJkOWQwNDE1NDBiNDUwMDMKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGZhYTdhNzMxODFkZGI1Y2I2NTkxMzQ5MyApCiAgICAgIDsKICAgICAgKl9z aWduLl9zbWltZWNlcnQuZXhhbXBsZS5jb20uICAgICAgICAgSU4gU01JTUVBICgKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgUkVKRUNUIENlcnQgRnVsbCBOTyAwMCApCiAgICAg ICpfZW5jci5fc21pbWVjZXJ0LmV4YW1wbGUuY29tLiAgICAgICAgIElOIFNNSU1FQSAoCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJFSkVDVCBDZXJ0IEZ1bGwgTk8gMDAgKQoK QS4xLjMuMi4gIE9yZ2FuaXphdGlvbiBUQSBXaWxkY2FyZAoKICAgMS4gIFRoZSB6b25lIGFkbWlu aXN0cmF0b3IgY3JlYXRlcyBhIHZhbGlkIGRlZmF1bHQgU01JTUVBIHJlY29yZAogICAgICAgdXNp bmcgYSB3aWxkY2FyZCBkb21haW4uICBUaGUgb3JnYW5pemF0aW9uJ3MgcHVibGljIGNlcnRpZmlj YXRlCiAgICAgICBpcyBpbmNsdWRlZCBpbiB0aGUgUkRBVEEgYW5kIHRoZSBjZXJ0aWZpY2F0ZSB1 c2UgdHlwZSBpcyBEQU5FLVRBCiAgICAgICAoMikgYW5kIHRoZSBtYXRjaGluZyB0eXBlIGlzIEZ1 bGwgKDApLiAgQnkgZGVmYXVsdCwgYWxsIG5vbi0KICAgICAgIGV4cGlyZWQgY2VydGlmaWNhdGVz IHRoYXQgYXJlIHNpZ25lZCBieSB0aGUgb3JnYW5pemF0aW9uJ3MgcHVibGljCiAgICAgICBrZXkg YXJlIGNvbnNpZGVyZWQgdmFsaWQuCgogICAyLiAgVG8gcmV2b2tlIGEgdXNlcidzIGNlcnRpZmlj YXRlOgoKCgoKCkhvZmZtYW4sIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAzLCAyMDE0 ICAgICAgICAgICAgICAgIFtQYWdlIDIwXQoMCkludGVybmV0LURyYWZ0ICAgICBETlMtQmFzZWQg QXV0aGVudGljYXRpb24gZm9yIFMvTUlNRSAgICBTZXB0ZW1iZXIgMjAxMwoKCiAgICAgICAxLiAg QSBjb21wcm9taXNlZCBjZXJ0aWZpY2F0ZSBtYXkgYmUgcmV2b2tlZCBieSBjcmVhdGluZyBhIG5l dyBSUgogICAgICAgICAgIHdpdGggdmFsaWRhdGlvbiBpbmZvcm1hdGlvbiBzcGVjaWZpY2FsbHkg Zm9yIHRoZSB1c2VyJ3MgbmV3CiAgICAgICAgICAgY2VydGlmaWNhdGUuCgogICAgICAgMi4gIEEg dXNlciBtYXkgYmUgcmV2b2tlZCBieSBpbmNsdWRpbmcgY2VydGlmaWNhdGUgdXNhZ2UgPQogICAg ICAgICAgIFJFSkVDVC4KCgogIDsKICA7IFdpbGRjYXJkIGV4YW1wbGUgdmFsaWRhdGluZyBjZXJ0 cyBmb3IgYWxsIHVzZXJzIGFzIGxvbmcKICAgICA7ICAgIGFzIHRoZWlyIGNlcnQgaXMgc2lnbmVk IGJ5IGV4YW1wbGUuY29tIHRydXN0IGFuY2hvci4KICAgICA7ICAgIFVzZXIgZW5jcnlwdGlvbiBj ZXJ0cyBhdmFpbGFibGUgdmlhIFdlYkZpbmdlci4KICAgICA7CiAgICAgOyBPbGQgc2lnbiBjZXJ0 IHJldm9rZWQgZm9yIE1OVUhLWTNMIChjaHVjaykgLS0gb25seSBuZXcgY2VydAogICAgIDsgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZhbGlkYXRlcwogICAg IDsgQWxsIGVuY3J5cHRpb24gY2VydHMgZm9yIE1OVUhLWTNMIChjaHVjaykgYXJlIHJldm9rZWQK ICAgICA7CiAgICAgOwogICAgIDsgY29tbW9uIHRydXN0IGFuY2hvciBmb3IgYWxsIGV4YW1wbGUu Y29tIHVzZXJzCiAgICAgKi5fc2lnbi5fc21pbWVjZXJ0LmV4YW1wbGUuY29tLiAgICAgICAgSU4g U01JTUVBICgKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgREFO RS1UQSBTUEtJIEZ1bGwgTk8gKC4uLikKICAgICA7CiAgICAgKi5fZW5jci5fc21pbWVjZXJ0LmV4 YW1wbGUuY29tLiAgICAgICAgSU4gU01JTUVBICgKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgREFORS1UQSBTUEtJIEZ1bGwgV0YgKC4uLikKICAgICA7CiAgICAg OwogICAgIDsgbmV3IHNpZ24gY2VydCBmb3IgY2h1Y2sKICAgICBNTlVIS1kzTC5fc2lnbi5fc21p bWVjZXJ0LmV4YW1wbGUuY29tLiBJTiBTTUlNRUEgKAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBEQU5FLUVFIFNQS0kgU0hBMi0yNTYgTk8gKC4uLikKICAgICA7CiAg ICAgOyBlbmNyIHJldm9rZWQgZm9yIGNodWNrCiAgICAgTU5VSEtZM0wuX2VuY3IuX3NtaW1lY2Vy dC5leGFtcGxlLmNvbS4gSU4gU01JTUVBICgKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUkVKRUNUIENlcnQgRnVsbCBOTyAwMCApCgoKCkF1dGhvcnMnIEFkZHJlc3NlcwoK ICAgUGF1bCBIb2ZmbWFuCiAgIFZQTiBDb25zb3J0aXVtCgogICBFTWFpbDogcGF1bC5ob2ZmbWFu QHZwbmMub3JnCgoKCgoKCgoKCkhvZmZtYW4sIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBcHJp bCAzLCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdlIDIxXQoMCkludGVybmV0LURyYWZ0ICAgICBE TlMtQmFzZWQgQXV0aGVudGljYXRpb24gZm9yIFMvTUlNRSAgICBTZXB0ZW1iZXIgMjAxMwoKCiAg IEpha29iIFNjaGx5dGVyCiAgIEtpcmVpIEFCCgogICBFTWFpbDogamFrb2JAa2lyZWkuc2UKCgog ICBTY290dCBSb3NlCiAgIE5JU1QKICAgMTAwIEJ1cmVhdSBEci4KICAgR2FpdGhlcnNidXJnLCBN RCAgMjA4OTkKICAgVVNBCgogICBQaG9uZTogKzEtMzAxLTk3NS04NDM5CiAgIEVNYWlsOiBzY290 dC5yb3NlQG5pc3QuZ292CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpIb2Zm bWFuLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXByaWwgMywgMjAxNCAgICAgICAgICAgICAg ICBbUGFnZSAyMl0KDAo= --089e0122f4f0177f5004ea8edae5-- From bry8star@inventati.org Thu Nov 7 04:03:05 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9B011E814D for ; Thu, 7 Nov 2013 04:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61jxl1Q2f2bh for ; Thu, 7 Nov 2013 04:03:04 -0800 (PST) Received: from diserzione.investici.org (diserzione.investici.org [IPv6:2002:52dd:6399::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC72511E813D for ; Thu, 7 Nov 2013 04:02:47 -0800 (PST) Received: from [82.221.99.153] (diserzione [82.221.99.153]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id 772F31811B0 for ; Thu, 7 Nov 2013 12:02:41 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.6.8 diserzione.investici.org 772F31811B0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1383825764; bh=8GOnREcBrSpMqF67ssz+U7vPn7VD6GmqKVatiUtMOPQ=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=nzZ51TKcYOW5s95826JaToCsaiOtz++73p0kbtjW1h6RW+DdU/TA0JeNycKZTRdCV RJG39dlChNFuBFkJ+bX/8RcF7w0UhoZJX1JFVc1sgprTx5xedX8S27hTjgDd4v7faS JtcfX/alDgW90dX1YrySGzpVdcvYHsVssqf5FMKU= Message-ID: <527B820C.1000602@inventati.org> Date: Thu, 07 Nov 2013 04:05:32 -0800 From: Bry8 Star User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: dane@ietf.org References: <527A753A.4040800@nist.gov> In-Reply-To: <527A753A.4040800@nist.gov> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] NIST DANE Tester Announcement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bry8star@inventati.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 Nov 2013 12:03:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Thanks. Will it be possible to add another textbox/input-field in this tester-site, for the DANE-signed domain-name that will be tested, to allow upload of a pem or crt or cer file which will be used with the HTTPS Web-Server, or with other scheme based server ? or a textbox to "paste" the cert or cert-chain code from such file. So that, test can show result info, by ruling-out that, a TLS/SSL cert or cert-chain used by the DANE-signed site, was not present in visitor's/client side web-browser/OS. My understanding is, such will allow to really TEST the DANE/TLSA "Usage" 2 and 3 cases. If you do not have domain owner's (TLSA "Usage" case 2's or 3's) TLS/SSL cert or cert-chain file, then will not your test-result always fail for those TWO "Usage" cases ? - - - - - - For users to test DANE+DNSSEC from their own location/computer, mentioned in below is one (or two in long shot) option(s), out of few other options: If a local full DNSSEC supported DNS-Server or DNS-Resolver software is present (for more accurate tests) in local computer or local (trusted) LAN, or in (local) VM. Then Mozilla Firefox, upto v24.0, (or other firefox/gecko/XUL-runner based web-browsers, like: GNU IceCat, Iceweasel, etc), can have partial DANE awareness, by loading the "Extended DNSSEC Validator" ("EDV", a firefox addon/extension from os3sec.org), this addon helps to display info/icon related to DANE/TLSA "Usage" 2 & 3, but no support for Usage 0 or 1 yet, this addon also has DNSSEC awareness and can display info related to DNSSEC authentications, it can also display info on SSL/TLS cert verification (and certificate chain verification), etc. But, EDV v0.5 (mozilla), v0.6 (github) or v0.8 (github) none worked on Firefox v25.0 or later, last tested on Nov 5, 2013. Based on EDV author's response, it seems, he is not interested now, in continuing developing anymore. And, developer/dev-group of "DNSSEC-Validator" (another Firefox addon, from CZ.NIC) said on mailing list, that they will add support for DANE from next month. Currently it supports displaying only DNSSEC (except DANE) related info/icon. - - Bright Star. Received from Stephen Nightingale, on 2013-11-06 8:58 AM: > > For those DANEs who are in Vancouver, you can talk to Scott Rose or > Doug Montgomery about this. Doug will be at the informal DANE lunch > tomorrow. > > ======== > > NIST has developed a test system for the RFC 6698 DANE protocol. > DANE seeks to verify PKIX certificate based Transport Layer Security > (RFC 5246 TLS) connections using the Domain Name System as secured > by DNSSEC. > > https://www.had-pilot.com/dane/danelaw.html > > The NIST DANE test system has three modes of operation: > > - Test your DANE enabled site: > Enter the URL of a site for which a DANE TLSA resource record is > provisioned. The system will negotiate the connection, verify with > DANE and get the web page - or provide failure diagnostics. > > - A reference test set to test your browser in response to all > possible DANE configurations. > > - If your browser is NOT DANE enabled, a reference test set to test > a DANE client's response to all possible configurations and return > the results to your browser. > > The site is up and available for testing - But it is still early > days and there may be occasional outages. Please be patient and/or > let us know. > > Stephen Nightingale, NIST > HAD Pilot Program > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSe4ILAAoJEID2ikYfWSP6J+wP/2oca5+I582EWHqWSWCJOhK+ m31LbzIz6UiHVDu9BRcm1BHyz6pVe3D3NawTZigLOm59qHBCQYpyO/gD295wAM4b bEyWJday8OvHq09+YLOxNXDVIMhl4kD8IuTeRyL1RpEXRNlFPfF0NJA8N9eQGrl5 sNanIQC6aFWOQWREUOr0hFWJkRM5Wz5rVD+sNy5HmbrNhFP+4ZV+bzeIAchawcIs KKMSNkcroNhlm3M0Olg6l1xUcKMN8MxfAyco1VfwzBpJckoS8rdaOpEE8ghor1gD SwKEhWHRSeiguaNXE4JEY3Z3h/PYsSGuTxVP+gN2198ToZXMYE1MJCOTF/oGTHRu H385t5RVEiRqkbE86WwZilV4oXl9L/gpVF+tpliGvgAdYwi0mW6oT5l/CstNZBEW of+4KxsDuZXDpgEselNLuglRJpo79z3+tjwjjRAjv3PhKRusLpA9tAc7mNj6eSJF jUPnCc6W9LriqaF0QNF2a4ULQqa2wFnRjZGX+Mq7i+FMZ7JVVWcJvV/qUnNBLTvb 49fXmg0UXxxydueedcG2ZRoLzjSqRmchkdBSNlWiiuM6XsYyhrwKcy/plgOXeUSS vbrE4bJr/U/MoeasamB4xtLVYjiI9qhxJtt3mn0H8CtglvVVltTPQdEMwOpMrmdp pVIuKJfGQPeduqwZ5rGN =kpRU -----END PGP SIGNATURE----- From bry8star@inventati.org Thu Nov 7 04:33:03 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEC511E81D0 for ; Thu, 7 Nov 2013 04:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J73wqflTI9iV for ; Thu, 7 Nov 2013 04:32:59 -0800 (PST) Received: from diserzione.investici.org (diserzione.investici.org [82.221.99.153]) by ietfa.amsl.com (Postfix) with ESMTP id 70A1711E8138 for ; Thu, 7 Nov 2013 04:32:59 -0800 (PST) Received: from [82.221.99.153] (diserzione [82.221.99.153]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id B69B7181199 for ; Thu, 7 Nov 2013 12:32:54 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.6.8 diserzione.investici.org B69B7181199 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1383827578; bh=lhMWCAEyCFzRi1aNylqik4BL74SXRp5ePDoUjjS6bbE=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=Tdc6CRshrmMR0/7d3mjYkl4KY+ZIYPWn79nCtJIYl1OV/sMN+lbAvixh25SDqLnoG 3To+dY7Geb0SjTt+GNEqrWMERl7/VpwWyZad/nN31+LtPJsZ6J3C2mdjnzbAqg8FdV FAXwBakJoO0u+MBU6j/XCBkskPAqMSaCM+188888= Message-ID: <527B8924.3070004@inventati.org> Date: Thu, 07 Nov 2013 04:35:48 -0800 From: Bry8 Star User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: dane@ietf.org References: <527A753A.4040800@nist.gov> <527B820C.1000602@inventati.org> In-Reply-To: <527B820C.1000602@inventati.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] NIST DANE Tester Announcement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bry8star@inventati.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 Nov 2013 12:33:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Users who will run test, should MAKE SURE to upload ONLY the PUBLIC certificate portion(s), or such certificate-chain portion (which DO NOT INCLUDE ANY PRIVATE KEY portion) into such textbox. They SHOULD NOT upload the exact cert file or cert-chain file which will be used in real HTTPS server or other TLS encrypted scheme/protocol based Server. As such file may have private keys. With such option (to copy-paste PUBLIC certificate codes), Tests related to "Usage" case 2 & 3 should succeed. Or, can your test-system pull the "Usage" case 3's TLS cert out of the TLSA DNS record, if domain-name have declared the FULL TLS cert code in TLSA ? and then, can such FULL SSL/TLS cert code be used for initiating encrypted connection, with the DANE-signed domain-name based TLS/HTTPS Server/URL ? - - Bright Star. Received from Bry8 Star, on 2013-11-07 4:05 AM: > Hi, > > Thanks. > > Will it be possible to add another textbox/input-field in this > tester-site, for the DANE-signed domain-name that will be tested, to > allow upload of a pem or crt or cer file which will be used with the > HTTPS Web-Server, or with other scheme based server ? or a textbox > to "paste" the cert or cert-chain code from such file. So that, > test can show result info, by ruling-out that, a TLS/SSL cert or > cert-chain used by the DANE-signed site, was not present in > visitor's/client side web-browser/OS. > > My understanding is, such will allow to really TEST the DANE/TLSA > "Usage" 2 and 3 cases. > > If you do not have domain owner's (TLSA "Usage" case 2's or 3's) > TLS/SSL cert or cert-chain file, then will not your test-result > always fail for those TWO "Usage" cases ? > > - - - - - > > For users to test DANE+DNSSEC from their own location/computer, > mentioned in below is one (or two in long shot) option(s), out of > few other options: > > If a local full DNSSEC supported DNS-Server or DNS-Resolver software > is present (for more accurate tests) in local computer or local > (trusted) LAN, or in (local) VM. > > Then Mozilla Firefox, upto v24.0, (or other firefox/gecko/XUL-runner > based web-browsers, like: GNU IceCat, Iceweasel, etc), can have > partial DANE awareness, by loading the "Extended DNSSEC Validator" > ("EDV", a firefox addon/extension from os3sec.org), this addon helps > to display info/icon related to DANE/TLSA "Usage" 2 & 3, but no > support for Usage 0 or 1 yet, this addon also has DNSSEC awareness > and can display info related to DNSSEC authentications, it can also > display info on SSL/TLS cert verification (and certificate chain > verification), etc. > > But, EDV v0.5 (mozilla), v0.6 (github) or v0.8 (github) none worked > on Firefox v25.0 or later, last tested on Nov 5, 2013. Based on EDV > author's response, it seems, he is not interested now, in continuing > developing anymore. > > And, developer/dev-group of "DNSSEC-Validator" (another Firefox > addon, from CZ.NIC) said on mailing list, that they will add support > for DANE from next month. Currently it supports displaying only > DNSSEC (except DANE) related info/icon. > > > - Bright Star. > > > > Received from Stephen Nightingale, on 2013-11-06 8:58 AM: > >> For those DANEs who are in Vancouver, you can talk to Scott Rose or >> Doug Montgomery about this. Doug will be at the informal DANE lunch >> tomorrow. > >> ======== > >> NIST has developed a test system for the RFC 6698 DANE protocol. >> DANE seeks to verify PKIX certificate based Transport Layer Security >> (RFC 5246 TLS) connections using the Domain Name System as secured >> by DNSSEC. > >> https://www.had-pilot.com/dane/danelaw.html > >> The NIST DANE test system has three modes of operation: > >> - Test your DANE enabled site: >> Enter the URL of a site for which a DANE TLSA resource record is >> provisioned. The system will negotiate the connection, verify with >> DANE and get the web page - or provide failure diagnostics. > >> - A reference test set to test your browser in response to all >> possible DANE configurations. > >> - If your browser is NOT DANE enabled, a reference test set to test >> a DANE client's response to all possible configurations and return >> the results to your browser. > >> The site is up and available for testing - But it is still early >> days and there may be occasional outages. Please be patient and/or >> let us know. > >> Stephen Nightingale, NIST >> HAD Pilot Program > > >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSe4kkAAoJEID2ikYfWSP6ah0P/jx0O35IvEqKbtqxRwo6A92d poQrEuEGpZWObJVsI5vboNslHDCsm+gOzxpyYbR0xcL4GfYB/rXh4wAdbelUEi4J pSmLVjNXgP/+q5hOmuB/eDdKA/Bq8/LuUc+3/oQ8OBqzT4Pru4exMQVTX8F2UCRe uFbje1zs6wXarATLav467BUTsOH8yMC45lhWdYQdtwyr9uQqOq3VpczsQJwx3sU7 CyfArrCLwzH591PYUh/iirgj4JCSVdFpHoDFbFyj1Ur5zPu5sOay53N51+agYZ6k N1O3wB7iOJJ9+x9WWwQODb8e6nTUUzZuE7gKWvUMIhumxlRFFi7M4RJBROqrOOET cp3Ko/WOJyaPPlGOXTctIwqvej7Z0ZVXFMdl46xoQfNpYXlAuXrDRMrOjWyddwp7 qOwAoOEuvZynj8fTThfu3RW+dy2PY0XeJZQbK0aZ3tsKG71Zwn/0X1+pWf9IM40V xoCTZut2tq2aeDV4d+zXj9tqMAB1i2FxpJTFeKujeE2XTCgHHktD4GmlPVkjk28R iEdudxUY1Now0VU7H4O8THASW45wp0gIzO5zTaOqTSW0b9/L8RGc5/kfY844CDXm EBG0mgPI3ZeLZE9WIWUwgs3odMY+7GJX+a0oiNBGQ8cavm3IMw89RLAZ0yYGeMS0 SHj4C3PsHUPqqONdhdfG =+D3S -----END PGP SIGNATURE----- From guido@witmond.nl Thu Nov 7 04:58:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9662511E8104 for ; Thu, 7 Nov 2013 04:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M4CHRY9V3hg for ; Thu, 7 Nov 2013 04:58:11 -0800 (PST) Received: from mail.witmond.nl (mail.wtmnd.nl [80.100.189.3]) by ietfa.amsl.com (Postfix) with ESMTP id A26C611E8137 for ; Thu, 7 Nov 2013 04:58:10 -0800 (PST) Received: from [10.1.2.6] (unknown [10.1.2.6]) by mail.witmond.nl (Postfix) with ESMTP id 6F959C0B06 for ; Thu, 7 Nov 2013 12:58:08 +0000 (UTC) Message-ID: <527B8E60.8080404@witmond.nl> Date: Thu, 07 Nov 2013 13:58:08 +0100 From: Guido Witmond User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9 MIME-Version: 1.0 To: dane@ietf.org References: <527A753A.4040800@nist.gov> <527B820C.1000602@inventati.org> In-Reply-To: <527B820C.1000602@inventati.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2HHHRNNREPOTXTQHLSSEP" Subject: [dane] Extended DNSSEC Validator was: Re: NIST DANE Tester Announcement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 12:58:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2HHHRNNREPOTXTQHLSSEP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/07/13 13:05, Bry8 Star wrote: >=20 > But, EDV v0.5 (mozilla), v0.6 (github) or v0.8 (github) none worked > on Firefox v25.0 or later, last tested on Nov 5, 2013. Based on EDV > author's response, it seems, he is not interested now, in continuing > developing anymore. > And, developer/dev-group of "DNSSEC-Validator" (another Firefox > addon, from CZ.NIC) said on mailing list, that they will add support > for DANE from next month. Currently it supports displaying only > DNSSEC (except DANE) related info/icon. Hi, I'm the person who updated the Extended DNSSEC Validator to 0.8 and submitted it to the original maintainer. Who did publish it. I was awaiting for their addon as well, as the EDV is a decendant of the nic.cz DV. I guess it's time for me to pick up the EDV again. Guido. ------enig2HHHRNNREPOTXTQHLSSEP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJSe45gAAoJEHPd8GglaNRmhsAP/14dw5fk6oD688KTJFVLvE/m +d3MT3J5SGwDdQ8JvEspW179MReUVfpyA+LBGVqPU+z+zmWRIm1N6xA9fAS81KAL ykBfdzZo9rF+AD7sXqg1iS9+VGhnqiySnJKDt24ZAGaflh2QcRe/OmMKaN6IEk2d V5q1j9PHQtQ+gnZqJj5yrgN9ScP09ROl4XKc/Pb8+CEsK8sCwhG6WdPKiGTwVkjk +EQZTAGQTWhkJ9IgOARSRz3fuTI55jHyhNuO3PH361qAO7Nroz9fVEDTlro/8zXH 130i6x08/7W6tPHMljas9r4hOTcTAe2V8xYczDWJN66z1fYPzFYFm3tMnNNEXdvY 5BFS3DZpHsLk4coToVT7pJhqaoE5iVrtoeMXCsXQ2RdVdOXIxzpkulUpQxr+ipjr 3QWZiYJ/DRmm9FNTPeCj9d/9cXAQerMRFK473Ep664T2IVYH8fOxAc3HUNw1J+d+ kSoiLGWsrtawXyARCduFb9Vec4cyZWlyoqUM42DLWi0GCzNk6KukKljSQTwWzbl5 SWPkdrki/Av+UqwM8WgV2G1fn6RLMrgjkutQtc9a6p4UZln5Kb5qQrM8p9g8zmNY Rx3Ch78wse2H5qVHtJ8RA6bCt2U50VoEJz1YXAeDsX2dCeNPNWoLccNRBOINQiVy /DyUwrF9zOg3BK4rlDOw =gq8R -----END PGP SIGNATURE----- ------enig2HHHRNNREPOTXTQHLSSEP-- From stephen.nightingale@nist.gov Thu Nov 7 07:04:48 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BB221E8258 for ; Thu, 7 Nov 2013 07:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29KJYCgydCxU for ; Thu, 7 Nov 2013 07:04:43 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 026A121E824B for ; Thu, 7 Nov 2013 07:04:31 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 10:04:10 -0500 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 7 Nov 2013 10:04:08 -0500 Received: from [127.0.0.1] (31-140.antd.nist.gov [129.6.140.31]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id rA7F403w002871 for ; Thu, 7 Nov 2013 10:04:02 -0500 Message-ID: <527BABCC.7060308@nist.gov> Date: Thu, 7 Nov 2013 10:03:40 -0500 From: Stephen Nightingale Organization: NIST User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <527A753A.4040800@nist.gov> <20131106221442.GB5561@mournblade.imrryr.org> <527AD0D7.4030000@sidn.nl> In-Reply-To: <527AD0D7.4030000@sidn.nl> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: Subject: Re: [dane] NIST DANE Tester Announcement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: night@nist.gov List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:04:48 -0000 On 11/6/2013 6:29 PM, Marco Davids (SIDN) wrote: > For those of you who prefer a somewhat more simple approach, there is > still: > https://check.sidnlabs.nl/dane/ This is a potentially useful adjunct for clients that don't do DANE validation. BUT This is the answer for NIST.gov: Warning! No TLSA records for _443._tcp.inside.nist.gov. were found. PKIX validation without DANE will be performed. 129.6.13.244 dane-validated successfully Maybe you should say that the certificate PKIX validated, rather than saying that DANE validated successfully, since there is no TLSA record? Stephen. From stephen.nightingale@nist.gov Thu Nov 7 07:17:20 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB63821E8293 for ; Thu, 7 Nov 2013 07:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnSPigzhaDYH for ; Thu, 7 Nov 2013 07:17:08 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 2D50021E829C for ; Thu, 7 Nov 2013 07:17:03 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 10:16:41 -0500 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 7 Nov 2013 10:16:57 -0500 Received: from [127.0.0.1] (31-140.antd.nist.gov [129.6.140.31]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id rA7FGg87004060 for ; Thu, 7 Nov 2013 10:16:44 -0500 Message-ID: <527BAEC0.1030406@nist.gov> Date: Thu, 7 Nov 2013 10:16:16 -0500 From: Stephen Nightingale Organization: NIST User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <527A753A.4040800@nist.gov> <527B820C.1000602@inventati.org> In-Reply-To: <527B820C.1000602@inventati.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: Subject: Re: [dane] NIST DANE Tester Announcement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: night@nist.gov List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:17:20 -0000 On 11/7/2013 7:05 AM, Bry8 Star wrote: >If you do not have domain owner's (TLSA "Usage" case 2's or 3's) TLS/SSL cert or cert-chain file, >then will not your test-result always fail for those TWO "Usage" cases ? For usage 2, Yes. That's probably why Viktor and Wes wrote in section 3.9.2 of their BCP document that TLSA RR 2 publishers must ensure their servers are configured to serve the trust anchor cert as part of a full cert chain, when TLS handshaking. I'm thinking to add annotations to that effect in the test site. Usage 3 specifically does not require PKIX validation, so the root cert non-availability is moot. If DANE comes to be widely deployed and trusted, backed by effective DNSSEC, then it seems likely that Usage 3 will come to be the default mode of operation, as either 301 or 302, for brevity. Perhaps I should repeat parts of the BCP in the respective test cases. Stephen. From viktor1dane@dukhovni.org Thu Nov 7 09:10:21 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF55921E81F9 for ; Thu, 7 Nov 2013 09:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7KUrWoS4dgC for ; Thu, 7 Nov 2013 09:10:16 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6383011E8276 for ; Thu, 7 Nov 2013 09:10:07 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 15ACB2AB0B7; Thu, 7 Nov 2013 17:10:06 +0000 (UTC) Date: Thu, 7 Nov 2013 17:10:06 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131107171006.GC761@mournblade.imrryr.org> References: <789202E67F7415FC98D8FECF@96B2F16665FF96BAE59E9B90> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <789202E67F7415FC98D8FECF@96B2F16665FF96BAE59E9B90> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] review of draft-ietf-dane-smtp-with-dane-02.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:10:22 -0000 On Tue, Nov 05, 2013 at 05:01:54PM -0800, Chris Newman wrote: > I have read draft-ietf-dane-smtp-with-dane-02.txt and support > advancing it on standards track if three changes* are made to the > document as mentioned in my comments below. I believe this is a > plausible strategy to improve security/privacy for SMTP relay and is > close to ready for publication. Thanks for the feedback. The primary points of contention appear to be: - Objection to DANE TLSA for submission. - Objection to requirement to match any of multiple peer names. - Suggestion that SMTP servers not offer TLS if the configured trust chain lacks a suitable TA. - Objection to text recommending anonymous cipher support on the server. My response to each below: - DANE for SMTP Submission * This is good measure a response to RFC6409 which introduces SRV records as a means to offer zeroconf MSA deployments. With the client having no securely obtained name to check in the peer certificate, the peer certificate is unusable, one can check it is valid, but one check that it names the right server. My contention is that MUA + SRV is in the same boat as MTA + MX and the only practical way to make either secure is DANE. Once we have at least one use-case for MUA + DANE, there is also the use case in which the server administrator and MUA user prefer to use DANE. There needs to be standard for this, and an SMTP + DANE RFC seemed like a fine place to cover this. - Objection to multiple peer names. * This was adopted from Tony's expired SRV draft. I agree with the motivation to interoperate with existing practice. It is already common in bilateral SMTP security configurations to field certificates that match the recipient domain, not the MX host. Public CAs even market (I may have misremembered the name) Unified Messaging Certificates. So DANE SMTP clients need to be prepared to encounter certificates tailored to a pre-DANE world. Postfix (widely deployed) supported multiple name values, even before DANE. This is IMHO not a major obstacle. - SMTP server chain sanity checks * This is rather tricky. An SMTP server does not generally know whether it is doing DANE or not, clients know whether they are doing DANE when they obtain (or fail to obtain) appropriate TLSA records. To determine whether it is missing a TA cert, a server would have to look up TLSA records for all relevant domains, locate the MX record that identifies it, obtain the TLSA RRset. If that RRset has usage 2 entries, after (in the SNI use-case) figuring out which chain applies to that domain, it then needs to validate the chain to see whether the required TA is present. I don't see ever implementing this for Postfix. What I did implement is a command-line tool that allows one to probe SMTP server TLS support and determine whether TLS works, including tests of DANE verification when TLSA records are found. Server operators should test their servers from a client that is configured with zero trusted CAs and make sure that DANE works there, when DANE TLSA records are published. We can give some more specific guidance to server operators on testing their deployment, perhaps in the ops draft, but I would not object to additional overlap in the SMTP draft. - Anon ciphers * A substantial fraction of SMTP MTAs enable and will continue to enable anon ciphersuites when not authenticating the server. * The comment in the draft is recommending *server* server support for these. If the client has already sent a HELLO message with a bunch of anon ciphersuites, the server may as well use one, and though it may prefer non-anon ciphers, its TLS stack should not fail just because anon ciphers were offered. > The TLS protocol has interoperability problems if the client hello > has too many cipher suites in it. * This issue may have been substantially addressed yesterday, see the the IETF TLS mailing list thread on ALPIN: http://www.ietf.org/mail-archive/web/tls/current/msg10423.html Avoiding client HELLO with length in [256,512) resolves the SSLv2 vs. SSLv3 HELLO ambiguity. -- Viktor. From chris.newman@oracle.com Thu Nov 7 17:32:44 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A810021E8181 for ; Thu, 7 Nov 2013 17:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.25 X-Spam-Level: X-Spam-Status: No, score=-106.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9oaaNEx9wNm for ; Thu, 7 Nov 2013 17:32:38 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A418621E817C for ; Thu, 7 Nov 2013 17:32:31 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA81WSki027732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 8 Nov 2013 01:32:29 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA81WSwX009558 for ; Fri, 8 Nov 2013 01:32:28 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.102.20] (dhcp-amer-vpn-rmdc-anyconnect-10-159-104-97.vpn.oracle.com [10.159.104.97]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPA id <0MVX00C038A1UG00@gotmail.us.oracle.com> for dane@ietf.org; Thu, 07 Nov 2013 17:32:27 -0800 (PST) Date: Thu, 07 Nov 2013 17:32:26 -0800 From: Chris Newman To: dane@ietf.org Message-id: In-reply-to: <20131107171006.GC761@mournblade.imrryr.org> References: <789202E67F7415FC98D8FECF@96B2F16665FF96BAE59E9B90> <20131107171006.GC761@mournblade.imrryr.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: Re: [dane] review of draft-ietf-dane-smtp-with-dane-02.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 01:32:44 -0000 Thanks for the thoughtful response! --On November 7, 2013 17:10:06 +0000 Viktor Dukhovni wrote: > On Tue, Nov 05, 2013 at 05:01:54PM -0800, Chris Newman wrote: > >> I have read draft-ietf-dane-smtp-with-dane-02.txt and support >> advancing it on standards track if three changes* are made to the >> document as mentioned in my comments below. I believe this is a >> plausible strategy to improve security/privacy for SMTP relay and is >> close to ready for publication. > > Thanks for the feedback. The primary points of contention appear > to be: > > - Objection to DANE TLSA for submission. > > - Objection to requirement to match any of multiple peer names. > > - Suggestion that SMTP servers not offer TLS if the configured trust > chain lacks a suitable TA. > > - Objection to text recommending anonymous cipher support on > the server. > > My response to each below: > > - DANE for SMTP Submission > > * This is good measure a response to RFC6409 which introduces > SRV records as a means to offer zeroconf MSA deployments. I think you meant RFC 6186. Putting on my mail end-user hat, I'm not sufficiently concerned by active attacks during account setup that I'd be willing to spend more money on a mail client to get protection for that. Mail clients that implement 6186 can do the SRV lookup insecurely and then use traditional TLS with the resulting hostnames embedded in the account profile from then on. I believe that will be good enough for most end users and MUA vendors. How many people do you know who verify the SSH fingerprint the first time they connect to a server? > With the client having no securely obtained name to check in > the peer certificate, the peer certificate is unusable, one > can check it is valid, but one check that it names the right > server. > > My contention is that MUA + SRV is in the same boat as MTA + MX > and the only practical way to make either secure is DANE. What evidence do you have that DANE is practical for MUAs? Do you have any significant MUA vendors who want to implement DANE for submission? If RFC 6125 SRV validation deploys in SSL stacks, then MUAs could implement SRV validation for submission with a single function call. The chance an MUA vendor will instead do all the work of embedding a new DNS library to do DNSSEC and DANE seems remote to me. You do have evidence DANE for MTA + MX is practical because you've implemented it and other MTA vendors are paying attention. There also isn't a better option that includes server authentication for the deployed MX infrastructure. Many MTAs already have an embedded DNS library anyway for multi-threaded MX lookups so upgrading it to support DNSSEC seems plausible. I've been in the email standards world for quite a while and this sort of client/server deployment asymmetry is annoying and frustrating when trying to make the infrastructure better, but it's also reality. > - Objection to multiple peer names. > > * This was adopted from Tony's expired SRV draft. I agree with > the motivation to interoperate with existing practice. It is > already common in bilateral SMTP security configurations to > field certificates that match the recipient domain, not the > MX host. Public CAs even market (I may have misremembered > the name) Unified Messaging Certificates. > > So DANE SMTP clients need to be prepared to encounter certificates > tailored to a pre-DANE world. > > Postfix (widely deployed) supported multiple name values, even > before DANE. This is IMHO not a major obstacle. I think Postfix uses OpenSSL. Our MTA uses NSS. The basic certificate validation API in NSS takes a single name, and I haven't yet investigated the extent to which it has callbacks to support multiple names. I generally consider NSS the #2 open source SSL library in terms of deployment as it's used in Thunderbird and Firefox as well as elsewhere. Anyway my concern is that multiple names could be a deployment barrier. So if there's a way to write the standard that didn't require multiple names it might be easier to deploy the standard. However, if it's necessary to support two names to make the model work, then it might be worth additional investigation of how big a barrier it will be and if that barrier can be mitigated. I'll take an action item to investigate the NSS API further to see how easy it is to work around that problem. > - SMTP server chain sanity checks > > * This is rather tricky. An SMTP server does not generally know whether > it is doing DANE or not, clients know whether they are doing DANE > when they obtain (or fail to obtain) appropriate TLSA records. Point taken. I withdraw the suggestion. > - Anon ciphers > > * A substantial fraction of SMTP MTAs enable and will continue > to enable anon ciphersuites when not authenticating the server. I have no problem with this. Those MTAs are free to make that choice. > * The comment in the draft is recommending *server* server support > for these. Why does this draft need to recommend them? It's inviting unnecessary problems and disrespect for other recommendations in the draft. I work on the SSL stack integration for our Messaging Server for IMAP/POP/SMTP/LDAP/etc. I want to keep configuration of that stack as simple as possible to avoid inadvertent security configuration errors. Having a different set of ciphers that are enabled for different purposes makes the product unnecessarily complicated and increases the chances of a security configuration or coding error. I do allow the site admin to do that with configuration if they really want to, but there will be a single default set of ciphers enabled for all uses of SSL/TLS in our product and it won't include the anonymous ciphers. I wouldn't consider changing that because I don't want to explain it in the documentation nor take the risk I'll make a mistake and enable the anon ciphers when they're inappropriate. It can be argued that the presence of the anon ciphers in a TLS stack is a security design error. It's hard enough to get certificate validation right so the server is authenticated (far too much code ignores certificate validation failures). But if it's also necessary to double-check the list of enabled ciphers to make sure authentication works when it's needed, that's just asking for more broken security in the wild. There was a discussion on the NSS developers list about removing the anonymous ciphers from that library. I don't recall the outcome of the discussion, but I'd support their removal simply on the basis that less code is almost always safer. And if they're not in the SSL library they won't be enabled and any recommendation you put in the draft will be ignored. You also might get challenges during IETF last call on this topic for various reasons. That's somewhat less likely now the general attitude in the IETF is more supportive of opportunistic encryption after recent events. But I'd prefer to see this document finished sooner rather than later, so let's drop this unnecessary advice when it's easier to do so rather than later in the process where it can take longer. As a suggestion: the draft might recommend servers log the cipher suite and note that if an anonymous cipher suite is negotiated that the server's log will then indicate no authentication was performed. That's true and non-controversial. >> The TLS protocol has interoperability problems if the client hello >> has too many cipher suites in it. > > * This issue may have been substantially addressed yesterday, > see the the IETF TLS mailing list thread on ALPIN: > > http://www.ietf.org/mail-archive/web/tls/current/msg10423.html > > Avoiding client HELLO with length in [256,512) resolves the > SSLv2 vs. SSLv3 HELLO ambiguity. Glad to hear that! - Chris From viktor1dane@dukhovni.org Thu Nov 7 18:39:19 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2625B11E81BA for ; Thu, 7 Nov 2013 18:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfVCN4oJYGFO for ; Thu, 7 Nov 2013 18:39:13 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3706621F99F3 for ; Thu, 7 Nov 2013 18:39:09 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DF8812AB08F; Fri, 8 Nov 2013 02:39:02 +0000 (UTC) Date: Fri, 8 Nov 2013 02:39:02 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131108023902.GN761@mournblade.imrryr.org> References: <789202E67F7415FC98D8FECF@96B2F16665FF96BAE59E9B90> <20131107171006.GC761@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] review of draft-ietf-dane-smtp-with-dane-02.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 02:39:19 -0000 On Thu, Nov 07, 2013 at 05:32:26PM -0800, Chris Newman wrote: > >- DANE for SMTP Submission > > > > * This is good measure a response to RFC6409 which introduces > > SRV records as a means to offer zeroconf MSA deployments. > > I think you meant RFC 6186. Yes, sorry. > Putting on my mail end-user hat, I'm not > sufficiently concerned by active attacks during account setup that > I'd be willing to spend more money on a mail client to get > protection for that. Mail clients that implement 6186 can do the SRV > lookup insecurely and then use traditional TLS with the resulting > hostnames embedded in the account profile from then on. It makes little sense to deploy SRV records, if all that happens is that the client remembers them after a single lookup and can never change them. In 6186 the client retries the SRV lookup whenever a secure connection fails. This is a mistake, the connection might not fail, and yet the client may reach the wrong place, and find its IMAP account empty, (then purge its local cache, oops, ...) I understand why the authors of 6186 wanted SRV caching, the SRV lookup step was insecure. With DANE, we can do better, and we can protect subsequent reconfiguration when a MITM attack causes the client to try reconfiguration. I am not telling MUAs to do DANE. I am telling them HOW to do DANE. I am encouraging them to do DANE to secure 6186 if they do 6186. Likely for some time they will do neither 6186 nor DANE. > > My contention is that MUA + SRV is in the same boat as MTA + MX > > and the only practical way to make either secure is DANE. > > What evidence do you have that DANE is practical for MUAs? Do you > have any significant MUA vendors who want to implement DANE for > submission? Practical is only a matter of code. Once decent DANE support is in TLS toolkits it will be easy for MUA authors to add DANE support if they so desire. This is not yet as easy as it should, but there is no rush for MUA authors to adopt DANE. > If RFC 6125 SRV validation deploys in SSL stacks, then MUAs could > implement SRV validation for submission with a single function call. > The chance an MUA vendor will instead do all the work of embedding a > new DNS library to do DNSSEC and DANE seems remote to me. It is not possible to securely validate SRV lookup results without DNSSEC. We should not confuse "SRV-ID" subjectAltName values (service@host) with SRV record hostname indirection. There is nothing in 6125 that addresses the problem of SRV record indirection if the TLS peername is understood to be that of the target host, not the hosted domain. The only way to support hosting with certificates that match the hosted domain is with SNI, which scales very poorly. So when a domain's mail (including submission) is hosted by a provider, it should not be necessary for the domain to constantly feed the provider with PKCS#12 key-pairs. DANE makes this unnecessary. > > Postfix (widely deployed) supported multiple name values, even > > before DANE. This is IMHO not a major obstacle. > > I think Postfix uses OpenSSL. Correct. > However, if it's necessary to support two > names to make the model work, then it might be worth additional > investigation of how big a barrier it will be and if that barrier > can be mitigated. I'll take an action item to investigate the NSS > API further to see how easy it is to work around that problem. I think this is important, otherwise verification of the MX (or SRV) hostname alone fails to inteperate with UC certificates. So even if this requires more effort with NSS, that effort will be necessary, possibly by extending NSS to support this across the board, rather than asking each application to add code for this. > > * The comment in the draft is recommending *server* server support > > for these. Well I definitely want to document that servers should definitely not fail when a client presents anon ciphers. > Why does this draft need to recommend them? It's inviting > unnecessary problems and disrespect for other recommendations in the > draft. Because I've run into ignorant auditors who cargo-cult the same nonsense about anon ciphers being insecure with no appreciation for context. An RFC that provides cover for people who know better is a community service. While indeed anon ciphers expose clients to MITM risk (unless protected by a robust inner authentication protocol with channel binding), they DO NOT expose servers to any risk, indeed they expose in server logs the fact that clients were risking MITM attacks, without introducing any possibility of MITM attacks. I have no sympathy for the view that this is too nuanced a point to explain to users and that we need to pretend that anon ciphers are actually a problem on servers. Not offering anon ciphers on servers (where they don't hit the wire causing no interop cost) is just burying one's head in the sand and feeling secure because you don't see the dangerous MITM monster. Once the client sends anon ciphers the deed is done. Postfix SMTP servers only suppress anon ciphers when client certs are required, since in that case, the protocol requires that the server start with its own cert. > Having a different set of ciphers that are enabled for > different purposes makes the product unnecessarily complicated and > increases the chances of a security configuration or coding error. My assertion (based on logic rather than habit) is that *ALL* TLS servers should enable anon ciphers unless they solicit client certs in the initial handshake (in which case they have no choice). > I do allow the site admin to do that with configuration if they really > want to, but there will be a single default set of ciphers enabled > for all uses of SSL/TLS in our product and it won't include the > anonymous ciphers. That's OK, I don't see a MUST in my draft. I am willing to replace the normative "SHOULD" with a neutral "should typically", if that resolves the issue. I am more interested in giving servers operators candid advice about what that choice means than in forcing their hand. - Don't fall over when the client enables anon ciphers - Do consider enabling them on the server, your logs will tell you which clients enable anon ciphers (thus definitely don't e.g. do DANE, ...) > I wouldn't consider changing that because I don't > want to explain it in the documentation nor take the risk I'll make > a mistake and enable the anon ciphers when they're inappropriate. Your product, your call. > It can be argued that the presence of the anon ciphers in a TLS > stack is a security design error. This argument is simply wrong (cargo-cult burying of head in sand). > You also might get challenges during IETF last call on this topic > for various reasons. I'm not too worried. > As a suggestion: the draft might recommend servers log the cipher > suite and note that if an anonymous cipher suite is negotiated that > the server's log will then indicate no authentication was performed. > That's true and non-controversial. With most TLS toolkits servers don't see what the client offered (many ciphers) they see only what the toolkit agreed to! It is impossible to log an agreement on an anon cipher unless the server agrees to one. That's the whole point, and I do want to see the cipher-suite in the logs. Statistics about cipher-suite use are very useful. The above suggestion is basically what I wrote, perhaps we can make that more clear: The purpose of server-side anon cipher support is forensics. The client is not authenticating the server, so no certificate is sent to mask this fact, and this is logged. Clients SHOULD NOT use anon ciphers without good reason (e.g. clearly defined opportunistic use-cases with no use of unverified certs for pinning, ...). > >> The TLS protocol has interoperability problems if the client hello > >> has too many cipher suites in it. > > > > * This issue may have been substantially addressed yesterday, > > see the the IETF TLS mailing list thread on ALPIN: > > > > http://www.ietf.org/mail-archive/web/tls/current/msg10423.html > > > > Avoiding client HELLO with length in [256,512) resolves the > > SSLv2 vs. SSLv3 HELLO ambiguity. > > Glad to hear that! Though there are still some Windows 2003 Microsoft Exchange servers (a small minority but reported from time to time) that fail when RC4-SHA or RC4-MD5 are not among the first 64 ciphers in the client list (nobody will ever need more than 640K^H^H^H^H 64 ciphers in their cipherlist). -- Viktor. From ondrej.sury@nic.cz Fri Nov 8 11:05:08 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779B011E81D1 for ; Fri, 8 Nov 2013 11:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3W96qpmFfdmN for ; Fri, 8 Nov 2013 11:05:07 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0659F11E8112 for ; Fri, 8 Nov 2013 11:03:04 -0800 (PST) Received: from [IPv6:2001:67c:370:152:916:f1d3:ad42:d312] (unknown [IPv6:2001:67c:370:152:916:f1d3:ad42:d312]) by mail.nic.cz (Postfix) with ESMTPSA id A0DF913FD9F; Fri, 8 Nov 2013 20:02:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1383937379; bh=pO5evPzKkKbXPPhPlhgnqv1YGUQ4RUxX1HvRFON0dyY=; h=From:Content-Type:Message-Id:Mime-Version:Subject:Date:References: To:In-Reply-To; b=CWaH7RZojI17Hbr6j5x4SHBBWylcbxf0JRRmkLBhJnKGY5jDzqh8PKYwmh19zpql+ 0ez38RO75OJTRtLirkXgAkqCbDbT7Qf0hzjYfZ2SlwzqV2p0IpJssTkl119tEH32hF iUMT15bMVZ7Yqv7MWzyHi2UdLO+lvUWpp61oZIpg= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: multipart/signed; boundary="Apple-Mail=_CCAA177D-1A05-45E6-BC91-74D32C3D0829"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <02507353-5C1D-428D-8D5C-16D9D231F890@nic.cz> Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Date: Fri, 8 Nov 2013 11:02:49 -0800 References: <522A57C8.8040702@stpeter.im> <20130919202330.GB29796@mournblade.imrryr.org> To: "dane@ietf.org list" , Tony Finch In-Reply-To: X-Mailer: Apple Mail (2.1822) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: Re: [dane] draft-ietf-dane-srv X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 19:05:08 -0000 --Apple-Mail=_CCAA177D-1A05-45E6-BC91-74D32C3D0829 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Tony, since we haven't heard from you last time, we would like to continue = with DANE SRV. We understand you might be very busy at this time, but = if we do not get a response by Friday November 15th (one week) we will = have to appoint new author(s). Ondrej & Warren On 30. 9. 2013, at 11:42, Warren Kumari wrote: >=20 > On Sep 19, 2013, at 7:07 PM, Warren Kumari wrote: >=20 >>=20 >> On Sep 19, 2013, at 4:23 PM, Viktor Dukhovni = wrote: >>=20 >>> On Thu, Sep 19, 2013 at 06:30:59PM +0100, Tony Finch wrote: >>>=20 >>>>> It seems that draft-ietf-dane-srv has expired. Does the document >>>>> editor (and, more important, the WG) still have an interest in = moving >>>>> this forward? >>>>=20 >>>> Yes I would like to. I have been busy at work recently, but I will = try to >>>> find the time to put out an update. >>>=20 >>> Welcome back. >>=20 >> +1.=20 >>=20 >>=20 >>> When you get a chance, please also take a look at >>> the new OPS and SMTP drafts Wes and I put together. Let us know >>> if you have any comments, and of course we should try to avoid >>> conflicts between these and the SRV draft. >>>=20 >>> For example, the new SMTP draft specifies that SMTP servers SHOULD >>> NOT publish TLSA RRs with usages 0/1, both for MTA to MTA traffic >>> and for port 587 when MUAs discover submission hosts via SRV = records. >>> So the SRV draft should not exclude such application-specific >>> specifications. >>>=20 >>=20 >> During the Berlin meeting it was proposed that draft-ietf-dane-smtp = be merged with draft-dukhovni-smtp-opportunistic-tls. >>=20 >> There was overwhelming support in favor of doing so -- I'm assuming = y'all are fine with this? >=20 > Dear Tony, >=20 > Can you please let us know if you have the time (and inclination) to = continue working on a combined draft-ietf-dane-smtp / = draft-dukhovni-smtp-opportunistic-tls document with yourself and Viktor = as co-authors? We understand that you are really busy, and are fine if = you simply do not have the time at the moment=E2=80=A6. >=20 > If we do not get a response by Monday October 7th (one week) we will = have to appoint new author(s). >=20 > W >=20 > [ Apologies for doing this on-list.]=20 >=20 >>=20 >> Also, while catching up=E2=80=A6 >>=20 >> There was a proposal to adopt draft-dukhovni-dane-ops-01.=20 >> There was overwhelming support for doing so, and no objections. I = will initial an onlist call for adoption inna bit=E2=80=A6 >>=20 >> W >>=20 >>> = https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01 >>> https://tools.ietf.org/html/draft-dukhovni-dane-ops-01 >>>=20 >>> with work-in-progress snapshots at: >>>=20 >>> http://vdukhovni.github.io/ietf/ >>>=20 >>> --=20 >>> Viktor. >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>>=20 >>=20 >> --=20 >> Do not meddle in the affairs of wizards, for they are subtle and = quick to anger. =20 >> -- J.R.R. Tolkien >>=20 >>=20 >=20 > -- > "Working the ICANN process is like being nibbled to death by ducks, > it takes forever, it doesn't make sense, and in the end we're still = dead in the water."=20 > -- Tom Galvin, VeriSign's vice president for government relations. >=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- --Apple-Mail=_CCAA177D-1A05-45E6-BC91-74D32C3D0829 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMKTCCBgYw ggTuoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwga8xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVz dGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMzAx BgNVBAMTKlRydXN0ZWQgSW50cm9kdWNlciAoVEkpIFRvcGxldmVsIENBIC0gRzAwMTEnMCUGCSqG SIb3DQEJARYYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMB4XDTA0MTIwNzEwMzYxN1oXDTMwMTIw NjAwMDAwMFowga0xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJ KTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50 cm9kdWNlciAoVEkpIENsaWVudCBDQSAtIEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQt aW50cm9kdWNlci5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOKQxMR3KDUpfJBz AhY2BPCByKo9SMp/V0RIboLBD6vO0miSYO9FmP3Q07OKPYR5WdlQyrpKqB1zl0SRz2cDjnYkzvDF vK5kvMvlTYeQlHypQlvhkTsYWD4ZZxxEhAYBb1s7cYaIahLw6H/RZz+kyWTOc9TncPBvBWIQ1Ypo S+uQqpopH8s5ebtB/17SbUty5yXiHoaPh/ScdMKqxbyJiL0YRM6SU4YX4HVZ5YGS9aWuiUSiA0YF 8dCR56nErx67wgq8O1GtsSKKOf/ueUxSmrqwgQNlfM9Or5O8kb61s1O2iACHtixoV3ENanylBafU mRYpNo5tSZsElGfntMoGBy8CAwEAAaOCAiswggInMB0GA1UdDgQWBBSeX93lU8ExaSlN1ZaXxfOP h2iHTjCB3AYDVR0jBIHUMIHRgBRdbehwJx/8iwlxnguJECc7MUXvoqGBtaSBsjCBrzELMAkGA1UE BhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAoVEkpMSAwHgYDVQQLExdDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTEzMDEGA1UEAxMqVHJ1c3RlZCBJbnRyb2R1Y2VyIChUSSkgVG9wbGV2 ZWwgQ0EgLSBHMDAxMScwJQYJKoZIhvcNAQkBFhhjYUB0cnVzdGVkLWludHJvZHVjZXIubmyCAQAw DwYDVR0TAQH/BAUwAwEB/zAjBgNVHRIEHDAagRhjYUB0cnVzdGVkLWludHJvZHVjZXIubmwwgasG A1UdHwSBozCBoDBOoEygSoZIaHR0cDovL2NybDEudHJ1c3RlZC1pbnRyb2R1Y2VyLm5sL2NhL3g1 MDkvZzEvZGF0YS9jcmxzL2NybC1yb290LWNhLTEuY3JsME6gTKBKhkhodHRwOi8vY3JsMi50cnVz dGVkLWludHJvZHVjZXIubmwvY2EveDUwOS9nMS9kYXRhL2NybHMvY3JsLXJvb3QtY2EtMS5jcmww IwYDVR0RBBwwGoEYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMAsGA1UdDwQEAwIBBjARBglghkgB hvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEFBQADggEBAI1sC2l8st3ElC74az6gH7tGXSiS7jicpHeI 10A3KY+7OEPT7BAJDpjMXxSvAwU1vBDFfwEAXGj42xAPB6cynOTDn0OiFpYGvi3EZV3khXYkGPLs fxZttUyDKqhXcWYy4nnI3fBxqCgLboJFw6OO/SVj5qQdXMZ7VhyFBWJMQkVOnlt6i3xFkG3O5LMI BDmdL5bZPEe8b6bJkMr+rUYEvorPJmV+CkiewYMaruCbdhwRkpkhXB3qLwB2ppnKxSinAU4f9Rcp p73h8iDVQ9389iliUKomVQqj9NJv2G6SyJdDQdN2vrldLszNpw6t+zIzCjpgQ//kem5BJ1k4YG3L CpAwggYbMIIFA6ADAgECAgIGSDANBgkqhkiG9w0BAQUFADCBrTELMAkGA1UEBhMCTkwxIDAeBgNV BAoTF1RydXN0ZWQgSW50cm9kdWNlciAoVEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJbnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEn MCUGCSqGSIb3DQEJARYYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMB4XDTEyMDgwMTA3NTEyNloX DTE0MDgwMTA3NTEyNlowejELMAkGA1UEBhMCTkwxGzAZBgNVBAoTElRydXN0ZWQgSW50cm9kdWNl cjEVMBMGA1UECxMMQ1ouTklDLUNTSVJUMRQwEgYDVQQDEwtPbmRyZWogU3VyeTEhMB8GCSqGSIb3 DQEJARYSb25kcmVqLnN1cnlAbmljLmN6MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA xlmN+hSg6RxWm1X6QOI3OXHSAqhRzWGb8ismR2+3LGDS640luS8x4VdWo490Ceqz+BZvMhQJwfny 9mb0IejFpx7kBOM7k2rMfOYUXa/pq07ysWEI8bXDcXRBf2ZcG0B/gajLPFA9MADlCWHSf7cNZF6S XnIHwTn5DowxpbF403NqLWFnTM08wTJkFgGB7WZAtE6KoSigztI39NrtKRsnosZoBMNZS/JG1CLt VdZPvkHVuiVQWEGYgswBEMGXoR7jtzVNhHr2F1atoBICJVGWFNA8fHvQRLAcXWJTXhKxb2uSq9Yp kKaZPZ6rrp88qtemvwVnQKE9r3/iPFeTARY7AQIDAQABo4ICdTCCAnEwDAYDVR0TAQH/BAIwADAd BgNVHQ4EFgQUgizwG0IeMZQlCSduLVeM1zDBdUEwgdwGA1UdIwSB1DCB0YAUnl/d5VPBMWkpTdWW l8Xzj4doh06hgbWkgbIwga8xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVj ZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMzAxBgNVBAMTKlRydXN0 ZWQgSW50cm9kdWNlciAoVEkpIFRvcGxldmVsIENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FA dHJ1c3RlZC1pbnRyb2R1Y2VyLm5sggECMCMGA1UdEgQcMBqBGGNhQHRydXN0ZWQtaW50cm9kdWNl ci5ubDAdBgNVHREEFjAUgRJvbmRyZWouc3VyeUBuaWMuY3owCwYDVR0PBAQDAgSwMCcGA1UdJQQg MB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwEQYJYIZIAYb4QgEBBAQDAgSwMIHVBgNV HR8Egc0wgcowY6BhoF+GXWh0dHA6Ly9jcmwxLnRydXN0ZWQtaW50cm9kdWNlci5ubC9jYS94NTA5 L2cxL2NhLXNzbC1jbGllbnQvZzEvZGF0YS9jcmxzL2NybC1jbGllbnQtY2EtMS0xLmNybDBjoGGg X4ZdaHR0cDovL2NybDIudHJ1c3RlZC1pbnRyb2R1Y2VyLm5sL2NhL3g1MDkvZzEvY2Etc3NsLWNs aWVudC9nMS9kYXRhL2NybHMvY3JsLWNsaWVudC1jYS0xLTEuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQAZP/dznHW3BWajBVQ3fTaDsx/3csUE6+jX83r1dgzYjUOmapOzXQVZ2/VTwZTzJSsD7rDgzUN6 sk6YWmUJOwqoEcPasYG9zt9e+bpwc/PURjSowb+WjEE2e4L47x3mPgL0dtlGj4guhRaj247K9N1f grvlyX0h/IL9JO4CN0I5lAuOaZ3Yfl0euHpHLlXZ9czxkc6dCbtGSZwr3RrltNmMjhp0O3D51fDd D6mG1vvOEV9Kj1JfSE2cQI5j3GpMlNleZA6noZ93drs2G9/D7WP4uVLCtJfGmG6PJsy4+qN46qXu ekJR/8WH1aNcH0Ya+JsYrwIFPwL4Cr+JXrbFqUOFMYIDzzCCA8sCAQEwgbQwga0xCzAJBgNVBAYT Ak5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBD QSAtIEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwCQYF Kw4DAhoFAKCCAe8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMx MTA4MTkwMjUzWjAjBgkqhkiG9w0BCQQxFgQUvGbDSpPS7RjSDdBEl3lYmc7GzqwwgcUGCSsGAQQB gjcQBDGBtzCBtDCBrTELMAkGA1UEBhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAo VEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJ bnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FAdHJ1c3Rl ZC1pbnRyb2R1Y2VyLm5sAgIGSDCBxwYLKoZIhvcNAQkQAgsxgbeggbQwga0xCzAJBgNVBAYTAk5M MSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBDQSAt IEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwDQYJKoZI hvcNAQEBBQAEggEAvg6FVSEPkv8IY2fHPOrFS75ODG+ZmLRIEuJVILyfNofON1BTAUexoxQIojKF gLtxnRWyMvBILEu+0xb+Yvu7apJd/zFlL64UhtHyaxOG3ErbVCRHBgsim1eg8Ab3dP9xQBrnEUwq /LjbQp8+w32qBvHzmnh+YWIAHt+K+epmUDvzs0u1oFmeAvBV6W3D4Ef4IJVObT7bBEXy9DBhyI91 4DNdi4xE8Af7jSVkE/yqbt8QwIf5ObPJPGrHUrcUhRMTHHhAeAX8JXyWzSXTOR4PgxFVGiVhLswp yzh1PvuEJj2abw5ztglkEl/uY85VEt2YTTK6rO8ebKw43sBHP1Sn8QAAAAAAAA== --Apple-Mail=_CCAA177D-1A05-45E6-BC91-74D32C3D0829-- From paulitrix@gmail.com Thu Nov 14 03:51:12 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE8B21E8095 for ; Thu, 14 Nov 2013 03:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHTJWfMElGjx for ; Thu, 14 Nov 2013 03:51:12 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id D98F321E8090 for ; Thu, 14 Nov 2013 03:51:11 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id fb10so2327027wid.6 for ; Thu, 14 Nov 2013 03:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PbVqdz4X/Ld3vNfgEeCUwAV8p/PyU5pt8xT6FzE1bCI=; b=XHsLciRE8GylJ0/bW+zgEmmi6lnzLhE4bO5vVry5Y+kEd7KEF0iVvgyMJX/f23UfDa oQ09wCtSLXyQP59gQRA1ekj5VelrXGxkpt3jfU9PiSZJMsGMhAClhVgzjT3sH2t6F4l8 mm/NcQpbQxlEe+u5fZWS5W8Y+2p5ooGwUo2Bn+p7VWFXBYTqUNS/2KRwHwvLSLjfMriq WBtGf8zfmqb0goUkwMCtJT9QSeJ0hmPjEkuaxdth94i18n9DpdEwe8zwh+5b1NSmJ2UY +GRz8sYP7MBrsPGqpHjVRbRGH+GhGdZoj6szUho5nCKc1sGjSK8cLEb6VVi9cCy4QDRS lwXg== X-Received: by 10.180.24.137 with SMTP id u9mr2084125wif.5.1384429870919; Thu, 14 Nov 2013 03:51:10 -0800 (PST) Received: from [192.168.33.166] ([41.87.105.66]) by mx.google.com with ESMTPSA id j41sm199962eeg.21.2013.11.14.03.51.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 03:51:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul M In-Reply-To: Date: Thu, 14 Nov 2013 14:51:05 +0300 Content-Transfer-Encoding: 7bit Message-Id: <874E21AD-EE12-4E0E-BDC8-A58174229B87@gmail.com> References: <522A57C8.8040702@stpeter.im> To: Tony Finch X-Mailer: Apple Mail (2.1822) Cc: "dane@ietf.org list" Subject: Re: [dane] draft-ietf-dane-srv X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 11:51:12 -0000 It seems that draft-ietf-dane-srv has expired. Does the document editor (and, more important, the WG) still have an interest in moving this forward? +1 Will find time to read and give my comments. From viktor1dane@dukhovni.org Thu Nov 14 21:45:13 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF7F11E8119 for ; Thu, 14 Nov 2013 21:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40mRiU-h141V for ; Thu, 14 Nov 2013 21:45:09 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8F85411E80FA for ; Thu, 14 Nov 2013 21:45:05 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D0A112AB141; Fri, 15 Nov 2013 05:45:04 +0000 (UTC) Date: Fri, 15 Nov 2013 05:45:04 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131115054504.GK761@mournblade.imrryr.org> References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <20131104223219.GP2976@mournblade.imrryr.org> <1383702043.26498.20.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1383702043.26498.20.camel@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Digest algorithm agility (possible discussion topic for: Informal lunch meeting in Vancouver on Thursday) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 05:45:13 -0000 On Tue, Nov 05, 2013 at 05:40:43PM -0800, Matt McCutchen wrote: > > My proposal is as follows: > > > > When a TLSA RRset contains multiple RRs of the form: > > > > _._tcp.server.example.com. IN TLSA > > > > with the same values of "U" and "S" but different values of the > > matching type, a client MAY ignore a "weaker" matching type > > (deprecated digest algorithm) when a "stronger" matching type for > > the same usage and selector is present. Which matching types are > > considered "weaker" is generally at the client's discretion. > > > - TLSA records that specify multiple certificates or public > > keys for a single (U,S) combination (e.g. multiple trust > > anchors, or multiple EE certificates during key roll-over) > > MUST use the same set of matching types for all of them! > > > > Otherwise, clients may fail to support one of the desired > > certificates, when they choose to support only the RRs with > > the strongest matching type. > > I.e., the same solution that is de facto used by DNSSEC DS records > (https://www.ietf.org/mail-archive/web/dnsext/current/msg11008.html). > > I believe in the need for algorithm agility and proposed three possible > solutions including the above during the original design process > (https://trac.tools.ietf.org/wg/dane/trac/ticket/22), but got no > traction. Thanks, yes, so my proposal requires no changes to the DANE RRset, rather it requires sensible DNS operator practice. For each (usage, selector) combination the mapping: "data" -> SET OF mtype for RRs that correspond to "data" must be the same for all "data" that use the same (usage, selector). I think this is the "Cartesian Product" option in your ticket, but the set of mtypes may differ from one (usage, selector) pair to another. This is now queued for inclusion in the next Postfix snapshot. Details that the group may want to comment on: - Records with mtype "0" are always considered stronger than any hash function for where collisions are unavoidable in principle, even if believed computationally infeasible. - Before choosing the "best" (client selected, not specified by RFC) digest for a particular (usage, selector) pair found in the TLSA RRset, any plainly unusable RRs are discarded: * With "X 0 0", discard RR if the associated data is not an ASN.1 encoding of an X.509 certificate. * With "X 1 0", discard RR if the associated data is not an ASN.1 encoding of an X.509 SPKI structure. * Otherwise, with "X [01] Y" for non-zero "Y", discard the RR when the length of "Y" is not a valid length for digest algorithm "Y". Basically, when all the RRs for a particular mtype (that would otherwise be considered strongest present) are a-priori unusable due to malformed data, we can't be sure whether even the "selector" and "mtype" are valid, after all the record is junk. So it seems reasonable to not impute any meaning to such a record's meta-data in the face of broken data. Otherwise, we commit to failing all all clients that support the apparently stronger algorithm, without in fact knowing where the problem lies. I must admit that of course this is an incomplete solution, some particularly elite domain administrators could replace all the hex E's in their association data with 3's and clearly some clients will again fail. So the strategy does not catch all problems, just the most obvious ones where we would otherwise have to fail when all the records of (apparently) the best mtype are unusable. If the majority feel strongly that one must take as much of a broken record as one can at face value, we should include this in the OPs BCP, and perhaps in any future DANE bis. My preference is to not read any meaning into unusable records. -- Viktor. From matt@mattmccutchen.net Thu Nov 14 22:27:00 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C2611E8107 for ; Thu, 14 Nov 2013 22:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX4ShswhVoXL for ; Thu, 14 Nov 2013 22:26:54 -0800 (PST) Received: from homiemail-a14.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 1833211E80F2 for ; Thu, 14 Nov 2013 22:26:54 -0800 (PST) Received: from homiemail-a14.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTP id 0FF7E392075 for ; Thu, 14 Nov 2013 22:26:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=Rsas1tfuyvIJw7+qgC4XQ517aCM=; b=WW1Qe+pyNn dxyTll/h9sdvGulpXBzKX8G1zHVMh+bLGx6Da2h/C8igkokvLJYXdk56lfmJvQ++ VGYqVRqLvh87LPCGAjbtswtYy24CtxCrH+boqTrWrudSTq8Hnr4dl/XbC3YD8gSs vcqUfv88iT7m+N0eXT3ubM89qrBZ8LB4A= Received: from [192.168.25.104] (unknown [216.239.55.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTPSA id F07A7392070 for ; Thu, 14 Nov 2013 22:26:50 -0800 (PST) Message-ID: <1384496841.1772.8.camel@localhost> From: Matt McCutchen To: dane@ietf.org Date: Thu, 14 Nov 2013 22:27:21 -0800 In-Reply-To: <20131115054504.GK761@mournblade.imrryr.org> References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <20131104223219.GP2976@mournblade.imrryr.org> <1383702043.26498.20.camel@localhost> <20131115054504.GK761@mournblade.imrryr.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Digest algorithm agility (possible discussion topic for: Informal lunch meeting in Vancouver on Thursday) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 06:27:00 -0000 On Fri, 2013-11-15 at 05:45 +0000, Viktor Dukhovni wrote: > On Tue, Nov 05, 2013 at 05:40:43PM -0800, Matt McCutchen wrote: > > > > My proposal is as follows: > > > > > > When a TLSA RRset contains multiple RRs of the form: > > > > > > _._tcp.server.example.com. IN TLSA > > > > > > with the same values of "U" and "S" but different values of the > > > matching type, a client MAY ignore a "weaker" matching type > > > (deprecated digest algorithm) when a "stronger" matching type for > > > the same usage and selector is present. Which matching types are > > > considered "weaker" is generally at the client's discretion. > > > > > - TLSA records that specify multiple certificates or public > > > keys for a single (U,S) combination (e.g. multiple trust > > > anchors, or multiple EE certificates during key roll-over) > > > MUST use the same set of matching types for all of them! > > > > > > Otherwise, clients may fail to support one of the desired > > > certificates, when they choose to support only the RRs with > > > the strongest matching type. > > > > I.e., the same solution that is de facto used by DNSSEC DS records > > (https://www.ietf.org/mail-archive/web/dnsext/current/msg11008.html). > > > > I believe in the need for algorithm agility and proposed three possible > > solutions including the above during the original design process > > (https://trac.tools.ietf.org/wg/dane/trac/ticket/22), but got no > > traction. > > Thanks, yes, so my proposal requires no changes to the DANE RRset, > rather it requires sensible DNS operator practice. For each > (usage, selector) combination the mapping: > > "data" -> SET OF mtype for RRs that correspond to "data" > > must be the same for all "data" that use the same (usage, selector). > I think this is the "Cartesian Product" option in your ticket, but > the set of mtypes may differ from one (usage, selector) pair to another. Right. Sensible as this practice may seem, it's not required by the standard, which may reduce the likelihood that any given zone administrator will be willing to follow it. You may get fewer interoperability failures at the cost of missing some attacks by having the zone opt into an algorithm agility scheme by publishing additional RRs. Matt From viktor1dane@dukhovni.org Thu Nov 14 22:37:39 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603DB11E8107 for ; Thu, 14 Nov 2013 22:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clxb68HAXYDi for ; Thu, 14 Nov 2013 22:37:34 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3660111E80DC for ; Thu, 14 Nov 2013 22:37:34 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CF97B2AB141; Fri, 15 Nov 2013 06:37:32 +0000 (UTC) Date: Fri, 15 Nov 2013 06:37:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131115063732.GL761@mournblade.imrryr.org> References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <20131104223219.GP2976@mournblade.imrryr.org> <1383702043.26498.20.camel@localhost> <20131115054504.GK761@mournblade.imrryr.org> <1384496841.1772.8.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1384496841.1772.8.camel@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Digest algorithm agility (possible discussion topic for: Informal lunch meeting in Vancouver on Thursday) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 06:37:39 -0000 On Thu, Nov 14, 2013 at 10:27:21PM -0800, Matt McCutchen wrote: > > Thanks, yes, so my proposal requires no changes to the DANE RRset, > > rather it requires sensible DNS operator practice. For each > > (usage, selector) combination the mapping: > > > > "data" -> SET OF mtype for RRs that correspond to "data" > > > > must be the same for all "data" that use the same (usage, selector). > > I think this is the "Cartesian Product" option in your ticket, but > > the set of mtypes may differ from one (usage, selector) pair to another. > > Right. > > Sensible as this practice may seem, it's not required by the standard, > which may reduce the likelihood that any given zone administrator will > be willing to follow it. You may get fewer interoperability failures at > the cost of missing some attacks by having the zone opt into an > algorithm agility scheme by publishing additional RRs. Fortunately, there is zero installed base for DANE. So even if RFC 6698 does not require the practice I am suggesting, I can add it to the SMTP draft, and make sure it is implemented in the first MTA to implement DANE (and likely also the second, as Exim developers are likely to work towards a compatible implementation soon). Therefore, it can become standard practice for SMTP from the outset. We can also publish this in the OPs draft, and encourage other protocol implementors (hint: XMPP, ...) to do likewise. It may also be time to start thinking about DANE bis, and this could be one of the additions. So it is far from too late to add this requirement without the complexity of additional new records. Given the "greenfields" state of DANE adoption today, is there a plausible consensus for moving forward with this proposal. Any positive or negative feedback on the processing of a-priori unusable records? -- Viktor. From viktor1dane@dukhovni.org Thu Nov 14 22:55:24 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB3C11E80DC for ; Thu, 14 Nov 2013 22:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCoij-AAd7zT for ; Thu, 14 Nov 2013 22:55:20 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id D25D911E8102 for ; Thu, 14 Nov 2013 22:55:19 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0F7952AB08F; Fri, 15 Nov 2013 06:55:19 +0000 (UTC) Date: Fri, 15 Nov 2013 06:55:19 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131115065518.GM761@mournblade.imrryr.org> References: <68F7E418-B6F1-46C2-9344-00BB6102D940@vpnc.org> <20131104223219.GP2976@mournblade.imrryr.org> <1383702043.26498.20.camel@localhost> <20131115054504.GK761@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131115054504.GK761@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Digest algorithm agility (possible discussion topic for: Informal lunch meeting in Vancouver on Thursday) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 06:55:24 -0000 On Fri, Nov 15, 2013 at 05:45:04AM +0000, Viktor Dukhovni wrote: > Basically, when all the RRs for a particular mtype (that would otherwise > be considered strongest present) are a-priori unusable due to malformed > data, we can't be sure whether even the "selector" and "mtype" are valid, > after all the record is junk. So it seems reasonable to not impute any > meaning to such a record's meta-data in the face of broken data. A closer reading of 6698 seems to support the above: https://tools.ietf.org/html/rfc6698#appendix-B.2 before any processing of the TLSA RRset, we see: for each R in TLSArecords { // unusable records include unknown certUsage, unknown // selectorType, unknown matchingType, erroneous RDATA, and // prohibited by local policy if (R is unusable) { remove R from TLSArecords } } with supporting language in https://tools.ietf.org/html/rfc6698#section-4.1 If a certificate association contains a certificate usage, selector, or matching type that is not understood by the TLS client, that certificate association MUST be considered unusable. If the comparison data for a certificate is malformed, the certificate association MUST be considered unusable. so certainly the malformed "X Y 0" cases are explicitly out of scope, and I think so are the cases where the digest length is absurd. So if the rest of the digest agility proposal is acceptable, the semantics of unusable records in this case are perhaps already defined the way I thought most natural. -- Viktor. From viktor1dane@dukhovni.org Wed Nov 20 13:28:23 2013 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 9CDBD1AE181 for ; Wed, 20 Nov 2013 13:28:23 -0800 (PST) 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 n2GD5HJc8Lfm for ; Wed, 20 Nov 2013 13:28:21 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id A25D61AE157 for ; Wed, 20 Nov 2013 13:28:20 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5C8ED2AB153; Wed, 20 Nov 2013 21:28:13 +0000 (UTC) Date: Wed, 20 Nov 2013 21:28:13 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131120212813.GJ761@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] TLSA lookup impedance mismatch with bare-bones DNS servers 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 Nov 2013 21:28:23 -0000 This week I received the first report of SMTP deliveries consistently deferred due to TLSA RRset lookup problems. The problem site is nist.gov which has a DNSSEC validate MX RRset: $ secdig() { dig +adflag +noall +comments +ans "$@" @8.8.8.8; } $ secdig -t mx nist.gov. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20926 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; ANSWER SECTION: nist.gov. IN MX 0 nist-gov.mail.protection.outlook.com. with the MX host an unsigned zone: $ secdig -t a nist-gov.mail.protection.outlook.com. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3142 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; ANSWER SECTION: nist-gov.mail.protection.outlook.com. 9 IN A 207.46.163.247 nist-gov.mail.protection.outlook.com. 9 IN A 207.46.163.138 nist-gov.mail.protection.outlook.com. 9 IN A 207.46.163.215 So far, so good, but if one tries to obtain TLSA RRs for the SMTP service at this host: $ secdig -t TYPE52 _25._tcp.nist-gov.mail.protection.outlook.com. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63234 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 the remote DNS server responds with SERVFAIL, not NXDOMAIN, even though: $ secdig -t NS _25._tcp.nist-gov.mail.protection.outlook.com. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30308 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 so clearly whatever DNS load-balancing kit is responsible for mail.protection.outlook.com (the problem happens for all names from this domain down) has a rather incomplete DNS implementation. What this means for DANE is that one should try to avoid sending TLSA queries when the TLSA base domain (the desired TCP endpoint) has been discovered to lie in an "insecure" zone. It is extremely unlikely that when "mx.example" is insecure, somehow through the magic of DLV "_port._tcp.mx.example" is secure. Postfix had code to avoid such queries, but it was applied too narrowly (only when sending to non-MX destinations), the next snapshot will have code to suppress TLSA lookups also with insecure MX hosts. Barring a contrary consensus from the group I will add suitable language to the SMTP and the OPS drafts. (The Postfix code will need to implement the work-around regardless, my question is whether the work-around can be stated in the SMTP and/or OPs drafts). Without the work-around, there will be undesirable interoperability issues when TLSA queries are sent to DNS servers that are neither DNSSEC not DANE TLSA aware and may misbehave when presented with unexpected queries. FWIW, the server in question even fails with CNAME or PTR lookups: $ secdig -t CNAME _25._tcp.nist-gov.mail.protection.outlook.com. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38672 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 -- Viktor. From marka@isc.org Wed Nov 20 14:49:20 2013 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 425511AE570 for ; Wed, 20 Nov 2013 14:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, 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 zsSsjVLHH7E6 for ; Wed, 20 Nov 2013 14:49:18 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id ADD731AE531 for ; Wed, 20 Nov 2013 14:49:17 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 83AD92383A7; Wed, 20 Nov 2013 22:48:56 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1E9AC16042E; Wed, 20 Nov 2013 22:55:46 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 176B81603E9; Wed, 20 Nov 2013 22:55:45 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A2886AA9D22; Thu, 21 Nov 2013 09:48:52 +1100 (EST) To: dane@ietf.org From: Mark Andrews References: <20131120212813.GJ761@mournblade.imrryr.org> In-reply-to: Your message of "Wed, 20 Nov 2013 21:28:13 -0000." <20131120212813.GJ761@mournblade.imrryr.org> Date: Thu, 21 Nov 2013 09:48:52 +1100 Message-Id: <20131120224852.A2886AA9D22@rock.dv.isc.org> Cc: hostmaster@nist.gov Subject: Re: [dane] TLSA lookup impedance mismatch with bare-bones DNS servers 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 Nov 2013 22:49:20 -0000 hostmaster@nist.gov your choice of mail handler provider is causing operational problem. In message <20131120212813.GJ761@mournblade.imrryr.org>, Viktor Dukhovni writes: > > This week I received the first report of SMTP deliveries consistently > deferred due to TLSA RRset lookup problems. The problem site is > nist.gov which has a DNSSEC validate MX RRset: > > $ secdig() { dig +adflag +noall +comments +ans "$@" @8.8.8.8; } > > $ secdig -t mx nist.gov. > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20926 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; ANSWER SECTION: > nist.gov. IN MX 0 nist-gov.mail.protection.outlook.com. > > with the MX host an unsigned zone: > > $ secdig -t a nist-gov.mail.protection.outlook.com. > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3142 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 > > ;; ANSWER SECTION: > nist-gov.mail.protection.outlook.com. 9 IN A 207.46.163.247 > nist-gov.mail.protection.outlook.com. 9 IN A 207.46.163.138 > nist-gov.mail.protection.outlook.com. 9 IN A 207.46.163.215 > > So far, so good, but if one tries to obtain TLSA RRs for the SMTP service > at this host: > > $ secdig -t TYPE52 _25._tcp.nist-gov.mail.protection.outlook.com. > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63234 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > the remote DNS server responds with SERVFAIL, not NXDOMAIN, even though: > > $ secdig -t NS _25._tcp.nist-gov.mail.protection.outlook.com. > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30308 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > so clearly whatever DNS load-balancing kit is responsible for > mail.protection.outlook.com (the problem happens for all names > from this domain down) has a rather incomplete DNS implementation. Yep, it returns NOTIMP and the developers didn't think about what the correct response to a query type that you don't load should be. Note a RFC 103[45] server is not permitted to serve a zone that it can't load. TXT and NS records are known types with no special processing. RFC 103[45] say what to return if the name exists and the type doesn't and it isn't NOTIMP. > What this means for DANE is that one should try to avoid sending > TLSA queries when the TLSA base domain (the desired TCP endpoint) > has been discovered to lie in an "insecure" zone. > > It is extremely unlikely that when "mx.example" is insecure, somehow > through the magic of DLV "_port._tcp.mx.example" is secure. > > Postfix had code to avoid such queries, but it was applied too > narrowly (only when sending to non-MX destinations), the next > snapshot will have code to suppress TLSA lookups also with insecure > MX hosts. > > Barring a contrary consensus from the group I will add suitable > language to the SMTP and the OPS drafts. (The Postfix code will > need to implement the work-around regardless, my question is whether > the work-around can be stated in the SMTP and/or OPs drafts). > > Without the work-around, there will be undesirable interoperability > issues when TLSA queries are sent to DNS servers that are neither > DNSSEC not DANE TLSA aware and may misbehave when presented with > unexpected queries. > > FWIW, the server in question even fails with CNAME or PTR lookups: > > $ secdig -t CNAME _25._tcp.nist-gov.mail.protection.outlook.com. > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38672 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > -- > 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 viktor1dane@dukhovni.org Wed Nov 20 15:45:04 2013 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 3460E1AE5B6 for ; Wed, 20 Nov 2013 15:45:04 -0800 (PST) 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 KcXV2t6MAcfC for ; Wed, 20 Nov 2013 15:45:02 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 100FA1AE5C5 for ; Wed, 20 Nov 2013 15:45:00 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D723A2AB14D; Wed, 20 Nov 2013 23:44:53 +0000 (UTC) Date: Wed, 20 Nov 2013 23:44:53 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131120234453.GM761@mournblade.imrryr.org> References: <20131120212813.GJ761@mournblade.imrryr.org> <20131120224852.A2886AA9D22@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131120224852.A2886AA9D22@rock.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] TLSA lookup impedance mismatch with bare-bones DNS servers 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 Nov 2013 23:45:04 -0000 On Thu, Nov 21, 2013 at 09:48:52AM +1100, Mark Andrews wrote: > hostmaster@nist.gov > your choice of mail handler provider is causing operational > problem. Thanks, I've already notified NIST off-list. Any comments on the work-around (avoiding TLSA lookup when the base-domain's A or AAAA record is "insecure")? > > $ secdig -t NS _25._tcp.nist-gov.mail.protection.outlook.com. > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30308 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > > > so clearly whatever DNS load-balancing kit is responsible for > > mail.protection.outlook.com (the problem happens for all names > > from this domain down) has a rather incomplete DNS implementation. > > Yep, it returns NOTIMP and the developers didn't think about what > the correct response to a query type that you don't load should be. If this is useful to anyone, the DNS servers in question are: mail.protection.outlook.com. IN NS ns1-proddns.glbdns.o365filtering.com. mail.protection.outlook.com. IN NS ns2-proddns.glbdns.o365filtering.com. delegated from: protection.outlook.com. IN NS ns2-gtm.glbdns.o365filtering.com. protection.outlook.com. IN NS ns1-gtm.glbdns.o365filtering.com. the latter don't appear to exhibit the problem. > RFC 103[45] say what to return if the name exists and > the type doesn't and it isn't NOTIMP. In this case the name does not exist, so the nameserver should be returning NXDOMAIN, but it snatches defeat from the jaws of victory and indeed returns "NOTIMP": ; <<>> DiG 9.8.0rc1 <<>> +norecur -t TYPE52 _25._tcp.mail.protection.outlook.com. @ns1-proddns.glbdns.o365filtering.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 4960 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 which 8.8.8.8 relayed as SERVFAIL. If there is someone from Microsoft on this list, please forward a pointer to thread to the appropriate interested parties. -- Viktor. From mrex@sap.com Wed Nov 20 16:05:37 2013 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 D59A81AE1E9 for ; Wed, 20 Nov 2013 16:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-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 w1l1aA_3iNiG for ; Wed, 20 Nov 2013 16:05:36 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9AC1AE12B for ; Wed, 20 Nov 2013 16:05:36 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAL05SF2009191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 21 Nov 2013 01:05:28 +0100 (MET) In-Reply-To: <20131120234453.GM761@mournblade.imrryr.org> To: dane@ietf.org Date: Thu, 21 Nov 2013 01:05:28 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131121000528.8BDF61AACA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Subject: Re: [dane] TLSA lookup impedance mismatch with bare-bones DNS servers X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 00:05:38 -0000 Viktor Dukhovni wrote: > > > RFC 103[45] say what to return if the name exists and > > the type doesn't and it isn't NOTIMP. > > In this case the name does not exist, so the nameserver should be > returning NXDOMAIN, but it snatches defeat from the jaws of victory > and indeed returns "NOTIMP": > > ; <<>> DiG 9.8.0rc1 <<>> +norecur -t TYPE52 _25._tcp.mail.protection.outlook.com. @ns1-proddns.glbdns.o365filtering.com. > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 4960 > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > which 8.8.8.8 relayed as SERVFAIL. If there is someone from > Microsoft on this list, please forward a pointer to thread to the > appropriate interested parties. I haven't looked at any of the other stuff (from this discussion), but this latter appears to be a major goof in Googles DNS server. Forwarding NOTIMP (=permanent, do not retry) as a temporary RC (SERVFAIL) is pretty unreasonable on my scorecard. -Martin From marka@isc.org Wed Nov 20 16:21:21 2013 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 E596F1AE1AC for ; Wed, 20 Nov 2013 16:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, 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 VyNHhkb_uodO for ; Wed, 20 Nov 2013 16:21:20 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 0035F1AE1FC for ; Wed, 20 Nov 2013 16:21:19 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 99676C94B8; Thu, 21 Nov 2013 00:21:00 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1384993273; bh=zDIjO6ZaiECAt4o8RAuIyG11/zLa8wFsJa3jBQ6m+Wo=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=aFdj66QcX4wHDs7E/EptQlvHEtBo3OxleCsHHTSmqdWBoyakTZzeD1Qli+5xf/igZ dd0iogqq09afWQNS6hAEh69qVlnEE6zpSCzm5UvIjANPmVzSiKElFZ6fJ758/YaYtK Ox/RF6Nmt/SyjmsdKvy1K3qRnXeIEoy6YfPU6Qwc= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 21 Nov 2013 00:21:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0F1C516042E; Thu, 21 Nov 2013 00:27:51 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id D15C01603E9; Thu, 21 Nov 2013 00:27:50 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0500FAAB027; Thu, 21 Nov 2013 11:20:57 +1100 (EST) To: mrex@sap.com From: Mark Andrews References: <20131121000528.8BDF61AACA@ld9781.wdf.sap.corp> In-reply-to: Your message of "Thu, 21 Nov 2013 01:05:28 +0100." <20131121000528.8BDF61AACA@ld9781.wdf.sap.corp> Date: Thu, 21 Nov 2013 11:20:57 +1100 Message-Id: <20131121002058.0500FAAB027@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dane@ietf.org Subject: Re: [dane] TLSA lookup impedance mismatch with bare-bones DNS servers 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 Nov 2013 00:21:22 -0000 In message <20131121000528.8BDF61AACA@ld9781.wdf.sap.corp>, Martin Rex writes: > Viktor Dukhovni wrote: > > > > > RFC 103[45] say what to return if the name exists and > > > the type doesn't and it isn't NOTIMP. > > > > In this case the name does not exist, so the nameserver should be > > returning NXDOMAIN, but it snatches defeat from the jaws of victory > > and indeed returns "NOTIMP": > > > > ; <<>> DiG 9.8.0rc1 <<>> +norecur -t TYPE52 _25._tcp.mail.protection.outlook.com. @ns1-proddns.glbdns.o365filtering.com. > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 4960 > > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > > > which 8.8.8.8 relayed as SERVFAIL. If there is someone from > > Microsoft on this list, please forward a pointer to thread to the > > appropriate interested parties. > > > I haven't looked at any of the other stuff (from this discussion), > but this latter appears to be a major goof in Googles DNS server. > > Forwarding NOTIMP (=permanent, do not retry) as a temporary > RC (SERVFAIL) is pretty unreasonable on my scorecard. NOTIMP causes a recursive server to try other servers or if it was a EDNS query to try a plain DNS query. REFUSED causes a recursive server to try other servers. SERVFAIL causes a recursive server to try other servers. When you exhaust the list of servers you return SERVFAIL. NOTIMP, REFUSED and SERVFAIL are not authoritative responses. > -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From cloos@jhcloos.com Thu Nov 21 09:11:47 2013 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 20FD21AE215 for ; Thu, 21 Nov 2013 09:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.525, 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 Jgj3VUK32WPY for ; Thu, 21 Nov 2013 09:11:36 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id BBDA41AE21A for ; Thu, 21 Nov 2013 09:11:36 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id B818D1DEF0; Thu, 21 Nov 2013 17:11:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1385053888; bh=D5c6yHi4yVJNjsVj93CFJQYoImp8/+HEoSfmudvR8co=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hRRALBHd8w28uOWK2sahCSs0HGS39wHDf8ZKGbuotFWTc1CdeYb6xOPq4waMj7TZb 4pvOdJizgNIgrbV4UTtCEcdHMoWgHdWrk1qS1tvHNjew1r2ZraUe4fXk0hGiXnBQSN NZZxpCfCkx57asPv/Vk3uPwN1k03ME0SDzfF7RQBn3Q== Received: by carbon.jhcloos.org (Postfix, from userid 500) id B3C8760027; Thu, 21 Nov 2013 17:08:38 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20131120212813.GJ761@mournblade.imrryr.org> (Viktor Dukhovni's message of "Wed, 20 Nov 2013 21:28:13 +0000") References: <20131120212813.GJ761@mournblade.imrryr.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 21 Nov 2013 12:08:38 -0500 Message-ID: Lines: 13 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:131121:dane@ietf.org::TLqscfqHvCKHEdA4:000P93+u X-Hashcash: 1:30:131121:viktor1dane@dukhovni.org::+uxt/gqI4nce+/Ap:000000000000000000000000000000000000O4TRB Subject: Re: [dane] TLSA lookup impedance mismatch with bare-bones DNS servers 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 Nov 2013 17:11:47 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> with the MX host an unsigned zone: Given insecure a/aaaa results, it is reasonable to presume that tlsa resaults also will be insecure. Avoiding the tlsa lookup has the downside of serializing the requests, but that appears to be necessary in the face of b0rked auth servers. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From viktor1dane@dukhovni.org Thu Nov 21 09:29:43 2013 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 A2F221AE21E for ; Thu, 21 Nov 2013 09:29:43 -0800 (PST) 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_14=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 6pJsc5lgcEby for ; Thu, 21 Nov 2013 09:29:42 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7C91AE21A for ; Thu, 21 Nov 2013 09:29:41 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4CCB02AB155; Thu, 21 Nov 2013 17:29:34 +0000 (UTC) Date: Thu, 21 Nov 2013 17:29:34 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131121172934.GS761@mournblade.imrryr.org> References: <20131120212813.GJ761@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] TLSA lookup impedance mismatch with bare-bones DNS servers 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 Nov 2013 17:29:43 -0000 On Thu, Nov 21, 2013 at 12:08:38PM -0500, James Cloos wrote: > Given insecure a/aaaa results, it is reasonable to presume that tlsa > resaults also will be insecure. Thanks, this is on the list for inclusion in the OPS and SMTP drafts. > Avoiding the tlsa lookup has the downside of serializing the requests, > but that appears to be necessary in the face of b0rked auth servers. Yes, though for Postfix the serialization is unavoidable, TLS policy is loaded one MX destination at a time (in preparation for delivery to that destination), after the network address is already in hand. [ The network address is needed early for loop elimination. Postfix determines whether it is an MX host for the destination by comparing network addresses, not hostnames. Therefore the network addresses of all equal-preference hosts need to be available, before delivery to any host at that preference. Hence the $proxy_interfaces parameter for MX hosts behind a NAT. ] Also Postfix + DANE requires a validating resolver on the loopback interface, so latency is a bit less of a concern, at least for high-volume destinations where the local cache amortises lookup latency. -- Viktor. From internet-drafts@ietf.org Sat Nov 23 23:18:53 2013 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 43F7E1ADFA0; Sat, 23 Nov 2013 23:18:53 -0800 (PST) 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 9fEYhc7aNO32; Sat, 23 Nov 2013 23:18:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F2E1AE082; Sat, 23 Nov 2013 23:18:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131124071851.16898.8180.idtracker@ietfa.amsl.com> Date: Sat, 23 Nov 2013 23:18:51 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-03.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: Sun, 24 Nov 2013 07:18:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : SMTP security via opportunistic DANE TLS Author(s) : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-smtp-with-dane-03.txt Pages : 20 Date : 2013-11-23 Abstract: This memo describes a protocol for opportunistic TLS security based on the DANE TLSA DNS record. The protocol is downgrade resistant when the SMTP client supports DANE TLSA and the server domain publishes TLSA records for its MX hosts. This enables an incremental transition of the Internet email backbone (MTA to MTA SMTP traffic) to TLS encrypted and authenticated delivery. 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: http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-smtp-with-dane-03 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 internet-drafts@ietf.org Sat Nov 23 23:35:56 2013 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 998CA1ADF9E; Sat, 23 Nov 2013 23:35:56 -0800 (PST) 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 7L665FCH-n4P; Sat, 23 Nov 2013 23:35:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADCF1AE0AE; Sat, 23 Nov 2013 23:35:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131124073554.16862.64720.idtracker@ietfa.amsl.com> Date: Sat, 23 Nov 2013 23:35:54 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-04.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: Sun, 24 Nov 2013 07:35:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : SMTP security via opportunistic DANE TLS Author(s) : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-smtp-with-dane-04.txt Pages : 20 Date : 2013-11-23 Abstract: This memo describes a protocol for opportunistic TLS security based on the DANE TLSA DNS record. The protocol is downgrade resistant when the SMTP client supports DANE TLSA and the server domain publishes TLSA records for its MX hosts. This enables an incremental transition of the Internet email backbone (MTA to MTA SMTP traffic) to TLS encrypted and authenticated delivery. 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: http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-smtp-with-dane-04 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 viktor1dane@dukhovni.org Sat Nov 23 23:42:58 2013 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 BE1941AE0E6 for ; Sat, 23 Nov 2013 23:42:58 -0800 (PST) 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 oL7guL0t9G-F for ; Sat, 23 Nov 2013 23:42:57 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 635941AE0D9 for ; Sat, 23 Nov 2013 23:42:57 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 55E0D2AB15E; Sun, 24 Nov 2013 07:42:49 +0000 (UTC) Date: Sun, 24 Nov 2013 07:42:49 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131124074249.GH761@mournblade.imrryr.org> References: <20131124073554.16862.64720.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131124073554.16862.64720.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-04.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: Sun, 24 Nov 2013 07:42:58 -0000 On Sat, Nov 23, 2013 at 11:35:54PM -0800, internet-drafts@ietf.org wrote: > Title : SMTP security via opportunistic DANE TLS > Author(s) : Viktor Dukhovni, Wes Hardaker > Filename : draft-ietf-dane-smtp-with-dane-04.txt This is a bugfix update to 03. The new material in 03 is a description of digest algorithm agility. The text describing anonymous cipher support should now be more acceptable, it does not say servers SHOULD support these, rather server MUST NOT fail to interoperate merely because some anon ciphersuites are offered. -- Viktor. From viktor1dane@dukhovni.org Sun Nov 24 13:28:56 2013 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 E53571AE349 for ; Sun, 24 Nov 2013 13:28:56 -0800 (PST) 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 MQMO8RhQnRJw for ; Sun, 24 Nov 2013 13:28:55 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id E64951AE342 for ; Sun, 24 Nov 2013 13:28:54 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6A9352AB15E; Sun, 24 Nov 2013 21:28:45 +0000 (UTC) Date: Sun, 24 Nov 2013 21:28:45 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131124212845.GJ761@mournblade.imrryr.org> References: <20131124073554.16862.64720.idtracker@ietfa.amsl.com> <20131124074249.GH761@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131124074249.GH761@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-04.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: Sun, 24 Nov 2013 21:28:57 -0000 On Sun, Nov 24, 2013 at 07:42:49AM +0000, Viktor Dukhovni wrote: > On Sat, Nov 23, 2013 at 11:35:54PM -0800, internet-drafts@ietf.org wrote: > > > Title : SMTP security via opportunistic DANE TLS > > Author(s) : Viktor Dukhovni, Wes Hardaker > > Filename : draft-ietf-dane-smtp-with-dane-04.txt > > This is a bugfix update to 03. The new material in 03 is a > description of digest algorithm agility. Here it is for your comments, extracted from the draft: === Digest algorithm agility While RFC 6698 specifies multiple digest algorithms, it does not explicitly specify a protocol by which the SMTP 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 campatibilty with less capable clients, but should if possible be ignored. We specify such a protocol below. Suppose that a DANE TLS client authenticating TLS server considers digest algorithm X stronger than digest algorithm Y. Suppose further that that a server's TLSA RRset contains some records with X as the digest algorithm. Suppose that for every raw public key or certificate object that is included in the server's TLSA RRset in digest form, whenever that object appears with digest Y (with some usage and selector) it also appears with digest X (with the same usage and selector). In that case our client can safely ignore TLSA records with the weaker digest Y, because it suffices to check the records with the stronger algorithm X. We take the simplest appraoch and mandate that all published TLSA RRsets conform to the above assumptions. Then clients can unconditionally ignore all but the (equal) strongest digest records with a given usage and selector. The ordering of digest algorithms by strength is entirely up to the client. Only the future will tell which algoritms might be weakened by new attacks and when. Therefore, server operators MUST ensure that for any given usage and selector, ALL objects with certificate association data with that usage and selector that are published with a digest matching type are published with the SAME SET of digests (non-zero matching types). In other words, for each usage and selector, the records with non-zero matching types will be a cross-product of a set of underlying objects and a fixed set of digests that apply uniformly to all the objects. Records with a matching type of "0", that publish the full object value play no role in digest algorithm agility. They neither preempt the processing of records that employ digests, nor are they ignored in the presence of any digest records. SMTP clients SHOULD use digest algorithm agility when processing the DANE TLSA records of an SMTP 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 only process any usable records with a matching type of "0" and any usable records whose digest is believed to be the strongest among usable records with the same usage and selector. The main impact of this requirement is on key rotation, when the TLSA RRset is pre-populated with digests of new certificates or public keys, before these replace or augment their predecessors. Were the newly introduced RRs to include previously unused digest algorithms, clients that employ this protocol could potentially ignore all the digests corresponding to the currently deployed certificates causing connectivity issues until the new keys or certificates are deployed. Similarly, publishing new records with fewer digests could cause problems once the new keys are deployed. Server operators SHOULD follow the following rules. When adding or removing objects from the TLSA RRset (e.g. during key rotation), DO NOT change the set of digests used, change just the list of objects. When changing the set of digests used, change only the set of digests, and generate a new RRset in which all the current objects are re-published with the new set of digests. The client-side of this "digest algorithm agility" protocol is enabled by default in the first DANE for SMTP implementation. For key rotation to work non-disruptively server operators MUST ensure that their TLSA records conform with the above specification. -- Viktor.