From nobody Thu Sep 8 01:21:01 2016 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 E80F112B421 for ; Thu, 8 Sep 2016 01:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.13 X-Spam-Level: X-Spam-Status: No, score=-104.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 PugRLm4VjUf6 for ; Thu, 8 Sep 2016 01:20:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC1712B41F for ; Thu, 8 Sep 2016 01:20:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 39306B80ABD; Thu, 8 Sep 2016 01:20:56 -0700 (PDT) To: pwouters@redhat.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, warren@kumari.net, ogud@ogud.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160908082056.39306B80ABD@rfc-editor.org> Date: Thu, 8 Sep 2016 01:20:56 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, dkg@fifthhorseman.net, dane@ietf.org Subject: [dane] [Technical Errata Reported] RFC7929 (4796) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 08 Sep 2016 08:21:00 -0000 The following errata report has been submitted for RFC7929, "DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7929&eid=4796 -------------------------------------- Type: Technical Reported by: Daniel Kahn Gillmor Section: 3 Original Text ------------- 6. The domain name (the "right-hand side" of the email address, called the "domain" in [RFC5322]) is appended to the result of step 2 to complete the prepared domain name. Corrected Text -------------- 6. The domain name (the "right-hand side" of the email address, called the "domain" in [RFC5322]) is appended to the result of step 5 to complete the prepared domain name. Notes ----- Technically, it should be step 5, not step 2: after step 2, there is no _openpgpkey label in the composed domain name. step 5 adds the _openpgpkey label. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7929 (draft-ietf-dane-openpgpkey-12) -------------------------------------- Title : DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP Publication Date : August 2016 Author(s) : P. Wouters Category : EXPERIMENTAL Source : DNS-based Authentication of Named Entities Area : Security Stream : IETF Verifying Party : IESG From nobody Thu Sep 8 06:05:56 2016 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 8986F12B45B for ; Thu, 8 Sep 2016 06:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 znnQziD3uDxp for ; Thu, 8 Sep 2016 06:05:50 -0700 (PDT) Received: from poretsky.uvt.nl (poretsky.uvt.nl [IPv6:2001:610:1410:0:5122:6ff4:e9c9:84ce]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C009D12B65F for ; Thu, 8 Sep 2016 05:40:06 -0700 (PDT) Received: by poretsky.uvt.nl (Postfix, from userid 116) id 70247C022C1; Thu, 8 Sep 2016 14:40:03 +0200 (CEST) Received: from localhost by poretsky (rewritefishurl); Thu, 8 Sep 2016 14:40:03 +0200 Received: from localhost (localhost [IPv6:::1]) by poretsky.uvt.nl (Postfix) with ESMTP id 683ACC000BB for ; Thu, 8 Sep 2016 14:40:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at uvt.nl X-Spam-Cookie: ecb13d25dfa0be0d66a72d432d2ef41a8fa2338a Received: from lambert.uvt.nl ([IPv6:2001:610:1410:0:55c7:8a48:39f2:4256]) by localhost (poretsky.uvt.nl [IPv6:2001:610:1410:0:5122:6ff4:e9c9:84ce]) (amavisd-new, port 10024) with ESMTP id KbztrDmkkJTO for ; Thu, 8 Sep 2016 14:40:03 +0200 (CEST) Received: from [::1] (localhost [::1]) (Authenticated sender: cgielen) by lambert.uvt.nl (Postfix) with ESMTPSA id 2A3E48800ED From: Casper Gielen To: dane@ietf.org References: <20160826013552.GR4670@mournblade.imrryr.org> Message-ID: <0f2e3307-bd37-a38a-5e4d-e43d52133af6@uvt.nl> Date: Thu, 8 Sep 2016 14:39:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4so1fJo0LCEn1e6hwdDNCIBD2gFdN01kR" Archived-At: Subject: Re: [dane] Nudge DANE SMTP adoption at DNSSEC-signed MX hosting providers X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 08 Sep 2016 13:05:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4so1fJo0LCEn1e6hwdDNCIBD2gFdN01kR Content-Type: multipart/mixed; boundary="01STgD9NPXB4DJtV5FRSeGnXEd60N7v1I" From: Casper Gielen To: dane@ietf.org Message-ID: <0f2e3307-bd37-a38a-5e4d-e43d52133af6@uvt.nl> Subject: Re: [dane] Nudge DANE SMTP adoption at DNSSEC-signed MX hosting providers References: <20160826013552.GR4670@mournblade.imrryr.org> In-Reply-To: --01STgD9NPXB4DJtV5FRSeGnXEd60N7v1I Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Op 29-08-16 om 15:27 schreef Casper Gielen: > Hi there, >=20 > uvt.nl here, we are working towards deploying DANE on all our zones and= > have most of the pieces in place. There's an issue with monitoring that= > needs to be fixed before we can go live. We expect to deploy before the= > end of the year, probably much sooner. done --=20 Casper Gielen | LIS UNIX PGP fingerprint =3D 16BD 2C9F 8156 C242 F981 63B8 2214 083C F80E 4AF7 Universiteit van Tilburg | Postbus 90153, 5000 LE Warandelaan 2 | Telefoon 013 466 4100 | G 236 | http://www.uvt.nl --01STgD9NPXB4DJtV5FRSeGnXEd60N7v1I-- --4so1fJo0LCEn1e6hwdDNCIBD2gFdN01kR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlfRXB0ACgkQIhQIPPgOSvdt7gCfdjXtjE9EjV9YsaMVw6geE8dn qmoAoIXd4pMmbotG+S6vu6ldVTuDJygc =vXXT -----END PGP SIGNATURE----- --4so1fJo0LCEn1e6hwdDNCIBD2gFdN01kR-- From nobody Thu Sep 8 06:30:52 2016 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 AE79812B196 for ; Thu, 8 Sep 2016 06:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.41 X-Spam-Level: X-Spam-Status: No, score=-8.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wr7G2OmgW2Px for ; Thu, 8 Sep 2016 06:30:49 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7834012B353 for ; Thu, 8 Sep 2016 06:21:12 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0C20861E73; Thu, 8 Sep 2016 13:21:11 +0000 (UTC) Received: from thinkpad.nohats.ca (vpn-232-31.phx2.redhat.com [10.3.232.31]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u88DL8PV010263; Thu, 8 Sep 2016 09:21:08 -0400 To: RFC Errata System , stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, warren@kumari.net, ogud@ogud.com References: <20160908082056.39306B80ABD@rfc-editor.org> From: Paul Wouters Message-ID: <403d4d1e-b79e-52b5-38c9-b6f97c047511@redhat.com> Date: Thu, 8 Sep 2016 09:21:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160908082056.39306B80ABD@rfc-editor.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 08 Sep 2016 13:21:11 +0000 (UTC) Archived-At: Cc: dkg@fifthhorseman.net, dane@ietf.org Subject: Re: [dane] [Technical Errata Reported] RFC7929 (4796) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 08 Sep 2016 13:30:51 -0000 On 09/08/2016 04:20 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC7929, > "DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7929&eid=4796 > > -------------------------------------- > Type: Technical > Reported by: Daniel Kahn Gillmor > > Section: 3 > > Original Text > ------------- > 6. The domain name (the "right-hand side" of the email address, > called the "domain" in [RFC5322]) is appended to the result of > step 2 to complete the prepared domain name. > > > Corrected Text > -------------- > 6. The domain name (the "right-hand side" of the email address, > called the "domain" in [RFC5322]) is appended to the result of > step 5 to complete the prepared domain name. > > > Notes > ----- > Technically, it should be step 5, not step 2: after step 2, there is no _openpgpkey label in the composed domain name. step 5 adds the _openpgpkey label. > This errata is correct. The original text did not have the intermediary steps listed as such, and no one spotted referenced number when the numbering changed :( Paul From nobody Thu Sep 8 06:34:22 2016 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 236F312B015; Thu, 8 Sep 2016 06:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.13 X-Spam-Level: X-Spam-Status: No, score=-104.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 Ih2Vl9CVusAy; Thu, 8 Sep 2016 06:34:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B32612B2E2; Thu, 8 Sep 2016 06:27:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 55B21B80B2D; Thu, 8 Sep 2016 06:27:53 -0700 (PDT) To: dkg@fifthhorseman.net, pwouters@redhat.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160908132753.55B21B80B2D@rfc-editor.org> Date: Thu, 8 Sep 2016 06:27:53 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, dane@ietf.org, iesg@ietf.org Subject: [dane] [Errata Verified] RFC7929 (4796) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 08 Sep 2016 13:34:14 -0000 The following errata report has been verified for RFC7929, "DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7929&eid=4796 -------------------------------------- Status: Verified Type: Technical Reported by: Daniel Kahn Gillmor Date Reported: 2016-09-08 Verified by: Stephen Farrell (IESG) Section: 3 Original Text ------------- 6. The domain name (the "right-hand side" of the email address, called the "domain" in [RFC5322]) is appended to the result of step 2 to complete the prepared domain name. Corrected Text -------------- 6. The domain name (the "right-hand side" of the email address, called the "domain" in [RFC5322]) is appended to the result of step 5 to complete the prepared domain name. Notes ----- Technically, it should be step 5, not step 2: after step 2, there is no _openpgpkey label in the composed domain name. step 5 adds the _openpgpkey label. -------------------------------------- RFC7929 (draft-ietf-dane-openpgpkey-12) -------------------------------------- Title : DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP Publication Date : August 2016 Author(s) : P. Wouters Category : EXPERIMENTAL Source : DNS-based Authentication of Named Entities Area : Security Stream : IETF Verifying Party : IESG From nobody Sat Sep 10 16:38:22 2016 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 BC61912B1EC for ; Sat, 10 Sep 2016 16:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 UX5vPcKxwP90 for ; Sat, 10 Sep 2016 16:38:20 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66E2712B145 for ; Sat, 10 Sep 2016 16:38:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2BE14282FA8; Sat, 10 Sep 2016 23:38:19 +0000 (UTC) Date: Sat, 10 Sep 2016 23:38:19 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160910233818.GZ4670@mournblade.imrryr.org> References: <20160826013552.GR4670@mournblade.imrryr.org> <0f2e3307-bd37-a38a-5e4d-e43d52133af6@uvt.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f2e3307-bd37-a38a-5e4d-e43d52133af6@uvt.nl> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] Nudge DANE SMTP adoption at DNSSEC-signed MX hosting providers X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2016 23:38:22 -0000 On Thu, Sep 08, 2016 at 02:39:57PM +0200, Casper Gielen wrote: > > uvt.nl here, we are working towards deploying DANE on all our zones and > > have most of the pieces in place. There's an issue with monitoring that > > needs to be fixed before we can go live. We expect to deploy before the > > end of the year, probably much sooner. > > done Thanks, that makes for 180 new domains in my survey, out of a grand total of 59100 as of today. Two of them, uvt.nl, and tilburguniversity.edu had even generated enough volume back and forth from Gmail to make the list of 71 domains in my survey that also have appeared in Gmail's transparency report in the recent past. With a bit of luck some of the other "nudgees" will also deploy soon. -- Viktor. P.S. I curious about the actual number of your 2LD DNSSEC domains that have some subset of {a,b,c,d}.mx.uvt.nl for their MX records. That is, how well am I doing at finding them all. From nobody Tue Sep 13 11:37:32 2016 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 CFDC512B4D0 for ; Tue, 13 Sep 2016 11:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 psn8zYLcrB47 for ; Tue, 13 Sep 2016 11:37:28 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9765912B00E for ; Tue, 13 Sep 2016 11:37:27 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id 38so93867334qte.1 for ; Tue, 13 Sep 2016 11:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ClaidcSq2zDeWnZ21Z23CcEW+NaE8X2uUU9SySxml5o=; b=fnqmOQGTXDmGQFdCRhU4sGdLfOWidNY9pqaD3QJSHnwBTwEdC8c7MQZ5Csgda28g9N 5V1CRXx7vOgEx2tb/zAVM7D8SNlM3n36Q7SHYQ+ArUh2Ej7x6mEVrtz1Au8DtZGD1gyE KoeJx8FBc0y9N6PgLiaO5//YF82DEjw8ZNBrLp5MqdbDraxZoKQaurrIN2ytoNTA1QpL 1xEf5l0ZsJ3cnKoTVIzUAyIWRVR1Q2clrhf4Oh0m0/bNlcFlr9nC1w+mgbw6rMqQjq1o EER+dddp/5ntnaprHToIE1b8vziNk8bpL6xqSEdlvabCtyIbMUYUOxObLmJv13FYX8eD 9LAQ== 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:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ClaidcSq2zDeWnZ21Z23CcEW+NaE8X2uUU9SySxml5o=; b=g6sDEsKCGD525fli7FJ1g8r62wkXDnyIlVvjOLhyUfzfhsDkMGBgMMduE2R7XNcQGO TS833FI/RNOaM4dhfCFBuvdFCT/yKAYHY6jfH1j4O/kRWVfDyF6GrhEng3ZW5R6hA1uC yq7NvGYGw67d333hKCm9rCNdJMVXDf1fTtjrzX/vYhKKlCFusic8/MZw8cgBwq0RKsim tqstqZXBcbiaFrxjeZ5RPAGK208Gb0ZVNhP6K3NeHi9cf7KJOcRSdvoqDeADWLfP6YCv HOSEp59UpYKKc92yI88FAJ0T30I3Amm0C/N+f6B9LaKkDtQEtc0jmyYNgr1UvFzpKHYJ dLrA== X-Gm-Message-State: AE9vXwPOwNKtEh8uRJ2YQOVVL5SieOXZX9F8QgMt0kaYNBU3peSalxEXajbdBJlm19wkClbiZyRZ10tVC1eKFXYV X-Received: by 10.200.53.235 with SMTP id l40mr2884926qtb.47.1473791846620; Tue, 13 Sep 2016 11:37:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.147.196 with HTTP; Tue, 13 Sep 2016 11:36:56 -0700 (PDT) In-Reply-To: <20130416221817.82228B1E003@rfc-editor.org> References: <20130416221817.82228B1E003@rfc-editor.org> From: Warren Kumari Date: Tue, 13 Sep 2016 14:36:56 -0400 Message-ID: To: RFC Errata System Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" , Viktor Dukhovni , Paul Hoffman , Sean Turner Subject: Re: [dane] [Technical Errata Reported] RFC6698 (3594) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 13 Sep 2016 18:37:31 -0000 Hello all, So, this errata was filed, but it seems never officially closed out - RFC6698 was updated by RFC7671 - "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance". What would the WG (especially the submitter) like us to do with this errata? I *think* that it can be rejected, but that feels like a process issue. Hold for update feels like it might be best, even though it's been done? W On Tue, Apr 16, 2013 at 6:18 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC6698, > "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Se= curity (TLS) Protocol: TLSA". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6698&eid=3D3594 > > -------------------------------------- > Type: Technical > Reported by: Viktor Dukhovni > > Section: 2.1.1 > > Original Text > ------------- > 2 -- Certificate usage 2 is used to specify a certificate, or the > public key of such a certificate, that MUST be used as the trust > anchor when validating the end entity certificate given by the > server in TLS. This certificate usage is sometimes referred to as > "trust anchor assertion" and allows a domain name administrator to > specify a new trust anchor -- for example, if the domain issues > its own certificates under its own CA that is not expected to be > in the end users' collection of trust anchors. The target > certificate MUST pass PKIX certification path validation, with any > certificate matching the TLSA record considered to be a trust > anchor for this certification path validation. > > Corrected Text > -------------- > 2 -- Certificate usage 2 is used to specify a certificate, or the > public key of such a certificate, that MUST be used as the trust > anchor when validating the end entity certificate given by the > server in TLS. This certificate usage is sometimes referred to as > "trust anchor assertion" and allows a domain name administrator to > specify a new trust anchor -- for example, if the domain issues > its own certificates under its own CA that is not expected to be > in the end users' collection of trust anchors. The target > certificate MUST pass PKIX certification path validation, with any > certificate matching the TLSA record considered to be a trust > anchor for this certification path validation. Since clients canno= t > be presumed to have their own copy of the trust-anchor certificate, > when the TLSA association specifies a certificate digest, the TLS > server MUST be configured to provide the trust-anchor certificate i= n > its "certificate_list" TLS handshake message. > > > Notes > ----- > This is critical for interoperability between clients and servers. A cli= ent that commits to verify TLSA RR certificate associations will fail if it= can't obtain the required certificates. With usage "2" there is no presum= ption that these are available to the client. If servers are not obligated= to provide them the protocol will consistently fail. With non-interactive= protocols where there is no user to "click OK", such as SMTP, there is no = good work-around and both client and server owners suffer. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6698 (draft-ietf-dane-protocol-23) > -------------------------------------- > Title : The DNS-Based Authentication of Named Entities (DAN= E) Transport Layer Security (TLS) Protocol: TLSA > Publication Date : August 2012 > Author(s) : P. Hoffman, J. Schlyter > Category : PROPOSED STANDARD > Source : DNS-based Authentication of Named Entities > Area : Security > Stream : IETF > Verifying Party : IESG > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Sep 13 16:54:16 2016 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 E5D2812B156 for ; Tue, 13 Sep 2016 16:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 iTd9EEbnqbCw for ; Tue, 13 Sep 2016 16:54:13 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96BA12B145 for ; Tue, 13 Sep 2016 16:53:39 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 50C10282F88; Tue, 13 Sep 2016 23:53:38 +0000 (UTC) Date: Tue, 13 Sep 2016 23:53:38 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160913235337.GP4670@mournblade.imrryr.org> References: <20130416221817.82228B1E003@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] [Technical Errata Reported] RFC6698 (3594) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 23:54:15 -0000 On Tue, Sep 13, 2016 at 02:36:56PM -0400, Warren Kumari wrote: > So, this errata was filed, but it seems never officially closed out - > RFC6698 was updated by RFC7671 - "The DNS-Based Authentication of > Named Entities (DANE) Protocol: Updates and Operational Guidance". Which addressed the issue by adding the missing requirement. > What would the WG (especially the submitter) like us to do with this > errata? I *think* that it can be rejected, but that feels like a > process issue. Hold for update feels like it might be best, even > though it's been done? I am not familiar with (and not terribly interested in) process issues. The erratum is moot. Do as you think best. -- Viktor. From nobody Tue Sep 13 17:29:04 2016 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 A8A1E12B464 for ; Tue, 13 Sep 2016 17:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 4UfYj4x2AktE for ; Tue, 13 Sep 2016 17:29:00 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C3812B511 for ; Tue, 13 Sep 2016 17:28:53 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id 93so862239qtg.2 for ; Tue, 13 Sep 2016 17:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zP9jTYf9RRlnCX7eGJKofA1C6+19GaxExmfIvJumre0=; b=p2HXpe+37VTekdoQ8EB97fh9M4vsWYnPmGYP2EYxtD0azOCQC5YnaPpYZofpS8KIgV revz3l4syEjYg4Q70vOWCj5e2ogmUTqIvsDUgLyBWVReAVanF335nAYpmuGnGIq2a+e3 HWPCzF+td9Jol7zDXIlkP5IePOXDSBg7D4PD59pCLY0651WbvBqaa/l9VPE4navL94yS ERc6jhHEjstdim2mCf3PbWYnjxDweVqNxka7RWRTE1vYrmFpb5DBSa5TsLFRo3mEnx0a GMzFvD1rqs6xTdauu3oWwmJSXgpGpODvmJ1QwLPAcSNEdUfSCgSQNjvY6kBnYZ9bHBKY xUAw== 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:from:date :message-id:subject:to; bh=zP9jTYf9RRlnCX7eGJKofA1C6+19GaxExmfIvJumre0=; b=WUddmWfoVtKBU/sMfNya65BwDCN5rt9wSCC88WWkvB65CCHBSCp7rK4aKjJNQuwixF gysRWenYnmLzakbbfMPNY8YMNKWOdCoiC/Jw7NF+xOALDynuhLLCbLX3hb9rGDzaRrlD mh3gOPB0ocmvqXeW5rm7LXaETmgL1aUuKi9Vuh+6FgPqZPYlmm/uZqWkp2YUMxRzb4p2 RaKG2BNQUBshlf9joPvu2DzTeBGrkfxS6ebtVI1bsulKtj1EVQY9aOPyJxGqzsTK8We6 aNzAwPfettJ/4ve3DrI0QD81O64KvmotT7NUAUuE3umnT/YkOILEQbDz5AQlxRBYz2a5 /gew== X-Gm-Message-State: AE9vXwNwEMgj4bB845zFhVC00hFoqIgbJirofoKYWfPIa3LZUB4DY4/6kNfdSBfpmn9TJgjb+ASubSQgNmcukvr0 X-Received: by 10.237.41.131 with SMTP id o3mr4724905qtd.57.1473812932346; Tue, 13 Sep 2016 17:28:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.147.196 with HTTP; Tue, 13 Sep 2016 17:28:51 -0700 (PDT) In-Reply-To: <20160913235337.GP4670@mournblade.imrryr.org> References: <20130416221817.82228B1E003@rfc-editor.org> <20160913235337.GP4670@mournblade.imrryr.org> From: Warren Kumari Date: Tue, 13 Sep 2016 20:28:51 -0400 Message-ID: To: "dane@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0bfb5c4cc294053c6cd0ad Archived-At: Subject: Re: [dane] [Technical Errata Reported] RFC6698 (3594) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 14 Sep 2016 00:29:03 -0000 --94eb2c0bfb5c4cc294053c6cd0ad Content-Type: text/plain; charset=UTF-8 On Tuesday, September 13, 2016, Viktor Dukhovni wrote: > On Tue, Sep 13, 2016 at 02:36:56PM -0400, Warren Kumari wrote: > > > So, this errata was filed, but it seems never officially closed out - > > RFC6698 was updated by RFC7671 - "The DNS-Based Authentication of > > Named Entities (DANE) Protocol: Updates and Operational Guidance". > > Which addressed the issue by adding the missing requirement. > > Yup. > > What would the WG (especially the submitter) like us to do with this > > errata? I *think* that it can be rejected, but that feels like a > > process issue. Hold for update feels like it might be best, even > > though it's been done? > > I am not familiar with (and not terribly interested in) process > issues. The erratum is moot. Do as you think best. Yeah, this is entirely process wonkery; I just didn't want the WG to be surprised / to give y'all a chance to express a preference (if anyone has one). W > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --94eb2c0bfb5c4cc294053c6cd0ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, September 13, 2016, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
On Tue, Sep 13, 2016 at 02:36:56PM -0400, Warren Ku= mari wrote:

> So, this errata was filed, but it seems never officially closed out -<= br> > RFC6698 was updated by RFC7671 - "The DNS-Based Authentication of=
> Named Entities (DANE) Protocol: Updates and Operational Guidance"= .

Which addressed the issue by adding the missing requirement.


Yup.
=C2=A0
> What would the WG (especially the submitter) like us to do with this > errata? I *think* that it can be rejected, but that feels like a
> process issue. Hold for update feels like it might be best, even
> though it's been done?

I am not familiar with (and not terribly interested in) process
issues.=C2=A0 The erratum is moot.=C2=A0 Do as you think best.=

Yeah, this is entirely process wonkery;=C2=A0I just did= n't want the WG to be surprised / to give y'all a chance to express= a preference (if anyone has one).=C2=A0

<= div>W
=C2=A0

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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


--
I don't think the execution is relevant whe= n it was obviously a bad idea in the first place.
This is like putting r= abid weasels in your pants, and later expressing regret at having chosen th= ose particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf=
--94eb2c0bfb5c4cc294053c6cd0ad-- From nobody Sat Sep 17 08:37:22 2016 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 9262412B23D for ; Sat, 17 Sep 2016 08:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2g1k-j2g9w7W for ; Sat, 17 Sep 2016 08:37:18 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A2F12B09C for ; Sat, 17 Sep 2016 08:37:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1blHg1-0001Ym-6K with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for dane@ietf.org; Sat, 17 Sep 2016 17:37:14 +0200 To: IETF DANE Mailinglist From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: <651d5b30-6833-df35-1394-5eede6eb6677@bartschnet.de> Date: Sat, 17 Sep 2016 17:37:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [dane] draft-ietf-dane-smime-12: TLS client-authentication X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2016 15:37:20 -0000 Hi, everyone knows the problem: We have dozens or hundreds of services to login and every service wants a user-name and a password. Most users reuse their passwords and a lot of services do not protect the passwords securely (no hashing, salting, etc.). If a service is hacked or malicious, the perpetrator can be quite sure to be able to reuse the credentials at other services. Not to mention passwords like 12345. In TLS operation, a user can be authenticated with a client-certificate. The password is neither transmitted over the wire nor to the service-provider. There is only one single password for the client-certificate instead of multiple passwords for multiple services. But if every service issues a certificate for a user the user application will be bloated with client-certificates. Not to mention the work-load for the user to create backups and to renew the client-certificates. A single client-certificate can be issued by a Certificate Authorities which is usually complicated, expensive and CAs have been proven to be unreliable. DANE-SMIMEA allows to validate an email-address/SMIME-certificate tupel via DNSSEC. That way a service-provider can validate a user is matching the email-address, be it a CA-issued or self-signed S/MIME-certificate. This establishes the opportunity to use DANE-SMIMEA as a global authentication system. The user creates a self-signed S/MIME-certificate and publishes it via DANE-SMIMEA. At a service he selects DANE-SMIMEA-Authentication and in his application (e.g. browser) the user selects the S/MIME-certificate to be used. The service provider (e.g. a mod_auth_smimea-module in Apache) validates the email-address/Common Name against the DNSSEC-protected public key in the SMIMEA-RR and can be sure to be connected with the user having that exact email-address. So I suggest to add this case to the application description in section 6 of draft-ietf-dane-smime-12 or a successor/errata. (Sorry, I lost track of the current state of SMIMEA). Regards, Renne From nobody Sat Sep 17 09:13:38 2016 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 CA65412B28D for ; Sat, 17 Sep 2016 09:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=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 RKdVkw-PIABB for ; Sat, 17 Sep 2016 09:13:34 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 740EE12B161 for ; Sat, 17 Sep 2016 09:13:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 3A23113044; Sat, 17 Sep 2016 19:13:32 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id pFKbHQgCfb6v; Sat, 17 Sep 2016 19:13:31 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 4E81E21C; Sat, 17 Sep 2016 19:13:31 +0300 (EEST) Date: Sat, 17 Sep 2016 19:13:28 +0300 From: Ilari Liusvaara To: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: <20160917161328.GA22975@LK-Perkele-V2.elisa-laajakaista.fi> References: <651d5b30-6833-df35-1394-5eede6eb6677@bartschnet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <651d5b30-6833-df35-1394-5eede6eb6677@bartschnet.de> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: IETF DANE Mailinglist Subject: Re: [dane] draft-ietf-dane-smime-12: TLS client-authentication X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2016 16:13:37 -0000 On Sat, Sep 17, 2016 at 05:37:12PM +0200, Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > Hi, > > > everyone knows the problem: > > We have dozens or hundreds of services to login and every service wants > a user-name and a password. Most users reuse their passwords and a lot > of services do not protect the passwords securely (no hashing, salting, > etc.). If a service is hacked or malicious, the perpetrator can be quite > sure to be able to reuse the credentials at other services. Not to > mention passwords like 12345. > > In TLS operation, a user can be authenticated with a client-certificate. > The password is neither transmitted over the wire nor to the > service-provider. There is only one single password for the > client-certificate instead of multiple passwords for multiple services. > So I suggest to add this case to the application description in section > 6 of draft-ietf-dane-smime-12 or a successor/errata. (Sorry, I lost > track of the current state of SMIMEA). Unfortunately, client certificates tend to be UX disaster. Things only get worse if one needs to consider multiple services, as using one key for multiple services tends to have bad security consequences. These tend to be the reasons browser vendors are phasing out and client certificate installation, pretty much meaning one has to have physical smartcard for TLS client certificate authentication. And such smartcards with the necressary equipment are pretty rare (I happen to have one) and tend to be built around real-world identity, which is great for some services, but not-so-great for most. I have once experimented on what it would take to implement client certificate authentication in a site, and pretty quickly gave up, given the horrible UX it had (not to mention technical problems, even with all the PKI baggage I could short-circuited). -Ilari From nobody Sun Sep 18 08:41:51 2016 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 A3C6E12B0F2 for ; Sun, 18 Sep 2016 08:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com 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 SThKh4AJvB7s for ; Sun, 18 Sep 2016 08:41:47 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0099.outbound.protection.outlook.com [23.103.201.99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEE812B03F for ; Sun, 18 Sep 2016 08:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ydxE7ERGY2pUPiIdPCfx7IScv3VdScQoln/mS0Qrs/8=; b=OVxBoKc3yfQ2gqwwrB7UhDQ1nWArn2SyUJvNC0vusWcMxIOsUWVSGUw1Z3LvZA2dat4x08Mtmk2QdEQes4a0YrwXChcW2MuCYiEwh8Gjyvw6xvLpmMMrvldMcD9Pl8+33nw2ApKgLooyt/5lG3phkWTs5KvQwuR4US7L1Mzqv3o= Received: from DM2PR09MB0576.namprd09.prod.outlook.com (10.161.252.22) by DM2PR09MB0575.namprd09.prod.outlook.com (10.161.252.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.8; Sun, 18 Sep 2016 15:41:44 +0000 Received: from DM2PR09MB0576.namprd09.prod.outlook.com ([10.161.252.22]) by DM2PR09MB0576.namprd09.prod.outlook.com ([10.161.252.22]) with mapi id 15.01.0629.006; Sun, 18 Sep 2016 15:41:44 +0000 From: "Garfinkel, Simson L. (Fed)" To: Ilari Liusvaara , "Rene 'Renne' Bartsch, B.Sc. Informatics" Thread-Topic: [dane] draft-ietf-dane-smime-12: TLS client-authentication Thread-Index: AQHSEPlp5IudwZNwZU29Ev2s+iPKuaB92uYAgAGGStE= Date: Sun, 18 Sep 2016 15:41:43 +0000 Message-ID: References: <651d5b30-6833-df35-1394-5eede6eb6677@bartschnet.de>, <20160917161328.GA22975@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160917161328.GA22975@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=simson.garfinkel@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:141:301:bf19:ddd5:cb79:4e88:a73d] x-ms-office365-filtering-correlation-id: e16c2b92-4642-468e-e7de-08d3dfda4b09 x-microsoft-exchange-diagnostics: 1; DM2PR09MB0575; 6:RGu8wJtsROKUbbI2Te44SS/TJpCjiZ+FjqXn50A3VVEtXvDJfBrsfDQAxTJDuxKi1fecqa+dT+X5B8pA4xBe7pH9YBjXnsbg+xAWaCovPPe75OY2yx6HW+WgvIU7Kdg4LWMqzexghz/80fGO1Y5UrFldEZyJccVzhZHSQqZ6192nKXcPsMDo0hsuuEtO6DlwvarNLNAP78/tIeThzRdX7nSbyOFonSz9ifwkP7iEPUSarKZuj3Jl7gvDpyAhf/074jkTWuTVuQB/It0noozka3n4rUnKet0ir0lyVkAsGckPajqWmKNzUNHZoSdMyJf3MibvEMJCSIQvoSz3jCQ+uQ==; 5:qisxbQ6Cl1vo5uZ1/r9c/6yXzebQS45AB3SIF98rAw1LUMwl9hh9bMhQ1zahEKiqjHwHz78anhSDur7pLxkywKdN9zzqi3djUlq/AuTqnS6aYE+W+noaW9amNJMjD/Akk56L1NCbG+6IesUXiHrHYA==; 24:5+6arpVEB5AarxNfy5hUJBb1yH5p5ESSNyuueVtc+iOD+vRGRRYKbAIia77E9RDtFKR+UUGwk2NLeugXDIRC7C8RK5rr8lZt0fhAWH3opRU=; 7:4T1uDFIZQ/Z3fEVUw76wiqiWWq1/Hf/5A1Z83L52qxWHqarEVKu9utALtJViAW1Iu7YhjvhNSBDyxbySO9WO2icoytzlFNuX7WwXxU9RGjVukj8uwAX2xxgbLhkObq700WHfuzlvh0ocqKLuBu3mtzMCiX6MGPgpYlSfxyDJ2NbU75yQ0P26hN3SBxgSu93J6v7tZLzmfV85pOy97c8bJ2diVt6pEMmIRTYtOAJU2vaEdeyFDnawVruUNPPsv72Mhhn6yw5A/euiElf2s0htKM+nvhLiMiSyZKq8wk+qOdH5w5pfn5AXKFcaz9D5b+NR x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0575; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DM2PR09MB0575; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0575; x-forefront-prvs: 0069246B74 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(377454003)(199003)(15594002)(189002)(7696004)(551544002)(10400500002)(19580395003)(19580405001)(2950100001)(2900100001)(8936002)(87936001)(16236675004)(19627405001)(68736007)(5660300001)(92566002)(102836003)(77096005)(15975445007)(6116002)(189998001)(230783001)(76576001)(19617315012)(586003)(97736004)(5002640100001)(5001770100001)(9686002)(7736002)(33656002)(19625215002)(7846002)(2906002)(76176999)(54356999)(7906003)(3280700002)(101416001)(81156014)(81166006)(8676002)(86362001)(11100500001)(5180700001)(3660700001)(15974865002)(106116001)(3900700001)(99286002)(122556002)(106356001)(74316002)(50986999)(4326007)(105586002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0575; H:DM2PR09MB0576.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0576A0CC44EC472F67741E47F6F50DM2PR09MB0576namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2016 15:41:43.7861 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0575 Archived-At: Cc: IETF DANE Mailinglist Subject: Re: [dane] draft-ietf-dane-smime-12: TLS client-authentication X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 18 Sep 2016 15:41:50 -0000 --_000_DM2PR09MB0576A0CC44EC472F67741E47F6F50DM2PR09MB0576namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ilari & Rene, Certificate-based smart cards are widely used within the US Government. The= Department of Defense has millions of it's so-called CACs (Common Access C= ards) in use, and they are used by most DoD employees on a daily basis to a= ccess information systems (logical access). Other federal agencies have bee= n less successful, but still somewhat successful, with the deployment of th= e PIV (Personal Identity Verification) cards for logical access. It is ver= y common for federal agencies to purchase laptops that have slots for smart= cards. The primary advantage of the CAC and PIV cards is that they provide both ph= ysical access and logical access. For physical access, the cards have embed= ded proximity chips. For logical access, the advantage is that they free re= lying parties from both identity and password management. If a card is lost= , the employee can get a new card without having to change a single passwor= d. They also significantly ease the usability burden, as the employee need = only remember a 6 digit PIN. I have an article coming out in a few weeks that looks in depth at the CAC = and PIV deployment. When it is published, I will post a link here. Ilari is correct in stating that the use of smartcards requires the deploym= ent of a card-reading infrastructure. The growing use of smartcards for cre= dit cards might result in the deployment of some credit card readers in the= home, which could also be used for certificate-containing smartcards. Anot= her promising form factor are USB tokens that combine a smartcard chip and = a smartcard reader. I believe that one way to move forward in providing strong logical authenti= cation is systems that allow people to use the chips in their credit cards = as an identity root. Another way to move forward is for universities and bu= sinesses to adopt multi-mode cards for their identification cards. With the= cost of smart card readers plummeting (they cost less than $15 now retail,= and the actual parts cost is substantially less), the fact that smartcards= provide both high levels of usability and security should be attractive to= many organizations. Simson Garfinkel ________________________________ From: dane on behalf of Ilari Liusvaara Sent: Saturday, September 17, 2016 12:13 PM To: Rene 'Renne' Bartsch, B.Sc. Informatics Cc: IETF DANE Mailinglist Subject: Re: [dane] draft-ietf-dane-smime-12: TLS client-authentication On Sat, Sep 17, 2016 at 05:37:12PM +0200, Rene 'Renne' Bartsch, B.Sc. Infor= matics wrote: > Hi, > > > everyone knows the problem: > > We have dozens or hundreds of services to login and every service wants > a user-name and a password. Most users reuse their passwords and a lot > of services do not protect the passwords securely (no hashing, salting, > etc.). If a service is hacked or malicious, the perpetrator can be quite > sure to be able to reuse the credentials at other services. Not to > mention passwords like 12345. > > In TLS operation, a user can be authenticated with a client-certificate. > The password is neither transmitted over the wire nor to the > service-provider. There is only one single password for the > client-certificate instead of multiple passwords for multiple services. > So I suggest to add this case to the application description in section > 6 of draft-ietf-dane-smime-12 or a successor/errata. (Sorry, I lost > track of the current state of SMIMEA). Unfortunately, client certificates tend to be UX disaster. Things only get worse if one needs to consider multiple services, as using one key for multiple services tends to have bad security consequences. These tend to be the reasons browser vendors are phasing out and client certificate installation, pretty much meaning one has to have physical smartcard for TLS client certificate authentication. And such smartcards with the necressary equipment are pretty rare (I happen to have one) and tend to be built around real-world identity, which is great for some services, but not-so-great for most. I have once experimented on what it would take to implement client certificate authentication in a site, and pretty quickly gave up, given the horrible UX it had (not to mention technical problems, even with all the PKI baggage I could short-circuited). -Ilari _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane dane Info Page - Internet Engineering Task Force www.ietf.org Your email address: Your name (optional): You may enter a privacy password = below. This provides only mild security, but should prevent others from mes= sing with ... --_000_DM2PR09MB0576A0CC44EC472F67741E47F6F50DM2PR09MB0576namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ilari & Rene,


Certificate-based smart cards are widely used within the US Government. = The Department of Defense has millions of it's so-called CACs (Common Acces= s Cards) in use, and they are used by most DoD employees on a daily ba= sis to access information systems (logical access). Other federal agencies have been less successful, but still somew= hat successful, with the deployment of the PIV (Personal Identity Verificat= ion) cards for logical access.  It is very common for federal agencies= to purchase laptops that have slots for smart cards.


The primary advantage of the CAC and PIV cards is that they provide both= physical access and logical access. For physical access, the cards have em= bedded proximity chips. For logical access, the advantage is that= they free relying parties from both identity and password management. If a card is lost, the employee can get a ne= w card without having to change a single password. They also significantly = ease the usability burden, as the employee need only remember a 6 digit PIN= .


I have an article coming out in a few weeks that looks in depth at = the CAC and PIV deployment.  When it is published, I will post a link = here.


Ilari is correct in stating that the use of smartcards requires the depl= oyment of a card-reading infrastructure. The growing use of smartcards for = credit cards might result in the deployment of some credit card readers in = the home, which could also be used for certificate-containing smartcards. Another promising form factor are U= SB tokens that combine a smartcard chip and a smartcard reader. 


I believe that one way to move forward in providing strong logical authe= ntication is systems that allow people to use the chips in their credi= t cards as an identity root. Another way to move forward is for universitie= s and businesses to adopt multi-mode cards for their identification cards. With the cost of smart card readers = plummeting (they cost less than $15 now retail, and the actual parts cost i= s substantially less), the fact that smartcards provide both high levels of= usability and security should be attractive to many organizations.


Simson Garfinkel


From: dane <dane-bounc= es@ietf.org> on behalf of Ilari Liusvaara <ilariliusvaara@welho.com&g= t;
Sent: Saturday, September 17, 2016 12:13 PM
To: Rene 'Renne' Bartsch, B.Sc. Informatics
Cc: IETF DANE Mailinglist
Subject: Re: [dane] draft-ietf-dane-smime-12: TLS client-authenticat= ion
 
On Sat, Sep 17, 2016 at 05:37:12PM +0200, Rene= 'Renne' Bartsch, B.Sc. Informatics wrote:
> Hi,
>
>
> everyone knows the problem:
>
> We have dozens or hundreds of services to login and every service want= s
> a user-name and a password. Most users reuse their passwords and a lot=
> of services do not protect the passwords securely (no hashing, salting= ,
> etc.). If a service is hacked or malicious, the perpetrator can be qui= te
> sure to be able to reuse the credentials at other services. Not to
> mention passwords like 12345.
>
> In TLS operation, a user can be authenticated with a client-certificat= e.
> The password is neither transmitted over the wire nor to the
> service-provider. There is only one single password for the
> client-certificate instead of multiple passwords for multiple services= .

> So I suggest to add this case to the application description in sectio= n
> 6 of draft-ietf-dane-smime-12 or a successor/errata. (Sorry, I lost > track of the current state of SMIMEA).

Unfortunately, client certificates tend to be UX disaster. Things only
get worse if one needs to consider multiple services, as using one key
for multiple services tends to have bad security consequences.

These tend to be the reasons browser vendors are phasing out <keygen>=
and client certificate installation, pretty much meaning one has to
have physical smartcard for TLS client certificate authentication.

And such smartcards with the necressary equipment are pretty rare
(I happen to have one) and tend to be built around real-world identity,
which is great for some services, but not-so-great for most.

I have once experimented on what it would take to implement client
certificate authentication in a site, and pretty quickly gave up,
given the horrible UX it had (not to mention technical problems,
even with all the PKI baggage I could short-circuited).



-Ilari

_______________________________________________
dane mailing list
dane@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dane
www.ietf.org
Your email address: Your name (optional): You may enter a privacy password = below. This provides only mild security, but should prevent others from mes= sing with ...


--_000_DM2PR09MB0576A0CC44EC472F67741E47F6F50DM2PR09MB0576namp_-- From nobody Sun Sep 18 10:00:05 2016 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 DC2EB12B144 for ; Sun, 18 Sep 2016 10:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=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 KtP-iWd5LMdu for ; Sun, 18 Sep 2016 10:00:02 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id BE52A12B13B for ; Sun, 18 Sep 2016 10:00:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 35F1212E37; Sun, 18 Sep 2016 20:00:00 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id JzJKgQ7SvSzZ; Sun, 18 Sep 2016 19:59:59 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id E4E4821C; Sun, 18 Sep 2016 19:59:59 +0300 (EEST) Date: Sun, 18 Sep 2016 19:59:57 +0300 From: Ilari Liusvaara To: "Garfinkel, Simson L. (Fed)" Message-ID: <20160918165957.GA24299@LK-Perkele-V2.elisa-laajakaista.fi> References: <651d5b30-6833-df35-1394-5eede6eb6677@bartschnet.de> <20160917161328.GA22975@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: IETF DANE Mailinglist Subject: Re: [dane] draft-ietf-dane-smime-12: TLS client-authentication X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 18 Sep 2016 17:00:04 -0000 On Sun, Sep 18, 2016 at 03:41:43PM +0000, Garfinkel, Simson L. (Fed) wrote: > Ilari & Rene, > > > Certificate-based smart cards are widely used within the US Government. > The Department of Defense has millions of it's so-called CACs (Common > Access Cards) in use, and they are used by most DoD employees on a > daily basis to access information systems (logical access). Other > federal agencies have been less successful, but still somewhat > successful, with the deployment of the PIV (Personal Identity > Verification) cards for logical access. It is very common for federal > agencies to purchase laptops that have slots for smart cards. Yes, if you have widely distributed smartcards, the reader infrastructure and sites tied to real-world identity, then things should work just great. Let's just say that out of the main methods used around the part of the world I live in, using official ID card, which also is a smartcard is the least BS way (if you happen to have a smartcard reader set up). Unfortunately, none of those three assumptions above is true in the wider web environment. There you don't want things like linkability to real-world identity or even linkability between origins. Nor can one assume presence of extra hardware. Also, there is currently no feasible way to go "all in" with any form of "what you have" authentication (except for some select sites with larger budgets for security). And if you don't go "all in", then you probably do cause problems for those using tokens of some kind via still having legacy baggage from passwords. -Ilari From nobody Mon Sep 19 07:30:23 2016 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 B090812B3CF; Mon, 19 Sep 2016 07:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.918 X-Spam-Level: X-Spam-Status: No, score=-104.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 kOnH2xMLvLT5; Mon, 19 Sep 2016 07:30:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0C612B05C; Mon, 19 Sep 2016 07:30:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7BDC2B80F83; Mon, 19 Sep 2016 07:30:11 -0700 (PDT) To: viktor1dane@dukhovni.org, paul.hoffman@vpnc.org, jakob@kirei.se X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160919143011.7BDC2B80F83@rfc-editor.org> Date: Mon, 19 Sep 2016 07:30:11 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, dane@ietf.org, iesg@ietf.org Subject: [dane] [Errata Rejected] RFC6698 (3594) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 19 Sep 2016 14:30:16 -0000 The following errata report has been rejected for RFC6698, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6698&eid=3594 -------------------------------------- Status: Rejected Type: Technical Reported by: Viktor Dukhovni Date Reported: 2013-04-16 Rejected by: Stephen Farrell (IESG) Section: 2.1.1 Original Text ------------- 2 -- Certificate usage 2 is used to specify a certificate, or the public key of such a certificate, that MUST be used as the trust anchor when validating the end entity certificate given by the server in TLS. This certificate usage is sometimes referred to as "trust anchor assertion" and allows a domain name administrator to specify a new trust anchor -- for example, if the domain issues its own certificates under its own CA that is not expected to be in the end users' collection of trust anchors. The target certificate MUST pass PKIX certification path validation, with any certificate matching the TLSA record considered to be a trust anchor for this certification path validation. Corrected Text -------------- 2 -- Certificate usage 2 is used to specify a certificate, or the public key of such a certificate, that MUST be used as the trust anchor when validating the end entity certificate given by the server in TLS. This certificate usage is sometimes referred to as "trust anchor assertion" and allows a domain name administrator to specify a new trust anchor -- for example, if the domain issues its own certificates under its own CA that is not expected to be in the end users' collection of trust anchors. The target certificate MUST pass PKIX certification path validation, with any certificate matching the TLSA record considered to be a trust anchor for this certification path validation. Since clients cannot be presumed to have their own copy of the trust-anchor certificate, when the TLSA association specifies a certificate digest, the TLS server MUST be configured to provide the trust-anchor certificate in its "certificate_list" TLS handshake message. Notes ----- As per discussion on the DANE WG list, this was overtaken by events and so is rejected. This is critical for interoperability between clients and servers. A client that commits to verify TLSA RR certificate associations will fail if it can't obtain the required certificates. With usage "2" there is no presumption that these are available to the client. If servers are not obligated to provide them the protocol will consistently fail. With non-interactive protocols where there is no user to "click OK", such as SMTP, there is no good work-around and both client and server owners suffer. --VERIFIER NOTES-- As per discussion on the DANE WG list, this was overtaken by events and so is rejected. -------------------------------------- RFC6698 (draft-ietf-dane-protocol-23) -------------------------------------- Title : The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA Publication Date : August 2012 Author(s) : P. Hoffman, J. Schlyter Category : PROPOSED STANDARD Source : DNS-based Authentication of Named Entities Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Sep 20 01:42:35 2016 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 E21D8128B44 for ; Tue, 20 Sep 2016 01:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WMg9VcqAKYNx for ; Tue, 20 Sep 2016 01:42:31 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB6A12B6AA for ; Tue, 20 Sep 2016 01:38:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1bmGZB-0004I2-Vd with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for dane@ietf.org; Tue, 20 Sep 2016 10:38:15 +0200 To: IETF DANE Mailinglist From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: Date: Tue, 20 Sep 2016 10:38:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dane] Webinterface for DANE-OpenPGPkey look-up available X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 20 Sep 2016 08:42:34 -0000 Hi, the german mail-provider mail.de has published a web-interface for RFC 7929 look-ups at https://openpgpkey.info/. While users have to trust mail.de, it allows John-Does to look-up OpenPGPkey-RRs until mail-clients support it. The website is now available via IPv4 and IPv6 protected with DNSSEC/DANE-TLS. Using the DNSSEC/TLSA-Validator from CZ-NIC (https://www.dnssec-validator.cz/) John-Does can look-up public PGP-keys fairly secure with their browser. There's definitely no excuse anymore for mail-providers to kick RFC 7929 down the road! ;-) Regards, Renne From nobody Tue Sep 20 01:57:53 2016 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 772A712B687 for ; Tue, 20 Sep 2016 01:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 O4QLD4FjU-Er for ; Tue, 20 Sep 2016 01:57:49 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8329B12B22A for ; Tue, 20 Sep 2016 01:57:49 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3sdc8q0vrnz25Rt; Tue, 20 Sep 2016 10:57:47 +0200 (CEST) X-purgate-ID: 152705::1474361867-000046BC-8272713E/0/0 X-purgate-size: 998 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3sdc8p4mGMzks2v; Tue, 20 Sep 2016 10:57:46 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9CB231A554; Tue, 20 Sep 2016 10:57:46 +0200 (CEST) In-Reply-To: To: "Rene 'Renne' Bartsch, B.Sc. Informatics" Date: Tue, 20 Sep 2016 10:57:46 +0200 (CEST) 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: <20160920085746.9CB231A554@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: IETF DANE Mailinglist Subject: Re: [dane] Webinterface for DANE-OpenPGPkey look-up available X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 08:57:51 -0000 Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > > the german mail-provider mail.de has published a web-interface for RFC > 7929 look-ups at https://openpgpkey.info/. While users have to trust > mail.de, it allows John-Does to look-up OpenPGPkey-RRs until > mail-clients support it. The website is now available via IPv4 and IPv6 > protected with DNSSEC/DANE-TLS. Using the DNSSEC/TLSA-Validator from > CZ-NIC (https://www.dnssec-validator.cz/) John-Does can look-up public > PGP-keys fairly secure with their browser. > > There's definitely no excuse anymore for mail-providers to kick RFC 7929 > down the road! ;-) The concept of the status "Experimental" seems to be unclear to you. And I'm slightly confused to see a comment like this from someone who seems to come from Europe. In Europe, publishing such information is a mandatory end-user-optin (so it requires a non-trivial change to the backend software), besides screaming out loud "spam-me-harder". -Martin From nobody Tue Sep 20 08:39:24 2016 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 2071212B21B for ; Tue, 20 Sep 2016 08:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.316 X-Spam-Level: X-Spam-Status: No, score=-4.316 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=-2.316] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 9_9tD0CNOzdK for ; Tue, 20 Sep 2016 08:39:18 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D684A12B0CC for ; Tue, 20 Sep 2016 08:37:11 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sdn1c5j1ZzN1H; Tue, 20 Sep 2016 17:37:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1474385828; bh=8JPm5lCgZT8oLi23DScMUSHvGz3gLff2nPTcOCbzIQo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=YoHBp/5o5Af7DRJizxD1xa6FL2a1B9GcGTtzPQ2g1aNhkBl8DMe/EgMKRGzFrcdbG oiX7puB9Jjr3ojtMkbVfQgFI+feUE2pCsDZrpaZzrwV8Pgg/bRhZMtIdqwkRILD9rw rtJ88QOXVMbb3umoa7DKFB0flpu3lxItQecRnFsI= 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 x70HZ1FqiAyT; Tue, 20 Sep 2016 17:37:06 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 20 Sep 2016 17:37:06 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D729E35A2AE; Tue, 20 Sep 2016 11:37:05 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca D729E35A2AE Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C1D9140D7297; Tue, 20 Sep 2016 11:37:05 -0400 (EDT) Date: Tue, 20 Sep 2016 11:37:05 -0400 (EDT) From: Paul Wouters To: Martin Rex In-Reply-To: <20160920085746.9CB231A554@ld9781.wdf.sap.corp> Message-ID: References: <20160920085746.9CB231A554@ld9781.wdf.sap.corp> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IETF DANE Mailinglist Subject: Re: [dane] Webinterface for DANE-OpenPGPkey look-up available X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 20 Sep 2016 15:39:23 -0000 On Tue, 20 Sep 2016, Martin Rex wrote: > Rene 'Renne' Bartsch, B.Sc. Informatics wrote: >> >> the german mail-provider mail.de has published a web-interface for RFC >> 7929 look-ups at https://openpgpkey.info/. That's neat! I tested it out and it found the my pgp key. Perhaps a more human readable interpretation would have been nice to see as well? >> There's definitely no excuse anymore for mail-providers to kick RFC 7929 >> down the road! ;-) :) > The concept of the status "Experimental" seems to be unclear to you. For one, marking it experimental was pretty silly, and based only on the "we are all going to die over lowercase()" issue. Second, even expriments need to get their deployments started to see if the RFC is successfull or not. > And I'm slightly confused to see a comment like this from someone > who seems to come from Europe. In Europe, publishing such information > is a mandatory end-user-optin (so it requires a non-trivial change > to the backend software), besides screaming out loud "spam-me-harder". It seems a little ironic that you are invoking privacy laws over publishing and using _public_ keys eh? :) And I'm also from European decent but do not see a privacy issue. In fact, if anything, one can argue that having encryption envelopes now readily available, sending your personal emails as a postcard without an encryption envelope would be the privacy law violation. Paul From nobody Mon Sep 26 09:28:25 2016 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 39F3C12B249 for ; Mon, 26 Sep 2016 09:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 YiLvwkYiQf5h for ; Mon, 26 Sep 2016 09:28:21 -0700 (PDT) Received: from poretsky.uvt.nl (poretsky.uvt.nl [IPv6:2001:610:1410:0:5122:6ff4:e9c9:84ce]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C5B312B246 for ; Mon, 26 Sep 2016 09:28:19 -0700 (PDT) Received: by poretsky.uvt.nl (Postfix, from userid 116) id BD5BEC000B3; Mon, 26 Sep 2016 18:28:17 +0200 (CEST) Received: from localhost by poretsky (rewritefishurl); Mon, 26 Sep 2016 18:28:17 +0200 Received: from localhost (localhost [IPv6:::1]) by poretsky.uvt.nl (Postfix) with ESMTP id B2B0BC000B0 for ; Mon, 26 Sep 2016 18:28:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at uvt.nl X-Spam-Cookie: c7b0e006e98ec213ad7e6201ec5841cd49d1415c Received: from lambert.uvt.nl ([IPv6:2001:610:1410:0:55c7:8a48:39f2:4256]) by localhost (poretsky.uvt.nl [IPv6:2001:610:1410:0:5122:6ff4:e9c9:84ce]) (amavisd-new, port 10024) with ESMTP id T6kSmDZC0UBF for ; Mon, 26 Sep 2016 18:28:17 +0200 (CEST) Received: from [::1] (localhost [::1]) (Authenticated sender: cgielen) by lambert.uvt.nl (Postfix) with ESMTPSA id 81B1B8800E7 To: dane@ietf.org References: <20160826013552.GR4670@mournblade.imrryr.org> <0f2e3307-bd37-a38a-5e4d-e43d52133af6@uvt.nl> <20160910233818.GZ4670@mournblade.imrryr.org> From: Casper Gielen Message-ID: Date: Mon, 26 Sep 2016 18:28:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160910233818.GZ4670@mournblade.imrryr.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dg5Kk5Uwa7IkB1mf1dDXJPB1pGec0BuHt" Archived-At: Subject: Re: [dane] Nudge DANE SMTP adoption at DNSSEC-signed MX hosting providers X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 26 Sep 2016 16:28:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Dg5Kk5Uwa7IkB1mf1dDXJPB1pGec0BuHt Content-Type: multipart/mixed; boundary="ciq5GgIjkdMBTjpjJs6o0E59H9AXvEsnV" From: Casper Gielen To: dane@ietf.org Message-ID: Subject: Re: [dane] Nudge DANE SMTP adoption at DNSSEC-signed MX hosting providers References: <20160826013552.GR4670@mournblade.imrryr.org> <0f2e3307-bd37-a38a-5e4d-e43d52133af6@uvt.nl> <20160910233818.GZ4670@mournblade.imrryr.org> In-Reply-To: <20160910233818.GZ4670@mournblade.imrryr.org> --ciq5GgIjkdMBTjpjJs6o0E59H9AXvEsnV Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Op 11-09-16 om 01:38 schreef Viktor Dukhovni: > Thanks, that makes for 180 new domains in my survey, out of a grand > total of 59100 as of today. Two of them, >=20 > uvt.nl, and > tilburguniversity.edu >=20 > had even generated enough volume back and forth from Gmail to make > the list of 71 domains in my survey that also have appeared in > Gmail's transparency report in the recent past. That's nice to hear. Is this information accessible online? It might help with bragging^Wadvocacy. My boss doesn't care about Dane, but being in a list of some sort makes him happy. > P.S. I curious about the actual number of your 2LD DNSSEC domains that have some subset of Somewhat over 300, the actual number varies from day to day. I'll send you a full list in private. --=20 Casper Gielen | LIS UNIX PGP fingerprint =3D 16BD 2C9F 8156 C242 F981 63B8 2214 083C F80E 4AF7 Universiteit van Tilburg | Postbus 90153, 5000 LE Warandelaan 2 | Telefoon 013 466 4100 | G 236 | http://www.uvt.nl --ciq5GgIjkdMBTjpjJs6o0E59H9AXvEsnV-- --Dg5Kk5Uwa7IkB1mf1dDXJPB1pGec0BuHt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlfpTJQACgkQIhQIPPgOSveimQCfZha5ZEA5rZLZLV4zFWOEyHpK 1t0AnRQvSAID8AZsuAFIhe0d9tUXV2bY =VAbg -----END PGP SIGNATURE----- --Dg5Kk5Uwa7IkB1mf1dDXJPB1pGec0BuHt-- From nobody Thu Sep 29 15:08:05 2016 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D60D012B00E; Thu, 29 Sep 2016 15:08:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147518688283.18473.7783493007808919741.idtracker@ietfa.amsl.com> Date: Thu, 29 Sep 2016 15:08:02 -0700 Archived-At: Cc: dane-chairs@ietf.org, dane@ietf.org Subject: [dane] dane - Not having a session at IETF 97 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 22:08:03 -0000 Warren Kumari, a chair of the dane working group, indicated that the dane working group does not plan to hold a session at IETF 97. This message was generated and sent by the IETF Meeting Session Request Tool.