From ogud@ogud.com Thu Aug 1 09:36: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 AADDE11E811E for ; Thu, 1 Aug 2013 09:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.178 X-Spam-Level: X-Spam-Status: No, score=-102.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, 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 nxqtjvM-Q6-p for ; Thu, 1 Aug 2013 09:36:16 -0700 (PDT) Received: from smtp156.ord.emailsrvr.com (smtp156.ord.emailsrvr.com [173.203.6.156]) by ietfa.amsl.com (Postfix) with ESMTP id 9008621F9C7E for ; Thu, 1 Aug 2013 09:36:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp16.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 74C603D02FB for ; Thu, 1 Aug 2013 12:36:11 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp16.relay.ord1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 863273D0266 for ; Thu, 1 Aug 2013 12:36:10 -0400 (EDT) From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_8FFAED72-B42B-412B-ACD4-7382380DDEB2" Message-Id: Date: Thu, 1 Aug 2013 12:36:11 -0400 To: "dane@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dane] Expressive Short names for TLSA Record fields 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, 01 Aug 2013 16:36:20 -0000 --Apple-Mail=_8FFAED72-B42B-412B-ACD4-7382380DDEB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think the best way to address this communication problem is to write a = ID that defines the terms, and updates the IANA registry by adding a = column=20 with the short name.=20 Value Short Description Reference=20 0 CA constraint [RFC6698] 1 Service certificate constraint [RFC6698] 2 Trust anchor assertion [RFC6698] 3 Domain-issued certificate [RFC6698] Suggested names: 0 =3D PKIX-Cert, 1 =3D PKIX-TA, 2 =3D=3D DANE-TA , 3 = =3D=3D DANE_Cert=20 For the selectors Value Short Description Reference=20 0 Full certificate [RFC6698] 1 SubjectPublicKeyInfo [RFC6698] 0 =3D Cert, 1 =3D=3D=3D Key=20 For the digest algorithms we will just use the algorithm names SHA-256 = and SHA-512.=20 Feel free to suggest better names,=20 Olafur --Apple-Mail=_8FFAED72-B42B-412B-ACD4-7382380DDEB2 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_EADB1A40-02FD-43AF-A6CC-5ABA6A7A99DD" --Apple-Mail=_EADB1A40-02FD-43AF-A6CC-5ABA6A7A99DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Value Short Description Reference CA = constraint[RFC6698]1Service certificate constraint[RFC6698]2Trust anchor assertion[RFC6698]3Domain-issued certificate[RFC6698]

Suggested names: 0 =3D PKIX-Cert,  1 = =3D PKIX-TA,  2 =3D=3D DANE-TA , 3 =3D=3D = DANE_Cert 


For the = selectors
Short Description Reference 

0   =3D Cert,   1  =3D=3D=3D = Key 

For the digest algorithms we will = just use the algorithm names SHA-256 and SHA-512. 
Feel = free to suggest better names, 

= Olafur

= --Apple-Mail=_EADB1A40-02FD-43AF-A6CC-5ABA6A7A99DD Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=sort_none.gif Content-Type: image/gif; name="sort_none.gif" Content-Id: <3E1B4184-2D3B-4964-8393-8C4152EE4FAA@meeting.ietf.org> R0lGODlhDgAMAPcuAAAAAAEBAQICAgMDAwQEBAUFBQYGBgcHBwgICAkJCQoKCgsLCwwMDA0NDQ4O Dg8PDxAQEBERERISEhMTExQUFBUVFRYWFhcXFxgYGBkZGRoaGhsbGxwcHB0dHR4eHh8fHyAgICEh ISIiIiMjIyQkJCUlJSYmJicnJygoKCkpKSoqKisrKywsLC0tLS4uLi8vLzAwMDExMTIyMjMzMzQ0 NDU1NTY2Njc3Nzg4ODk5OTo6Ojs7Ozw8PD09PT4+Pj8/P0BAQEFBQUJCQkNDQ0REREVFRUZGRkdH R0hISElJSUpKSktLS0xMTE1NTU5OTk9PT1BQUFFRUVJSUlNTU1RUVFVVVVZWVldXV1hYWFlZWVpa WltbW1xcXF1dXV5eXl9fX2BgYGFhYWJiYmNjY2RkZGVlZWZmZmdnZ2hoaGlpaWpqamtra2xsbG1t bW5ubm9vb3BwcHFxcXJycnNzc3R0dHV1dXZ2dnd3d3h4eHl5eXp6ent7e3x8fH19fX5+fn9/f4CA gIGBgYKCgoODg4SEhIWFhYaGhoeHh4iIiImJiYqKiouLi4yMjI2NjY6Ojo+Pj5CQkJGRkZKSkpOT k5SUlJWVlZaWlpeXl5iYmJmZmZqampubm5ycnJ2dnZ6enp+fn6CgoKGhoaKioqOjo6SkpKWlpaam pqenp6ioqKmpqaqqqqurq6ysrK2tra6urq+vr7CwsLGxsbKysrOzs7S0tLW1tba2tre3t7i4uLm5 ubq6uru7u7y8vL29vb6+vr+/v8DAwMHBwcLCwsPDw8TExMXFxcbGxsfHx8jIyMnJycrKysvLy8zM zM3Nzc7Ozs/Pz9DQ0NHR0dLS0tPT09TU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f 3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5ufn5+jo6Onp6erq6uvr6+zs7O3t7e7u7u/v7/Dw8PHx8fLy 8vPz8/T09PX19fb29vf39/j4+Pn5+fr6+vv7+/z8/P39/f7+/v///yH5BAEKAP8AIf4VQ3JlYXRl ZCB3aXRoIFRoZSBHSU1QACwCAAAADAAMAAAIMQDhCBxIcOC/gwgTCvxXcCFDOAcLInT4EOJEixET PtSIceNFjBQlemwIkaLGiCQLBgQAOw== --Apple-Mail=_EADB1A40-02FD-43AF-A6CC-5ABA6A7A99DD Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=sort_none.gif Content-Type: image/gif; name="sort_none.gif" Content-Id: R0lGODlhDgAMAPcuAAAAAAEBAQICAgMDAwQEBAUFBQYGBgcHBwgICAkJCQoKCgsLCwwMDA0NDQ4O Dg8PDxAQEBERERISEhMTExQUFBUVFRYWFhcXFxgYGBkZGRoaGhsbGxwcHB0dHR4eHh8fHyAgICEh ISIiIiMjIyQkJCUlJSYmJicnJygoKCkpKSoqKisrKywsLC0tLS4uLi8vLzAwMDExMTIyMjMzMzQ0 NDU1NTY2Njc3Nzg4ODk5OTo6Ojs7Ozw8PD09PT4+Pj8/P0BAQEFBQUJCQkNDQ0REREVFRUZGRkdH R0hISElJSUpKSktLS0xMTE1NTU5OTk9PT1BQUFFRUVJSUlNTU1RUVFVVVVZWVldXV1hYWFlZWVpa WltbW1xcXF1dXV5eXl9fX2BgYGFhYWJiYmNjY2RkZGVlZWZmZmdnZ2hoaGlpaWpqamtra2xsbG1t bW5ubm9vb3BwcHFxcXJycnNzc3R0dHV1dXZ2dnd3d3h4eHl5eXp6ent7e3x8fH19fX5+fn9/f4CA gIGBgYKCgoODg4SEhIWFhYaGhoeHh4iIiImJiYqKiouLi4yMjI2NjY6Ojo+Pj5CQkJGRkZKSkpOT k5SUlJWVlZaWlpeXl5iYmJmZmZqampubm5ycnJ2dnZ6enp+fn6CgoKGhoaKioqOjo6SkpKWlpaam pqenp6ioqKmpqaqqqqurq6ysrK2tra6urq+vr7CwsLGxsbKysrOzs7S0tLW1tba2tre3t7i4uLm5 ubq6uru7u7y8vL29vb6+vr+/v8DAwMHBwcLCwsPDw8TExMXFxcbGxsfHx8jIyMnJycrKysvLy8zM zM3Nzc7Ozs/Pz9DQ0NHR0dLS0tPT09TU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f 3+Dg4OHh4eLi4uPj4+Tk5OXl5ebm5ufn5+jo6Onp6erq6uvr6+zs7O3t7e7u7u/v7/Dw8PHx8fLy 8vPz8/T09PX19fb29vf39/j4+Pn5+fr6+vv7+/z8/P39/f7+/v///yH5BAEKAP8AIf4VQ3JlYXRl ZCB3aXRoIFRoZSBHSU1QACwCAAAADAAMAAAIMQDhCBxIcOC/gwgTCvxXcCFDOAcLInT4EOJEixET PtSIceNFjBQlemwIkaLGiCQLBgQAOw== --Apple-Mail=_EADB1A40-02FD-43AF-A6CC-5ABA6A7A99DD-- --Apple-Mail=_8FFAED72-B42B-412B-ACD4-7382380DDEB2-- From ietf@meetecho.com Thu Aug 1 18:46:27 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74C621E8378 for ; Thu, 1 Aug 2013 18:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.316 X-Spam-Level: X-Spam-Status: No, score=-0.316 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 ubrvGS+8tULX for ; Thu, 1 Aug 2013 18:46:16 -0700 (PDT) Received: from smtpdg8.aruba.it (smtpdg226.aruba.it [62.149.158.226]) by ietfa.amsl.com (Postfix) with ESMTP id 73C7C11E820F for ; Thu, 1 Aug 2013 17:58:55 -0700 (PDT) Received: from dell-tcastaldi ([130.129.66.20]) by smtpcmd03.ad.aruba.it with bizsmtp id 7cys1m00P0SDdTW01cytYY; Fri, 02 Aug 2013 02:58:54 +0200 Date: Fri, 2 Aug 2013 02:58:51 +0200 (CEST) From: Meetecho Team To: dane@ietf.org Message-ID: <1910900393.1.1375405131129.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_629893004.1375405131076" Subject: [dane] DANE session recording available 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, 02 Aug 2013 01:46:28 -0000 ------=_Part_0_629893004.1375405131076 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the DANE WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#DANE For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_629893004.1375405131076-- From bry8star@inventati.org Thu Aug 1 19:29: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 4644C21E826D for ; Thu, 1 Aug 2013 19:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKh2WonWbL9C for ; Thu, 1 Aug 2013 19:29:44 -0700 (PDT) Received: from contumacia.investici.org (contumacia.investici.org [IPv6:2002:b2ff:9023::1]) by ietfa.amsl.com (Postfix) with ESMTP id A94AD11E80ED for ; Thu, 1 Aug 2013 19:10:00 -0700 (PDT) Received: from [178.255.144.35] (contumacia [178.255.144.35]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id C0269E831B for ; Fri, 2 Aug 2013 02:09:55 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.6.8 contumacia.investici.org C0269E831B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1375409399; bh=Hnq5PJNX7uxsFjNCFwg0liUUDyoJ+Vtp+NbH5IYS7i4=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=pxs2Wva0oaW7c3NYKaN91NHNJW+UCDm0nYbbz6ikKyg7HNw1ctdqk2eEtFFRWiwFp gf2iDlzqMTyL1mkN3+a9FG8Q7rDuhyBS25C1i/KTJgakAGd4XY8hk+qaUbhsJJ759O EK6Pf3PeOzW4oVDsy2G9SXycFueuntqxR41fE1m8= Message-ID: <51FB14E2.9050005@inventati.org> Date: Thu, 01 Aug 2013 19:09:38 -0700 From: Bry8 Star User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dane@ietf.org References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2KLTIAXLNRKSWISQPRTXA" Subject: Re: [dane] Expressive Short names for TLSA Record fields 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: Fri, 02 Aug 2013 02:29:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2KLTIAXLNRKSWISQPRTXA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If i may suggest: CAD or C_A_D or C-A-D as short for "Certificate Association Data" field. Then for example, for TA TLSA type of lines, we can/may use at end, CAD_TA or CAD-TA. For DANE_cert types, we can/may use at end, CAD_DI or CAD-DI. For selector "1", may i suggest "PKey" or "pKey", instead of "Key". "SPKI" can also be used. "SPKey" may be more meaningful. For selector "0", may i suggest "Full_Cert", or "fCert". Currently, Usage 3, says checking cert chain/path is optional, so pls consider to add another usage case, for example, usage 4 for domain-issued cert, where zone/domain owner/operator can add domain-issued cert and say/tell clients to check its FULL path/chain by collecting/using other dane/TLSA RRs from DNS RRs. So that, ALL certs in a cert chain/path, can be verified using DANE. Also suggesting to consider to add another usage type for declaring Intermediate Authority certs including its position in a cert path/chain (i've posted a such proposal some time earlier). Received from Olafur Gudmundsson, on 2013-08-01 9:36 AM: >=20 > I think the best way to address this communication problem is to write = a ID that=20 > defines the terms, and updates the IANA registry by adding a column > with the short name. >=20 > Value Short Description Reference > 0 CA constraint [RFC6698 ] > 1 Service certificate constraint [RFC6698 ] > 2 Trust anchor assertion [RFC6698 ] > 3 Domain-issued certificate [RFC6698 ] >=20 >=20 > Suggested names: 0 =3D PKIX-Cert, 1 =3D PKIX-TA, 2 =3D=3D DANE-TA , 3= =3D=3D DANE_Cert >=20 >=20 > For the selectors > Value Short Description Reference > 0 Full certificate [RFC6698 ] > 1 SubjectPublicKeyInfo [RFC6698 ] >=20 >=20 > 0 =3D Cert, 1 =3D=3D=3D Key >=20 > For the digest algorithms we will just use the algorithm names SHA-256 = and SHA-512. > Feel free to suggest better names, >=20 > Olafur >=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 ------enig2KLTIAXLNRKSWISQPRTXA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJR+xTjAAoJEID2ikYfWSP67PEP/2IFUD/f0bm1PNKhFnz0P0/x ClZAhvqBZSy8HdZHVTpLoZo6ImvqlZIYwlple196QYpXX+ue6e+s6o2CjgSBLjjh F4a3Ui+2eh2AQxUeVbfYMMWgXdmnARUtG9A05Wx3lIA5DpKvDBEfMYKluCZjiKdG woQ5Vu/m1CKO5BCqMlYaWYLHctjQEwwuxxlnk56KED+eXRKdoIma9vY0OFtocwWV b2O5A0Y3J85vWbTYoncbuWGfM5ibpJSiZU/5AH6ASn+dZsImwPJdgCLWeybGbIa/ Ml0Ac7pgNHC1Bm/YT6+CyJFoskgc4/vNbZd/BM3szF639W0I4Wtf/tiYn3YQhZMS C3v1YhEO++XD/+eKrt3WWXZprUSbColPYnNmevFaT4B7zocmKKzDGr4BSQ4fsJg1 sT5X32gWWERs9UGk97wdY1dvQNbYvF9JXl8GnePhZZzE44+KMIRbh63wdrQEFhD3 CYGQqqTTvJUon7gXQuwi7OyIKvkcL3lwJqnXl6Fl42dG5OAfsxQekURzNkFnGCbE pymwO7xG3hplKKJPqroh0EVVUmGhLbi02PVXClnNPtWv7fLxxj1f5bLMDvzj5EZb PKkopbOyTmvL7pI+49MDj94fYSrq2FhcnglCGDdgDMx8/7Dfu0XpG8fhrZTxyTq3 9s8+xiaFIXDuvcpSbR+d =hmBD -----END PGP SIGNATURE----- ------enig2KLTIAXLNRKSWISQPRTXA-- From paul@nohats.ca Fri Aug 2 00:49:26 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086AF11E8210 for ; Fri, 2 Aug 2013 00:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15JBrcaTZA8X for ; Fri, 2 Aug 2013 00:49:19 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 32DDB11E8253 for ; Fri, 2 Aug 2013 00:49:17 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3c60r72Jhmz3sq; Fri, 2 Aug 2013 03:49:11 -0400 (EDT) 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 TGBxZI2yo0zu; Fri, 2 Aug 2013 03:49:10 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Fri, 2 Aug 2013 03:49:10 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id A585D80EC9; Fri, 2 Aug 2013 03:49:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9A2F880E8F; Fri, 2 Aug 2013 03:49:11 -0400 (EDT) Date: Fri, 2 Aug 2013 03:49:11 -0400 (EDT) From: Paul Wouters To: Olafur Gudmundsson In-Reply-To: Message-ID: References: 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@ietf.org list" Subject: Re: [dane] Expressive Short names for TLSA Record fields 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, 02 Aug 2013 07:49:26 -0000 On Thu, 1 Aug 2013, Olafur Gudmundsson wrote: > I think the best way to address this communication problem is to write a ID that defines the terms, and updates the IANA registry by adding a column > with the short name. > > Value Short Description Reference > 0 CA constraint [RFC6698] > 1 Service certificate constraint [RFC6698] > 2 Trust anchor assertion [RFC6698] > 3 Domain-issued certificate [RFC6698] > > Suggested names: 0 = PKIX-Cert, 1 = PKIX-TA, 2 == DANE-TA , 3 == DANE_Cert > > > For the selectors > Value Short Description Reference > 0 Full certificate [RFC6698] > 1 SubjectPublicKeyInfo [RFC6698] > > 0 = Cert, 1 === Key Agreed here, as I proved how confusing it is yesterday :) > For the digest algorithms we will just use the algorithm names SHA-256 and SHA-512. > Feel free to suggest better names, Based on my experience with IKE configuration syntax in the last decade, this seems a really bad idea. People have assumed "sha" is "sha1". When you say "sha-256" people now know it is sha2 because sha1 does not have 256 bits. But for sha3 that won't be true. We really aught to keep "sha" to be an alias to "sha1" only, and always use "sha2" and sha3" prefixes. Paul From warren@kumari.net Fri Aug 2 01:33: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 7D9C121E82C0 for ; Fri, 2 Aug 2013 01:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 QTQTJ8szSdeO for ; Fri, 2 Aug 2013 01:33:33 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F26B21F9D92 for ; Fri, 2 Aug 2013 01:31:37 -0700 (PDT) Received: from [130.129.0.225] (unknown [130.129.0.225]) by vimes.kumari.net (Postfix) with ESMTPSA id 4DB8A1B412CD; Fri, 2 Aug 2013 04:28:59 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Warren Kumari In-Reply-To: Date: Fri, 2 Aug 2013 10:28:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1508) Cc: "dane@ietf.org list" Subject: Re: [dane] Expressive Short names for TLSA Record fields 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, 02 Aug 2013 08:33:39 -0000 On Aug 1, 2013, at 6:36 PM, Olafur Gudmundsson wrote: >=20 > I think the best way to address this communication problem is to write = a ID that defines the terms, and updates the IANA registry by adding a = column=20 > with the short name.=20 >=20 As mentioned off-list, I think this is a grand idea=85. Sometimes, in some sort of other document, someone should write up a = recommendation to always use enums or named values or something. Even if you only start off with 2 values, eventually you add more and it = all gets confusing. "You connect over FOO (6)" is much clearer than "You = connect over 6", even if you figure everyone will remember what 6 is=85 W > Value Short Description = Reference > 0 CA constraint [RFC6698] > 1 Service certificate constraint [RFC6698] > 2 Trust anchor assertion [RFC6698] > 3 Domain-issued certificate [RFC6698] >=20 > Suggested names: 0 =3D PKIX-Cert, 1 =3D PKIX-TA, 2 =3D=3D DANE-TA , = 3 =3D=3D DANE_Cert=20 >=20 >=20 > For the selectors > Value Short Description = Reference > 0 Full certificate [RFC6698] > 1 SubjectPublicKeyInfo [RFC6698] >=20 > 0 =3D Cert, 1 =3D=3D=3D Key=20 >=20 > For the digest algorithms we will just use the algorithm names SHA-256 = and SHA-512.=20 > Feel free to suggest better names,=20 >=20 > Olafur >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From ondrej.sury@nic.cz Fri Aug 2 02:08: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 A3A8611E8210 for ; Fri, 2 Aug 2013 02:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaU9-z3RNvIc for ; Fri, 2 Aug 2013 02:08:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9342421F83EF for ; Fri, 2 Aug 2013 02:02:46 -0700 (PDT) Received: from [IPv6:2001:df8::96:297b:20d:2cd8:7470] (unknown [IPv6:2001:df8:0:96:297b:20d:2cd8:7470]) by mail.nic.cz (Postfix) with ESMTPSA id 3415713FDA1 for ; Fri, 2 Aug 2013 11:02:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375434152; bh=33xjhojKwlwYzkbxf0OzQJM5dr9+NEEi6flCsd3UY4Q=; h=From:Content-Type:Subject:Message-Id:Date:To:Mime-Version; b=ESjyh2VmnmQA1tRnQaBKLQnhLvS8gqatb4wT5R4iEFj09o9MYb/mBfF7rCSqHmI6l ZoanVPAdCjD5RJvnuSRmDsmKYtf+EgjuNvgYXYW7/d1K6umj/PGFuOuLowVsNsUAeN f9v+rxdNuWR6pzMyDA4aE0/Eyj+LhQ/SbWd7bnf0= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: multipart/signed; boundary="Apple-Mail=_F36B9A64-737F-4A16-9723-E48F4A76C476"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <39018622-D8A7-4E30-A137-C7BE15DB3A88@nic.cz> Date: Fri, 2 Aug 2013 11:02:28 +0200 To: dane@ietf.org list Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1786.1\)) X-Mailer: Apple Mail (2.1786.1) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: [dane] Postfix Ubuntu packages with DANE support 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, 02 Aug 2013 09:08:17 -0000 --Apple-Mail=_F36B9A64-737F-4A16-9723-E48F4A76C476 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hey all (with my Debian Developer hat on), I have created an Ubuntu PPA repository with Postfix 2.11-development = snapshot with DANE support in case you are running Ubuntu and you are too lazy to compile from the source: https://launchpad.net/~ondrej/+archive/postfix+dane I'll probably do the same for Debian in near future, but I don't have a = sensible infrastructure at this moment (since Debian doesn't have something = similar to PPA yet). And if you are even lazier and don't want to read the docs, just drop: smtp_dns_support_level =3D dnssec smtp_tls_security_level =3D dane smtp_tls_loglevel =3D 1 to your main.cf and restart postfix. Then the log would should this: Aug 2 10:35:49 jedi postfix/smtp[24161]: Verified TLS connection = established to mail.nic.cz[217.31.204.67]:25: TLSv1 with cipher = DHE-RSA-AES256-SHA (256/256 bits) Aug 2 10:38:06 jedi postfix/smtp[24161]: Verified TLS connection = established to = mailly.debian.org[2001:41b8:202:deb:6564:a62:52c3:4b72]:25: TLSv1.2 with = cipher DHE-RSA-AES256-SHA256 (256/256 bits) for DANE verified TLS. or this: Aug 2 10:46:54 jedi postfix/smtp[24300]: Untrusted TLS connection = established to aspmx.l.google.com[2a00:1450:4001:c02::1b]:25: TLSv1.2 = with cipher ECDHE-RSA-RC4-SHA (128/128 bits) for no TLSA. Ondrej -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- --Apple-Mail=_F36B9A64-737F-4A16-9723-E48F4A76C476 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMKTCCBgYw ggTuoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwga8xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVz dGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMzAx BgNVBAMTKlRydXN0ZWQgSW50cm9kdWNlciAoVEkpIFRvcGxldmVsIENBIC0gRzAwMTEnMCUGCSqG SIb3DQEJARYYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMB4XDTA0MTIwNzEwMzYxN1oXDTMwMTIw NjAwMDAwMFowga0xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJ KTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50 cm9kdWNlciAoVEkpIENsaWVudCBDQSAtIEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQt aW50cm9kdWNlci5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOKQxMR3KDUpfJBz AhY2BPCByKo9SMp/V0RIboLBD6vO0miSYO9FmP3Q07OKPYR5WdlQyrpKqB1zl0SRz2cDjnYkzvDF vK5kvMvlTYeQlHypQlvhkTsYWD4ZZxxEhAYBb1s7cYaIahLw6H/RZz+kyWTOc9TncPBvBWIQ1Ypo S+uQqpopH8s5ebtB/17SbUty5yXiHoaPh/ScdMKqxbyJiL0YRM6SU4YX4HVZ5YGS9aWuiUSiA0YF 8dCR56nErx67wgq8O1GtsSKKOf/ueUxSmrqwgQNlfM9Or5O8kb61s1O2iACHtixoV3ENanylBafU mRYpNo5tSZsElGfntMoGBy8CAwEAAaOCAiswggInMB0GA1UdDgQWBBSeX93lU8ExaSlN1ZaXxfOP h2iHTjCB3AYDVR0jBIHUMIHRgBRdbehwJx/8iwlxnguJECc7MUXvoqGBtaSBsjCBrzELMAkGA1UE BhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAoVEkpMSAwHgYDVQQLExdDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTEzMDEGA1UEAxMqVHJ1c3RlZCBJbnRyb2R1Y2VyIChUSSkgVG9wbGV2 ZWwgQ0EgLSBHMDAxMScwJQYJKoZIhvcNAQkBFhhjYUB0cnVzdGVkLWludHJvZHVjZXIubmyCAQAw DwYDVR0TAQH/BAUwAwEB/zAjBgNVHRIEHDAagRhjYUB0cnVzdGVkLWludHJvZHVjZXIubmwwgasG A1UdHwSBozCBoDBOoEygSoZIaHR0cDovL2NybDEudHJ1c3RlZC1pbnRyb2R1Y2VyLm5sL2NhL3g1 MDkvZzEvZGF0YS9jcmxzL2NybC1yb290LWNhLTEuY3JsME6gTKBKhkhodHRwOi8vY3JsMi50cnVz dGVkLWludHJvZHVjZXIubmwvY2EveDUwOS9nMS9kYXRhL2NybHMvY3JsLXJvb3QtY2EtMS5jcmww IwYDVR0RBBwwGoEYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMAsGA1UdDwQEAwIBBjARBglghkgB hvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEFBQADggEBAI1sC2l8st3ElC74az6gH7tGXSiS7jicpHeI 10A3KY+7OEPT7BAJDpjMXxSvAwU1vBDFfwEAXGj42xAPB6cynOTDn0OiFpYGvi3EZV3khXYkGPLs fxZttUyDKqhXcWYy4nnI3fBxqCgLboJFw6OO/SVj5qQdXMZ7VhyFBWJMQkVOnlt6i3xFkG3O5LMI BDmdL5bZPEe8b6bJkMr+rUYEvorPJmV+CkiewYMaruCbdhwRkpkhXB3qLwB2ppnKxSinAU4f9Rcp p73h8iDVQ9389iliUKomVQqj9NJv2G6SyJdDQdN2vrldLszNpw6t+zIzCjpgQ//kem5BJ1k4YG3L CpAwggYbMIIFA6ADAgECAgIGSDANBgkqhkiG9w0BAQUFADCBrTELMAkGA1UEBhMCTkwxIDAeBgNV BAoTF1RydXN0ZWQgSW50cm9kdWNlciAoVEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJbnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEn MCUGCSqGSIb3DQEJARYYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMB4XDTEyMDgwMTA3NTEyNloX DTE0MDgwMTA3NTEyNlowejELMAkGA1UEBhMCTkwxGzAZBgNVBAoTElRydXN0ZWQgSW50cm9kdWNl cjEVMBMGA1UECxMMQ1ouTklDLUNTSVJUMRQwEgYDVQQDEwtPbmRyZWogU3VyeTEhMB8GCSqGSIb3 DQEJARYSb25kcmVqLnN1cnlAbmljLmN6MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA xlmN+hSg6RxWm1X6QOI3OXHSAqhRzWGb8ismR2+3LGDS640luS8x4VdWo490Ceqz+BZvMhQJwfny 9mb0IejFpx7kBOM7k2rMfOYUXa/pq07ysWEI8bXDcXRBf2ZcG0B/gajLPFA9MADlCWHSf7cNZF6S XnIHwTn5DowxpbF403NqLWFnTM08wTJkFgGB7WZAtE6KoSigztI39NrtKRsnosZoBMNZS/JG1CLt VdZPvkHVuiVQWEGYgswBEMGXoR7jtzVNhHr2F1atoBICJVGWFNA8fHvQRLAcXWJTXhKxb2uSq9Yp kKaZPZ6rrp88qtemvwVnQKE9r3/iPFeTARY7AQIDAQABo4ICdTCCAnEwDAYDVR0TAQH/BAIwADAd BgNVHQ4EFgQUgizwG0IeMZQlCSduLVeM1zDBdUEwgdwGA1UdIwSB1DCB0YAUnl/d5VPBMWkpTdWW l8Xzj4doh06hgbWkgbIwga8xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVj ZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMzAxBgNVBAMTKlRydXN0 ZWQgSW50cm9kdWNlciAoVEkpIFRvcGxldmVsIENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FA dHJ1c3RlZC1pbnRyb2R1Y2VyLm5sggECMCMGA1UdEgQcMBqBGGNhQHRydXN0ZWQtaW50cm9kdWNl ci5ubDAdBgNVHREEFjAUgRJvbmRyZWouc3VyeUBuaWMuY3owCwYDVR0PBAQDAgSwMCcGA1UdJQQg MB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwEQYJYIZIAYb4QgEBBAQDAgSwMIHVBgNV HR8Egc0wgcowY6BhoF+GXWh0dHA6Ly9jcmwxLnRydXN0ZWQtaW50cm9kdWNlci5ubC9jYS94NTA5 L2cxL2NhLXNzbC1jbGllbnQvZzEvZGF0YS9jcmxzL2NybC1jbGllbnQtY2EtMS0xLmNybDBjoGGg X4ZdaHR0cDovL2NybDIudHJ1c3RlZC1pbnRyb2R1Y2VyLm5sL2NhL3g1MDkvZzEvY2Etc3NsLWNs aWVudC9nMS9kYXRhL2NybHMvY3JsLWNsaWVudC1jYS0xLTEuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQAZP/dznHW3BWajBVQ3fTaDsx/3csUE6+jX83r1dgzYjUOmapOzXQVZ2/VTwZTzJSsD7rDgzUN6 sk6YWmUJOwqoEcPasYG9zt9e+bpwc/PURjSowb+WjEE2e4L47x3mPgL0dtlGj4guhRaj247K9N1f grvlyX0h/IL9JO4CN0I5lAuOaZ3Yfl0euHpHLlXZ9czxkc6dCbtGSZwr3RrltNmMjhp0O3D51fDd D6mG1vvOEV9Kj1JfSE2cQI5j3GpMlNleZA6noZ93drs2G9/D7WP4uVLCtJfGmG6PJsy4+qN46qXu ekJR/8WH1aNcH0Ya+JsYrwIFPwL4Cr+JXrbFqUOFMYIDzzCCA8sCAQEwgbQwga0xCzAJBgNVBAYT Ak5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBD QSAtIEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwCQYF Kw4DAhoFAKCCAe8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMw ODAyMDkwMjMwWjAjBgkqhkiG9w0BCQQxFgQU7hRPbxp86Ed9ps130wiNyfgLvpcwgcUGCSsGAQQB gjcQBDGBtzCBtDCBrTELMAkGA1UEBhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAo VEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJ bnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FAdHJ1c3Rl ZC1pbnRyb2R1Y2VyLm5sAgIGSDCBxwYLKoZIhvcNAQkQAgsxgbeggbQwga0xCzAJBgNVBAYTAk5M MSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBDQSAt IEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwDQYJKoZI hvcNAQEBBQAEggEAO2BAW6i4m+fQIXtJRr/sbup3peuyfrIT9D3uT9DhxMcuXJMjY4kf4d99yqEf fvcbcyo+bqp0WfCa58notPZCTD9aY4PpC9iv7NTlhDivzGjGArI2mhylzzMyxOzf262gApVYm7VZ UywZvThW18DSGfb25+Pt3DB+RppCq52xYlUsFMhtCXQQtbBQruU2N4XZtkCxYm+2lkc/zl2mAMVy 76lGp566wLfl5suDw8C4FfY04KPb8T3T6NOXt18UWFCCQl5/ysc3vSsE25lEqNzY6OSsvbWYuXGR GJ7HVEO/vraTUV+Qd7AlnB2cy1+GE7F9WMaooj9Q1qkVxl6MtvPzzwAAAAAAAA== --Apple-Mail=_F36B9A64-737F-4A16-9723-E48F4A76C476-- From 35nlv6@nottheoilrig.com Fri Aug 2 14:04:00 2013 Return-Path: <35nlv6@nottheoilrig.com> 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 349E321F9D5F for ; Fri, 2 Aug 2013 14:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] 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 ETvs5s6XyCUM for ; Fri, 2 Aug 2013 14:03:55 -0700 (PDT) Received: from mail.nottheoilrig.com (mail.nottheoilrig.com [50.16.249.74]) by ietfa.amsl.com (Postfix) with ESMTP id BD0B321F9C10 for ; Fri, 2 Aug 2013 14:03:55 -0700 (PDT) Received: from mail.nottheoilrig.com (localhost [127.0.0.1]) by mail.nottheoilrig.com (Postfix) with ESMTP id 66ADA40BBB for ; Fri, 2 Aug 2013 21:03:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nottheoilrig.com; s=mail; t=1375477434; bh=cxnwfrpOOJW0GA/mqEijilgWR0WIVLAdVt2YEQmD3F0=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=FavuAIxEMDNtKlwcJCwp9xST6XnIEo88j4xSO6IUEKC2luCPPIywWfP9VdXVDvFoH rcq+Bl1/WZfuvsnVWP1YQRTaJILlPggGPuSo3+Mgf6OLDyoyjJ45HLrViE9wA39ZZM lTCyF0lcDjQUCPuJTbMogS4byKAnjxerm2UFV9v0= Received: from [192.168.0.11] (S0106c8fb26402908.ek.shawcable.net [24.66.136.12]) by mail.nottheoilrig.com (Postfix) with ESMTPSA for ; Fri, 2 Aug 2013 21:03:53 +0000 (UTC) Message-ID: <51FC1EB8.90502@nottheoilrig.com> Date: Fri, 02 Aug 2013 14:03:52 -0700 From: Jack Bates <35nlv6@nottheoilrig.com> User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dane] DNS hosting 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, 02 Aug 2013 21:04:00 -0000 Hello, does someone on the list know about a DNS hosting provider with support for TLSA records? Or are folks who already published TLSA records mostly managing their own DNS servers? Here are some of the hosting providers I checked, several now support DNSSEC, but unfortunately no support for TLSA records yet: o DreamHost o Namecheap o GKG o Go Daddy o easyDNS I guess Dyn might support TLSA records, but only as part of their premium service (I haven't confirmed yet) http://dyn.com/dns/dns-comparison/ Thanks! From paulitrix@gmail.com Sat Aug 3 02:08: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 3AD5221F968B for ; Sat, 3 Aug 2013 02:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 vEg2Yjx3uAPe for ; Sat, 3 Aug 2013 02:08:45 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2F421F935A for ; Sat, 3 Aug 2013 02:08:44 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id bv4so106188qab.6 for ; Sat, 03 Aug 2013 02:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Uhn2OIUvcVRnL8v1d+iXEmYfUh3RNd1QTcrXNCeNUsg=; b=qmnnpGzH/6ss7Hw2jD8QOcdRIuHp1nATrTUUZB4v12PO4739dgerv08aPz4ZLFM2KV MNB6QPi3magxBFe62uQfujrNQzuPxmqL0TZO2l1mk4a536IAxuglAeozCrlsBb6FJ3f/ YjotN27kT87tVSL474uQAD9GytlQEkNjTQBQopMu4tlMq4pzqsERz4m53A4K4Kr58Ek/ IE01egtTEbSPeth3roPvDUQwDdQZZUrvperR+ZkokajFocgqX4eg+RVPqnaSB0q7Ci+3 +FAhZs+9R4VAFHtVYDalpn5If2GQY+MQOWD2bBuGu2mNHeyqsIbaAP/5hBxTfkIyJ684 lQEw== MIME-Version: 1.0 X-Received: by 10.224.49.130 with SMTP id v2mr15841953qaf.75.1375520923495; Sat, 03 Aug 2013 02:08:43 -0700 (PDT) Received: by 10.224.37.197 with HTTP; Sat, 3 Aug 2013 02:08:43 -0700 (PDT) In-Reply-To: <51FC1EB8.90502@nottheoilrig.com> References: <51FC1EB8.90502@nottheoilrig.com> Date: Sat, 3 Aug 2013 12:08:43 +0300 Message-ID: From: Paul M To: Jack Bates <35nlv6@nottheoilrig.com> Content-Type: multipart/alternative; boundary=001a11c2fc5606b15c04e3076c7a Cc: IETF DANE WG list Subject: Re: [dane] DNS hosting X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 09:08:48 -0000 --001a11c2fc5606b15c04e3076c7a Content-Type: text/plain; charset=ISO-8859-1 Jack there are exceedingly rare implementors of DANE and the two I've come across seem to manage their own DNS servers. I came across Netfuture because of this tutorial they published it seems they have their own TLSA records: https://netfuture.ch/2013/06/how-to-create-dnssec-dane-tlsa-entries/ and Nlnetlabs who've written software that supports DANE: http://www.nlnetlabs.nl/ Currently, its a very tall order getting even one DNS hosting provider implementing DANE. Maybe others in the DANE mailing list can give us a hint. On Sat, Aug 3, 2013 at 12:03 AM, Jack Bates <35nlv6@nottheoilrig.com> wrote: > Hello, does someone on the list know about a DNS hosting provider with > support for TLSA records? Or are folks who already published TLSA records > mostly managing their own DNS servers? > > Here are some of the hosting providers I checked, several now support > DNSSEC, but unfortunately no support for TLSA records yet: > > o DreamHost > o Namecheap > o GKG > o Go Daddy > o easyDNS > > I guess Dyn might support TLSA records, but only as part of their premium > service (I haven't confirmed yet) http://dyn.com/dns/dns-**comparison/ > > Thanks! > ______________________________**_________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/**listinfo/dane > -- :-) Paul M --001a11c2fc5606b15c04e3076c7a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Jack there are exceedingly rare implementors of DANE and t= he two I've come across seem to manage their own DNS servers.
=A0
I came across Netfuture because of this tutorial they published it= seems they have their own TLSA records:=A0https://netfuture.ch/2013/= 06/how-to-create-dnssec-dane-tlsa-entries/=A0and Nlnetlabs who've w= ritten =A0software that supports DANE:=A0http://www.nlnetlabs.nl/=A0=A0

Currently, its a very tall order getting even one DNS h= osting provider implementing DANE. Maybe others in the DANE mailing list ca= n give us a hint.=A0


On Sat, Aug 3, 2013 at 12:03 AM, Jack Bates <35nlv6@nottheoilrig.c= om> wrote:
Hello, does someone on the list know about a DNS hosting provider with supp= ort for TLSA records? Or are folks who already published TLSA records mostl= y managing their own DNS servers?

Here are some of the hosting providers I checked, several now support DNSSE= C, but unfortunately no support for TLSA records yet:

=A0 =A0o =A0DreamHost
=A0 =A0o =A0Namecheap
=A0 =A0o =A0GKG
=A0 =A0o =A0Go Daddy
=A0 =A0o =A0easyDNS

I guess Dyn might support TLSA records, but only as part of their premium s= ervice (I haven't confirmed yet) http://dyn.com/dns/dns-comparison/
Thanks!
_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
:-) Paul M
--001a11c2fc5606b15c04e3076c7a-- From benl@google.com Sat Aug 3 06:43:22 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DA421F9D83 for ; Sat, 3 Aug 2013 06:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.98 X-Spam-Level: X-Spam-Status: No, score=-0.98 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDtlGzFwzBI3 for ; Sat, 3 Aug 2013 06:43:21 -0700 (PDT) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 35B8521F9D96 for ; Sat, 3 Aug 2013 06:43:19 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id 1so914970qee.27 for ; Sat, 03 Aug 2013 06:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=uREHhji4YXbMUfhDlPNsW3mDABcyw4VI7eQWR9dUtJk=; b=XXmQHR7ltPWf6OgOkajhqUlo2M4+4mfst+TUdnNLvZW0OrLGuudlRGXD+5k9aJlcwq 3SZpkDPvS96UzM+S9v5yl3lHpniGstj//OojrLNsjmDdd1QTiashDhfHMlSlOqY5dx/H pQjBO4bzMFIqlL5uG6vQTUG/WGXBQjB8XDaF6cp8XX3Zlscn+pbSYqvxfN8CSVLASquh 9VeES7RF+mcx4Bg+pcQFR+DuKfULaGcFDtk4asq3UQHlVOxPTM1OUkF+8oCpFxFK9Dz+ ZT/OGXJx+WdBXg53KpoK+4Cq+cYODtS7sqn4MwoFV1vvz11zR28GSKrj++P6PHV8peTD ENfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=uREHhji4YXbMUfhDlPNsW3mDABcyw4VI7eQWR9dUtJk=; b=QWkd6naPWW09vfW5EHqZq6JcRwRG3EPsXKnb0WYnxGgeO7bk/4l69MnxhNArKEn6iF K3AyRkWZ+gpmEQpEgjXr7tv7INqsKncALxL48axdTefj5FYe3rxO3yf6e/9CGNeqIG4C i5CiziTDB2Vg+tgS7nWcazPleuGUZa9zHy407+r3a1upYGxFH+AuzYlw02nX2y4IcQkh Jqrn9wLIuvY5JoPq0RGhiwjva79oqYWtQi2Zh2OUtwRHC7UDlSp2iJkHareF6xofeVHX cfDm886WHNxOMx18inW9Vhyiv/YZRbZK9eZJiy+SVF3eqnXY24d8lpVGBzkw3wAK6rri eugQ== MIME-Version: 1.0 X-Received: by 10.224.21.202 with SMTP id k10mr17593830qab.10.1375537398617; Sat, 03 Aug 2013 06:43:18 -0700 (PDT) Received: by 10.229.169.196 with HTTP; Sat, 3 Aug 2013 06:43:18 -0700 (PDT) Date: Sat, 3 Aug 2013 14:43:18 +0100 Message-ID: From: Ben Laurie To: "tls@ietf.org" , IETF DANE WG list , certificate-transparency@googlegroups.com, "therightkey@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf0c10c05508f04e30b4266 X-Gm-Message-State: ALoCoQluIHUCka9lW1hNgl7Fdshc9vgGtnOD6uMyLGfLR9FC8AVyhSahg9eOHUNgNcPRGVHbpAClDUo3PJDXudc6AwMPj2b7nRt8bx9OEDqmiTzM8HjmcZMzkRTuJ/KM2OMBfojFqxtbwRDMzt/QyCHi1gRSMwsXhcIqMZwjgNaVZoMlbvNuSNKe7NhpHrppfqTv4ugVIGDO Subject: [dane] Certificate Transparency Hack Day: Weds Aug 28th X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 13:43:22 -0000 --047d7bf0c10c05508f04e30b4266 Content-Type: text/plain; charset=ISO-8859-1 We've set the date: Weds Aug 28th at Google's London office. More information to follow soon. --047d7bf0c10c05508f04e30b4266 Content-Type: text/html; charset=ISO-8859-1
We've set the date: Weds Aug 28th at Google's London office.

More information to follow soon.

--047d7bf0c10c05508f04e30b4266-- From warren@kumari.net Sat Aug 3 07:32:18 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E669B21F9EED for ; Sat, 3 Aug 2013 07:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.536 X-Spam-Level: X-Spam-Status: No, score=-99.536 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_HTML_USL_OBFU=1.666, 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 FKUmzruoo8WS for ; Sat, 3 Aug 2013 07:32:15 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3BE21F9EF0 for ; Sat, 3 Aug 2013 07:32:14 -0700 (PDT) Received: from [10.32.34.4] (unknown [31.221.87.75]) by vimes.kumari.net (Postfix) with ESMTPSA id 021551B40357; Sat, 3 Aug 2013 10:32:13 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-228D5E65-D137-4453-B480-23E468DA4B70 Content-Transfer-Encoding: 7bit References: <51FC1EB8.90502@nottheoilrig.com> In-Reply-To: Mime-Version: 1.0 (1.0) Message-Id: <109FC22B-8C2E-4A86-AE6A-2010C841D0CE@kumari.net> From: Warren Kumari Date: Sat, 3 Aug 2013 15:28:37 +0100 To: Paul M X-Mailer: iPhone Mail (10B350) Cc: IETF DANE WG list Subject: Re: [dane] DNS hosting X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 14:32:19 -0000 --Apple-Mail-228D5E65-D137-4453-B480-23E468DA4B70 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Apologies for terseness, about to board plane. Registro.br has a hosted DNS solution where you register the domain, and if y= ou host your DNS with them you simply click a lock icon -- they go fetch the= cert (from www.example.com), validate it and then publish a TLSA record. It is very slick -- Frederico Neves has been promising to do a write up wit= h screenshots and such, but keeps getting sidetracked... W Warren Kumari ------ Please excuse typing, etc -- This was sent from a device with a tiny keyboar= d. On Aug 3, 2013, at 10:08 AM, Paul M wrote: > Jack there are exceedingly rare implementors of DANE and the two I've come= across seem to manage their own DNS servers. > =20 > I came across Netfuture because of this tutorial they published it seems t= hey have their own TLSA records: https://netfuture.ch/2013/06/how-to-create-= dnssec-dane-tlsa-entries/ and Nlnetlabs who've written software that suppor= ts DANE: http://www.nlnetlabs.nl/ =20 >=20 > Currently, its a very tall order getting even one DNS hosting provider imp= lementing DANE. Maybe others in the DANE mailing list can give us a hint.=20= >=20 >=20 > On Sat, Aug 3, 2013 at 12:03 AM, Jack Bates <35nlv6@nottheoilrig.com> wrot= e: >> Hello, does someone on the list know about a DNS hosting provider with su= pport for TLSA records? Or are folks who already published TLSA records most= ly managing their own DNS servers? >>=20 >> Here are some of the hosting providers I checked, several now support DNS= SEC, but unfortunately no support for TLSA records yet: >>=20 >> o DreamHost >> o Namecheap >> o GKG >> o Go Daddy >> o easyDNS >>=20 >> I guess Dyn might support TLSA records, but only as part of their premium= service (I haven't confirmed yet) http://dyn.com/dns/dns-comparison/ >>=20 >> Thanks! >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 >=20 >=20 > --=20 > :-) Paul M > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --Apple-Mail-228D5E65-D137-4453-B480-23E468DA4B70 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Apologies for terseness, about to boar= d plane.

Registro.br= has a hosted DNS solution where you register the domain, and if you hos= t your DNS with them you simply click a lock icon -- they go fetch the cert (= from www.example.com), validate it an= d then publish a TLSA record.

It is very slick -- Fre= derico  Neves has been promising to do a write up with screenshots and s= uch, but keeps getting sidetracked...

W

Warren Kumari
------
Please excuse typing, etc -- This was s= ent from a device with a tiny keyboard.

On Aug 3, 2013, at 10:= 08 AM, Paul M <paulitrix@gmail.com= > wrote:

Jack there are exceedingly rare implementors of DANE and the two I've come a= cross seem to manage their own DNS servers.
 
I came acro= ss Netfuture because of this tutorial they published it seems they have thei= r own TLSA records: https://netfuture.ch/2013/06/how-to-create-dns= sec-dane-tlsa-entries/ and Nlnetlabs who've written  software t= hat supports DANE: h= ttp://www.nlnetlabs.nl/  

Currently, its a very tall order getting even one DNS ho= sting provider implementing DANE. Maybe others in the DANE mailing list can g= ive us a hint. 





--
:-) Paul M
____________________= ___________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman= /listinfo/dane
= --Apple-Mail-228D5E65-D137-4453-B480-23E468DA4B70-- From cloos@jhcloos.com Sat Aug 3 08:17:10 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 0240F11E8118 for ; Sat, 3 Aug 2013 08:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.26 X-Spam-Level: X-Spam-Status: No, score=0.26 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, GB_AFFORDABLE=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 ReXo+rjgTJv4 for ; Sat, 3 Aug 2013 08:17:06 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id 460F011E80AD for ; Sat, 3 Aug 2013 08:17:05 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id A07ED1DDC0; Sat, 3 Aug 2013 15:16:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1375543018; bh=2F+7kCi8J6pDBdH18cWYypcWkV6QLbAAVgSqzjm4W5k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=SrlkUcOxnAUT7RRyc1uJcXW1557Ud4a68GcyCSyQAuTw+J52AozMl+Cl280CE8Sji I8mCgnXnGOo3tpB96BEiQNg0c7fCuBFcoTYDWSWfaiJC2ByAiNyKHokjruX9iJOW4D 8QHruTPY9gfie25qoQuesr9htKS2vP7PxztMPJy36PQ== Received: by carbon.jhcloos.org (Postfix, from userid 500) id CD67273DB5; Sat, 3 Aug 2013 15:14:22 +0000 (UTC) From: James Cloos To: DANE WG In-Reply-To: <51FC1EB8.90502@nottheoilrig.com> (Jack Bates's message of "Fri, 02 Aug 2013 14:03:52 -0700") References: <51FC1EB8.90502@nottheoilrig.com> 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: Sat, 03 Aug 2013 11:14:21 -0400 Message-ID: Lines: 28 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:130803:dane@ietf.org::joNjuru+FDU//feC:0001Qu2N X-Hashcash: 1:28:130803:35nlv6@nottheoilrig.com::ohyOa7MGiiMpbySX:0000000000000000000000000000000000000ZCxo0 Subject: Re: [dane] DNS hosting X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 15:17:10 -0000 >>>>> "JB" == Jack Bates <35nlv6@nottheoilrig.com> writes: JB> Hello, does someone on the list know about a DNS hosting provider with JB> support for TLSA records? Or are folks who already published TLSA JB> records mostly managing their own DNS servers? You can use a number of such providers for their secondary service, but I do not know of any whose primary service includes support for web-based editing of zone with TLSA records. Virtual servers can be leased for as little as 12-60 USD per year with enough ram and net, disk & memory bandwidth to run a DNS server. There are some web front-ends available to help manage your own primary, depending on which server you choose. http://lowendbox.com is a good resource for finding affordable virtual servers. http://puck.nether.net/dns and https://acc.rollernet.us/help/dns/secondary.php are good no-cost, dnssec-capable secondary services. (I cannot speak for them, but given that rollernet's primary service supports dnssec and records like sshfp, they *might* be responsive to a request to add support for tlsa, too.) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From jakob@kirei.se Mon Aug 5 12:57:49 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 AF00A21F9E1A for ; Mon, 5 Aug 2013 12:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 IwEgfhPXfX77 for ; Mon, 5 Aug 2013 12:57:44 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [91.206.174.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5A05D21F9D89 for ; Mon, 5 Aug 2013 12:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=zO/+CHNtv99IbhnkBdu/mkkB2Z6kB2UhyRNn4UqumO8=; b=K5HVHaaiRsAu6zyoIWj7R3gNRVyErj9fj/LPtQnjPJ1MIsVXIC7NUOxKCTzItigj3B+TnBpKE3sM5 OAAj7QYK/AEtiCDob6M6G3TYtVfSN5mTJjL2VwJ6Fm2ODJRGwR+B3Ytm8Xf+C/GPRRfP8Wpxpkz9pw VHpn6lywRe5E70gs= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Mon, 5 Aug 2013 21:41:22 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jakob Schlyter In-Reply-To: Date: Mon, 5 Aug 2013 21:41:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <644C1ABF-3FA2-4A04-B992-EE0ED9AA9118@kirei.se> References: To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1508) Cc: "dane@ietf.org list" Subject: Re: [dane] Expressive Short names for TLSA Record fields 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, 05 Aug 2013 19:57:49 -0000 On 1 aug 2013, at 18:36, Olafur Gudmundsson wrote: > Value Short Description = Reference > 0 CA constraint [RFC6698] > 1 Service certificate constraint [RFC6698] > 2 Trust anchor assertion [RFC6698] > 3 Domain-issued certificate [RFC6698] >=20 > Suggested names: 0 =3D PKIX-Cert, 1 =3D PKIX-TA, 2 =3D=3D DANE-TA , = 3 =3D=3D DANE_Cert=20 Although I assume you mean: 0 =3D PKIX-TA 1 =3D PKIX-CERT 2 =3D DANE-TA 3 =3D DANE-CERT jakob From ogud@ogud.com Tue Aug 6 04:50: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 2824A21F98AC for ; Tue, 6 Aug 2013 04:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f56ir2BcoKd0 for ; Tue, 6 Aug 2013 04:50:00 -0700 (PDT) Received: from smtp108.ord1c.emailsrvr.com (smtp108.ord1c.emailsrvr.com [108.166.43.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1976521F9633 for ; Tue, 6 Aug 2013 04:49:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id E027998101; Tue, 6 Aug 2013 07:49:56 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id A6DD698107; Tue, 6 Aug 2013 07:49:55 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olafur Gudmundsson In-Reply-To: <644C1ABF-3FA2-4A04-B992-EE0ED9AA9118@kirei.se> Date: Tue, 6 Aug 2013 07:50:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <644C1ABF-3FA2-4A04-B992-EE0ED9AA9118@kirei.se> To: Jakob Schlyter X-Mailer: Apple Mail (2.1508) Cc: "dane@ietf.org list" Subject: Re: [dane] Expressive Short names for TLSA Record fields 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, 06 Aug 2013 11:50:05 -0000 On Aug 5, 2013, at 3:41 PM, Jakob Schlyter wrote: > On 1 aug 2013, at 18:36, Olafur Gudmundsson wrote: >=20 >> Value Short Description = Reference >> 0 CA constraint [RFC6698] >> 1 Service certificate constraint [RFC6698] >> 2 Trust anchor assertion [RFC6698] >> 3 Domain-issued certificate [RFC6698] >>=20 >> Suggested names: 0 =3D PKIX-Cert, 1 =3D PKIX-TA, 2 =3D=3D DANE-TA , = 3 =3D=3D DANE_Cert=20 >=20 > Although I assume you mean: >=20 > 0 =3D PKIX-TA > 1 =3D PKIX-CERT > 2 =3D DANE-TA > 3 =3D DANE-CERT >=20 >=20 > jakob >=20 Yes I do,=20 Olafur From stephen.farrell@cs.tcd.ie Tue Aug 6 05:03: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 D2CBE21F9EA9 for ; Tue, 6 Aug 2013 05:03:50 -0700 (PDT) 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 BXk-tzxkX2sY for ; Tue, 6 Aug 2013 05:03:46 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1A16421F9D96 for ; Tue, 6 Aug 2013 05:03:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EF498BE25; Tue, 6 Aug 2013 13:03:43 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxdSiPJ0BG3m; Tue, 6 Aug 2013 13:03:42 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.64.202]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A0100BDE3; Tue, 6 Aug 2013 13:03:42 +0100 (IST) Message-ID: <5200E61D.9050300@cs.tcd.ie> Date: Tue, 06 Aug 2013 13:03:41 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Olafur Gudmundsson References: <644C1ABF-3FA2-4A04-B992-EE0ED9AA9118@kirei.se> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dane@ietf.org list" Subject: Re: [dane] Expressive Short names for TLSA Record fields 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, 06 Aug 2013 12:03:51 -0000 On 08/06/2013 12:50 PM, Olafur Gudmundsson wrote: > > On Aug 5, 2013, at 3:41 PM, Jakob Schlyter wrote: > >> On 1 aug 2013, at 18:36, Olafur Gudmundsson wrote: >> >>> Value Short Description Reference >>> 0 CA constraint [RFC6698] >>> 1 Service certificate constraint [RFC6698] >>> 2 Trust anchor assertion [RFC6698] >>> 3 Domain-issued certificate [RFC6698] >>> >>> Suggested names: 0 = PKIX-Cert, 1 = PKIX-TA, 2 == DANE-TA , 3 == DANE_Cert >> >> Although I assume you mean: >> >> 0 = PKIX-TA >> 1 = PKIX-CERT >> 2 = DANE-TA >> 3 = DANE-CERT Names are better than numbers for this I fully agree and the above would be a useful improvement. I have a quibble though;-) I'm not sure that TA/CERT is the right distinction since both trust anchors and pretty much everything else in PKIX are represented by certificates. In pure PKIX terms, that'd maybe be more like TA/EE (EE=end-entity), but I'm not sure if that terminology would be useful or not for those less steeped in PKIXishness. S. PS: no hats or anything, just a nitty comment. >> >> >> jakob >> > > Yes I do, > > Olafur > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > From jakob@kirei.se Tue Aug 6 06:47: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 B096821F859B for ; Tue, 6 Aug 2013 06:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 4PJGPmrOqui9 for ; Tue, 6 Aug 2013 06:47:07 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [91.206.174.9]) by ietfa.amsl.com (Postfix) with ESMTP id 55D2A21F9D05 for ; Tue, 6 Aug 2013 06:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=Fd0+JcxmpaKR1rZBN5H094eenfn3RmbfmEcqAQFyDXM=; b=CXPUVGJsdBNcssPJk4GSuyCy//A58RTOe8Tj7hvW7Xxz+c+7fIfCVKznAU0hqvEdeDD5Cv6NfAKM6 6vGmrY93cKrKkzrnqJrUUnSnq78uY8E+RiVUS+ZBny66yLPe4bCgpFSyBIFQ88NdQLPuloglDJf5vS AGduk7ndwXi4Qo24= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 6 Aug 2013 15:30:48 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jakob Schlyter In-Reply-To: <5200E61D.9050300@cs.tcd.ie> Date: Tue, 6 Aug 2013 15:30:50 +0200 Content-Transfer-Encoding: 7bit Message-Id: <902DE9E3-985B-4640-A824-8CDAD80D9177@kirei.se> References: <644C1ABF-3FA2-4A04-B992-EE0ED9AA9118@kirei.se> <5200E61D.9050300@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) Cc: "dane@ietf.org list" Subject: Re: [dane] Expressive Short names for TLSA Record fields 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, 06 Aug 2013 13:47:12 -0000 On 6 aug 2013, at 14:03, Stephen Farrell wrote: > I'm not sure that TA/CERT is the right distinction since both > trust anchors and pretty much everything else in PKIX are > represented by certificates. In pure PKIX terms, that'd maybe > be more like TA/EE (EE=end-entity), but I'm not sure if that > terminology would be useful or not for those less steeped in > PKIXishness. Yes, {PKIX,DANE}-{TA,EE} would be better. jakob From hallam@gmail.com Tue Aug 6 11:51: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 AD34D21E8091; Tue, 6 Aug 2013 11:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 C-a737wUiaIN; Tue, 6 Aug 2013 11:51:42 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id A4B2621E809B; Tue, 6 Aug 2013 11:51:27 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so698220wgh.5 for ; Tue, 06 Aug 2013 11:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CkRYxJsK7c7e3XmMiOGOcD3QagIW3iN7Emn9Si4p0pw=; b=ZRfqFxGVJsb6tgJ23Kwq559h+JtvVAPLRJ+W+maGMYzZ0LatwMsq70RoomX2h3fAcI ZQlcz4EzXxpXp1HFyZxhmlmfyWEhSCW7k8qDFPqprkJnPaFbv/MDxhUWSHCs7iyL2hbv r8xzUIqWjmnR45IX/FGUtwqTSH2Vu/hIeygNZG4WjmAnRO9+/k1emhkb2QFSzCV28bPc KUKisMrnS5bjM/66Jy6Y3sixEimH029y66cDR3OE51wyxqAaaDwKzxHkFSJqmEJKCCdr WOkzW09SzQRCh8gnp7W+aX0apWxf3PVgS1JQ/FwW+OG4rp2LtdkgDdgMKQ7fwN0EtUEX TA5w== MIME-Version: 1.0 X-Received: by 10.194.242.134 with SMTP id wq6mr1993818wjc.94.1375815083770; Tue, 06 Aug 2013 11:51:23 -0700 (PDT) Received: by 10.194.6.67 with HTTP; Tue, 6 Aug 2013 11:51:23 -0700 (PDT) In-Reply-To: References: <030F2A8C-1C25-4C91-88FD-C81AF44FA98E@openfortress.nl> Date: Tue, 6 Aug 2013 14:51:23 -0400 Message-ID: From: Phillip Hallam-Baker To: "Rick van Rein (OpenFortress)" Content-Type: multipart/alternative; boundary=089e0141a1fc584bc904e34be980 Cc: openpgp@ietf.org, "dane@ietf.org" Subject: Re: [dane] =?windows-1252?q?Storing_public_keys_in_DNS=85_or_LDAP?= 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, 06 Aug 2013 18:51:43 -0000 --089e0141a1fc584bc904e34be980 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sounds like you are proposing this. http://www.ietf.org/rfc/rfc4386.txt For what it is worth, I agree that using the DNS to store per-user data is not a good approach. The DNS administration model is that it makes assertions about network names and not individual users. Previous attempts to put end users in the DNS have uniformly met with failure. But that does not mean that LDAP is a useful tool. LDAP has tons of complexity and none of it does the slightest bit of good. While writing my RFC tool I thought about writing a spec for an Internet bibliography service that would convert labels [RFC4386] to XML documents describing the reference. Then after a fairly short amount of work I realized that I could do everything I wanted using HTTP and some simple regular expression pattern matching. And the regexp stuff was only necessary because I wanted to reuse the existing libraries of references at xml.resource.org. So if you want to do per client records my suggestion would be 1) Use HTTP as the query language transport. 2) Put some form of pointer to the service in the DNS. 3) Use DNSSEC to secure the binding It might well be that (2) is a case where NAPTR would be a good solution. Or it might not. On Fri, Jul 26, 2013 at 10:19 AM, Rick van Rein (OpenFortress) < rick@openfortress.nl> wrote: > Hello Paul Wouters, > > I came across your work on storing public key credentials of users in the > DNS: > * draft-wouters-dane-openpgp-00 > * draft-wouters-dane-otrfp-00 > As I am currently trying to achieve similar, secure end-to-end exchanges > of public key material for secure communication, this is very interesting= . > Thanks for the work! > > When I read them, I found that you made a choice that we deliberately > abandoned as unpractical, so I thought it good to share our thoughts. Th= e > background of our work is http://networkeffectalliance.org/ with which we > aim to get more end user and technical facilities incorporated into hosti= ng > packages. Doing this, we are rather keen on privacy and security, as you > are in your drafts. > > We decided against the sort of options in DNS that you are describing > because we felt that the DNS is not meant for storing individual user > credentials. One reason for this opinion is that DNS is ultimately treat= ed > public data, and no DNS admin will accept responsibility for "leaking" > information through DNS, whereas most users will not want that kind of > treatment with their electronically addressable contact channels. Anothe= r > reason is that DNS management is usually considered too sensitive to upda= te > for end user changes; which is why it is often in the hands of another > (class of) operator. > > We are embarking in another direction, and thought this might also be > useful for you, also because it can be used without RFC work. Instead of > using DNS for user data, we are looking at LDAP (with DANE to secure it)= . > It is a very suitable mechanism for retrieval of end-user descriptive > information, ranging from postalAddress to pgpKey descriptions. It also > has a well-established notion of a Global Directory that is based on > DNS-names derived from dc=3D,dc=3D trailers to distinguishedNames, and SR= V > record lookups of LDAP service under such domains. Given an email addres= s, > the username part can then be sought with (uid=3D=85) filtering, and PGP = keys > and such can be located under that node. I am not aware of any XMPP > profile for LDAP, but that is as straightforward to define as it has been > for OpenPGP, SSH and even SRP. It is probably easier to get such an LDAP > attribute spec standardised as an RFC or even just a XEP than your propos= ed > use of DNS. > > The searchable structured data in LDAP can have privacy issues when used > as a public-facing service when published without restraint; we are > resolving that with a filtering practice (for which we are developing > software) that can filter out considered-private attributes (or objects) > unless their attribute values are explicitly mentioned in a query. So, > searching for (uid=3Drick) under dc=3Dopenfortress,dc=3Dnl would deliver = my > account record with email address and SIP phone number as well as being a > parent for key material, but searching for (uid=3D*) would not deliver th= is > if I configured LDAP to treat uid as too private to publish in that case. > Another reason not to publish LDAP is that it is often used for data abo= ut > local infra; this can be solved by separating in-house and public directo= ry > services. > > If you want to know more about this work, you can visit this site with th= e > work in progress: http://rickywiki.vanrein.org/doku.php?id=3Dglobaldir > > Specifically note how, for OpenPGP, there is a solution that already work= s > with PGP tools -- they will perform that LDAP queries to per-domain LDAP > service. I detailed it on the subpage > http://rickywiki.vanrein.org/doku.php?id=3Dglobaldir-5-openpgp > > > I hope this is helpful! > > > Cheers, > > Rick van Rein > OpenFortress > +31.53.4782239 > rick@openfortress.nl (SMTP, XMPP, SIP) > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ --089e0141a1fc584bc904e34be980 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Sounds like you are proposing this.

http://www.ietf.org/rfc/= rfc4386.txt

For what it is worth, I agree that u= sing the DNS to store per-user data is not a good approach. The DNS adminis= tration model is that it makes assertions about network names and not indiv= idual users. Previous attempts to put end users in the DNS have uniformly m= et with failure.

But that does not mean that LDAP is a useful tool. LDAP= has tons of complexity and none of it does the slightest bit of good.


While writing my RFC tool I thought abo= ut writing a spec for an Internet bibliography service that would convert l= abels [RFC4386] to XML documents describing the reference.

Then after a fairly short amount of work I realized tha= t I could do everything I wanted using HTTP and some simple regular express= ion pattern matching. And the regexp stuff was only necessary because I wan= ted to reuse the existing libraries of references at xml.resource.org.


So if you want to do per client records = my suggestion would be

1) Use HTTP as the query la= nguage transport.

2) Put some form of pointer to t= he service in the DNS.

3) Use DNSSEC to secure the binding


It might well be that (2) is a case where NAPTR would = be a good solution. Or it might not.



On Fri, Jul 26, 2013 at 10:19 AM, Rick v= an Rein (OpenFortress) <rick@openfortress.nl> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Hello Paul Wouters,

I came across your work on storing public key credentials of users in the D= NS:
* draft-wouters-dane-openpgp-00
* draft-wouters-dane-otrfp-00
As I am currently trying to achieve similar, secure end-to-end exchanges of= public key material for secure communication, this is very interesting. = =A0Thanks for the work!

When I read them, I found that you made a choice that we deliberately aband= oned as unpractical, so I thought it good to share our thoughts. =A0The bac= kground of our work is http://networkeffectalliance.org/ with which we aim to get = more end user and technical facilities incorporated into hosting packages. = =A0Doing this, we are rather keen on privacy and security, as you are in yo= ur drafts.

We decided against the sort of options in DNS that you are describing becau= se we felt that the DNS is not meant for storing individual user credential= s. =A0One reason for this opinion is that DNS is ultimately treated public = data, and no DNS admin will accept responsibility for "leaking" i= nformation through DNS, whereas most users will not want that kind of treat= ment with their electronically addressable contact channels. =A0Another rea= son is that DNS management is usually considered too sensitive to update fo= r end user changes; which is why it is often in the hands of another (class= of) operator.

We are embarking in another direction, and thought this might also be usefu= l for you, also because it can be used without RFC work. =A0Instead of =A0u= sing DNS for user data, we are looking at LDAP (with DANE to secure it). = =A0It is a very suitable mechanism for retrieval of end-user descriptive in= formation, ranging from postalAddress to pgpKey descriptions. =A0It also ha= s a well-established notion of a Global Directory that is based on DNS-name= s derived from dc=3D,dc=3D trailers to distinguishedNames, and SRV record l= ookups of LDAP service under such domains. =A0Given an email address, the u= sername part can then be sought with (uid=3D=85) filtering, and PGP keys an= d such can be located under that node. =A0I am not aware of any XMPP profil= e for LDAP, but that is as straightforward to define as it has been for Ope= nPGP, SSH and even SRP. =A0It is probably easier to get such an LDAP attrib= ute spec standardised as an RFC or even just a XEP than your proposed use o= f DNS.

The searchable structured data in LDAP can have privacy issues when used as= a public-facing service when published without restraint; we are resolving= that with a filtering practice (for which we are developing software) that= can filter out considered-private attributes (or objects) unless their att= ribute values are explicitly mentioned in a query. =A0So, searching for (ui= d=3Drick) under dc=3Dopenfortress,dc=3Dnl would deliver my account record w= ith email address and SIP phone number as well as being a parent for key ma= terial, but searching for (uid=3D*) would not deliver this if I configured = LDAP to treat uid as too private to publish in that case. =A0Another reason= not to publish LDAP is that it is often used for data about local infra; t= his can be solved by separating in-house and public directory services.

If you want to know more about this work, you can visit this site with the = work in progress: http://rickywiki.vanrein.org/doku.php?id=3Dglobal= dir

Specifically note how, for OpenPGP, there is a solution that already works = with PGP tools -- they will perform that LDAP queries to per-domain LDAP se= rvice. I detailed it on the subpage http://rickywiki.vanr= ein.org/doku.php?id=3Dglobaldir-5-openpgp


I hope this is helpful!


Cheers,

Rick van Rein
OpenFortress
+31.53.4782239<= br> rick@openfortress.nl =A0 (SMTP,= XMPP, SIP)
_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
Website: http://hallambaker.com/
--089e0141a1fc584bc904e34be980-- From gnu@toad.com Tue Aug 6 18:06: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 B58DC21F9D9C; Tue, 6 Aug 2013 18:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7zhiweaB1+J; Tue, 6 Aug 2013 18:06:34 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8642621F9DAF; Tue, 6 Aug 2013 18:06:34 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id r7716UgN004651; Tue, 6 Aug 2013 18:06:30 -0700 Message-Id: <201308070106.r7716UgN004651@new.toad.com> To: Phillip Hallam-Baker In-reply-to: References: <030F2A8C-1C25-4C91-88FD-C81AF44FA98E@openfortress.nl> Comments: In-reply-to Phillip Hallam-Baker message dated "Tue, 06 Aug 2013 14:51:23 -0400." Date: Tue, 06 Aug 2013 18:06:30 -0700 From: John Gilmore Cc: "Rick van Rein \(OpenFortress\)" , "dane@ietf.org" , openpgp@ietf.org Subject: Re: [dane] Storing public keys in DNS or LDAP, or elsewhere 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, 07 Aug 2013 01:06:39 -0000 > For what it is worth, I agree that using the DNS to store per-user data is > not a good approach. The DNS administration model is that it makes > assertions about network names and not individual users. Previous attempts > to put end users in the DNS have uniformly met with failure. > > But that does not mean that LDAP is a useful tool. LDAP has tons of > complexity and none of it does the slightest bit of good. The classic Internet protocol for providing per-user data is "finger", RFC 742 from 1977. (Note by the way the illustrious users in the "examples" section.) It has been updated a few times, most recently in RFC 1288 from 1991. It is a Draft Standard. Many people put their PGP public key in their .plan file for easy remote access via finger. Finger has two drawbacks for this purpose: It is not authenticated nor encrypted; and it is designed to be human-readable, not machine-readable. But a simple finger-like protocol, authenticated and encrypted via keys anchored in DNSSEC, might not only fill the need to obtain keys, but also offer a secured and machine-readable replacement for the finger protocol. > Sounds like you are proposing this. > http://www.ietf.org/rfc/rfc4386.txt Well, no. That just specifies a DNS RR for finding a server that includes X.509 stuff. It doesn't define a protocol for getting the stuff from that server, nor is it generic to information beyond X.509. >> * draft-wouters-dane-openpgp-00 >> * draft-wouters-dane-otrfp-00 These actually specify how to get authenticated key material from the DNS. (However, they don't encrypt the DNS transaction, so the identity of the user being communicated with is leaked to NSA and any other wiretappers...) John From mcr@sandelman.ca Tue Aug 6 19:49:37 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C80721E80B5; Tue, 6 Aug 2013 19:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyjiAPIryeDx; Tue, 6 Aug 2013 19:49:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id D7B3421E80C1; Tue, 6 Aug 2013 19:49:31 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id CD79820172; Tue, 6 Aug 2013 23:55:58 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id EC85BA904C; Tue, 6 Aug 2013 22:48:01 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D6A49B8EA6; Tue, 6 Aug 2013 22:48:01 -0400 (EDT) From: Michael Richardson To: John Gilmore In-Reply-To: <201308070106.r7716UgN004651@new.toad.com> References: <030F2A8C-1C25-4C91-88FD-C81AF44FA98E@openfortress.nl> <201308070106.r7716UgN004651@new.toad.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: openpgp@ietf.org, "Rick van Rein \(OpenFortress\)" , "dane@ietf.org" Subject: Re: [dane] Storing public keys in DNS or LDAP, or elsewhere 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, 07 Aug 2013 02:49:37 -0000 --=-=-= John Gilmore wrote: >> For what it is worth, I agree that using the DNS to store per-user data is >> not a good approach. The DNS administration model is that it makes >> assertions about network names and not individual users. Previous attempts >> to put end users in the DNS have uniformly met with failure. >> >> But that does not mean that LDAP is a useful tool. LDAP has tons of >> complexity and none of it does the slightest bit of good. > The classic Internet protocol for providing per-user data is "finger", > RFC 742 from 1977. (Note by the way the illustrious users in the > "examples" section.) It has been updated a few times, most recently > in RFC 1288 from 1991. It is a Draft Standard. Many people put their > PGP public key in their .plan file for easy remote access via finger. > Finger has two drawbacks for this purpose: It is not authenticated nor > encrypted; and it is designed to be human-readable, not > machine-readable. But a simple finger-like protocol, authenticated > and encrypted via keys anchored in DNSSEC, might not only fill the > need to obtain keys, but also offer a secured and machine-readable > replacement for the finger protocol. Alas, finger ignores the MX records, and the standard client does not pass the entire command line argument in the query (making multi-tenant hard). This effectively means that one has to run the fingerd on the web server, as many want "example.com" to answer the same as "www.example.com", and HTTP doesn't do SRV lookup either. If finger could be updated to look up a SRV RR to find the finger server, it would be very so much easier to deploy. Given IPv6, putting a unique IP address per hosted domain isn't so terrible, but having % finger user@example.com send "user@example.com" as it's query would help too. I frankly think that having per-user data in DNS is not a horrible thing. It is true that the DNS administrators often will not like this, but as was pointed out in a WG session last week, many them will respond to a request like: "please insert user.example.com IN NS ns1.user.example.com" even when they don't understand: "please delegate user.example.com to ns1.user.example.com" (yes, you can finger me for keys to check this message. John convinced me it the utility 15 years ago.) -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUgG1X4qHRg3pndX9AQJcCAP/aPGikznbKpMgLvTQN/abkoo8jGiu4dAU rLcKyVy9/YlRYZMcg+LrRdeCGJnuIlpmE2j7FIyFdkREXDgk7H9XCedl3iZ++QXz 1VbkxY5Rh9dWE44SLbiy1vZ3xcTXo1CibN9cTsuxRBEz3yHSarHYEFkQ+oKVwbtQ zi3mlfWh+Gc= =5+EL -----END PGP SIGNATURE----- --=-=-=-- From marka@isc.org Tue Aug 6 20:10: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 A526821F9A0C; Tue, 6 Aug 2013 20:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 LDi5HdZrqqSl; Tue, 6 Aug 2013 20:09:58 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id C4F8221F9A1C; Tue, 6 Aug 2013 20:09:54 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id A3271C948E; Wed, 7 Aug 2013 03:09:16 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1375844993; bh=rV3w1l26c7cVuyctCvcvawM3wTvSazWuzeunCvzJqg4=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=ViBkdT3Y0+TpnQIX1FhsfzrJBevkki3G6AP6gsf3u0TVdl9+P/bldI0UmSkSDNwva zjMbqq0bCHeY1z6JOWkDZfrA/qGB31o2Ns+MbqUWfcyUhN9dvNjG2p1AqYB9ZLLIcA /TSSt/D2wMZopL1SwFrq6VrR/+XSVFZVCKmTkPn8= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 7 Aug 2013 03:09:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B226616037C; Wed, 7 Aug 2013 03:13:30 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id FpDWHKe_4u9A; Wed, 7 Aug 2013 03:13:26 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1B80A16037A; Wed, 7 Aug 2013 03:13:26 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id A66A1160082; Wed, 7 Aug 2013 03:13:25 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id A569C3814077; Wed, 7 Aug 2013 13:09:09 +1000 (EST) To: Michael Richardson From: Mark Andrews References: <030F2A8C-1C25-4C91-88FD-C81AF44FA98E@openfortress.nl> <201308070106.r7716UgN004651@new.toad.com> <30532.1375843681@sandelman.ca> In-reply-to: Your message of "Tue, 06 Aug 2013 22:48:01 -0400." <30532.1375843681@sandelman.ca> Date: Wed, 07 Aug 2013 13:09:09 +1000 Message-Id: <20130807030909.A569C3814077@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "Rick van Rein \(OpenFortress\)" , openpgp@ietf.org, "dane@ietf.org" Subject: Re: [dane] Storing public keys in DNS or LDAP, or elsewhere 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, 07 Aug 2013 03:10:04 -0000 > John Gilmore wrote: > >> For what it is worth, I agree that using the DNS to store per-user data is > >> not a good approach. The DNS administration model is that it makes > >> assertions about network names and not individual users. Previous attempts > >> to put end users in the DNS have uniformly met with failure. > >> > >> But that does not mean that LDAP is a useful tool. LDAP has tons of > >> complexity and none of it does the slightest bit of good. > > > The classic Internet protocol for providing per-user data is "finger", > > RFC 742 from 1977. (Note by the way the illustrious users in the > > "examples" section.) It has been updated a few times, most recently > > in RFC 1288 from 1991. It is a Draft Standard. Many people put their > > PGP public key in their .plan file for easy remote access via finger. > > > Finger has two drawbacks for this purpose: It is not authenticated nor > > encrypted; and it is designed to be human-readable, not > > machine-readable. But a simple finger-like protocol, authenticated > > and encrypted via keys anchored in DNSSEC, might not only fill the > > need to obtain keys, but also offer a secured and machine-readable > > replacement for the finger protocol. > > Alas, finger ignores the MX records, and the standard client does not pass > the entire command line argument in the query (making multi-tenant hard). > > This effectively means that one has to run the fingerd on the web server, > as many want "example.com" to answer the same as "www.example.com", and HTTP > doesn't do SRV lookup either. > > If finger could be updated to look up a SRV RR to find the finger server, > it would be very so much easier to deploy. Given IPv6, putting a unique IP > address per hosted domain isn't so terrible, but having > % finger user@example.com > > send "user@example.com" as it's query would help too. > > I frankly think that having per-user data in DNS is not a horrible thing. > It is true that the DNS administrators often will not like this, but as was > pointed out in a WG session last week, many them will respond to a request > like: > "please insert > user.example.com IN NS ns1.user.example.com" > > even when they don't understand: > "please delegate user.example.com to ns1.user.example.com" > > (yes, you can finger me for keys to check this message. John convinced me it > the utility 15 years ago.) > > -- > Michael Richardson , Sandelman Software Works DNS mailbox format for users is just plain wrong. It results in namespace collisions between users and hosts which has all sorts of implications on delegations. Additionally DNS name normalisation is nowhere near similar to the normalisation used for user names in mail servers so even if you addressed the namespace collision there are still major problem. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From rick@openfortress.nl Tue Aug 6 23:31:29 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F1021E8051; Tue, 6 Aug 2013 23:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.354 X-Spam-Level: X-Spam-Status: No, score=-0.354 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R--3UINaY78N; Tue, 6 Aug 2013 23:31:23 -0700 (PDT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5049321F9FBD; Tue, 6 Aug 2013 23:31:16 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id r776V9wB073172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Aug 2013 08:31:10 +0200 (CEST) (envelope-from rick@openfortress.nl) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: "Rick van Rein (OpenFortress)" In-Reply-To: <30532.1375843681@sandelman.ca> Date: Wed, 7 Aug 2013 08:31:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <030F2A8C-1C25-4C91-88FD-C81AF44FA98E@openfortress.nl> <201308070106.r7716UgN004651@new.toad.com> <30532.1375843681@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: openpgp@ietf.org, "dane@ietf.org" Subject: Re: [dane] Storing public keys in DNS or LDAP, or elsewhere 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, 07 Aug 2013 06:31:30 -0000 Hello, >> The classic Internet protocol for providing per-user data is = "finger", >> RFC 742 from 1977. Love it. My first play with redundant/reliable hosting was = "fingerhosting", which achieved 99.9999% uptime due to tripple servers of 99% each :) >> Finger has two drawbacks for this purpose: It is not authenticated = nor >> encrypted; Yes, so it is purely there for public data. For such data, it's = better-positioned user data than DNS. >> and it is designed to be human-readable, not >> machine-readable. That ought to be good for some degree of privacy ;-) but this is why so = many attempts are made to structure data in DNS but why I prefer LDAP = with its large set of predefined techniques and formats -- and it's = openness for DIY specs that won't clash due to the use of ASN1 OIDs. I wouldn't mind seeing http://user@domain/ step into this cavity BTW -- = HTTP must be the only protocol on the planet (well, sort of) that does = not support usernames, and we are using this pattern very, very often = nowadays. > Given IPv6, putting a unique IP > address per hosted domain isn't so terrible, but having > % finger user@example.com This would be an operational impossibility I fear. If people need to = get an IPv6 address per user to be able to run finger, then no admin = will support it. "Just use WebFinger", I can hear them say. WebFinger by the way, is too far up the stack IMHO -- it queries the = .well-known directory on a webserver, fills in a pattern and does a = query. Sounds more like DNS stuff to me, and a good application for = http://user@domain/ -- the other obvious beneficiary being OpenID. This = might call for a SRV record of some kind in the DNS -- or an NAPTR. > (yes, you can finger me for keys to check this message. John convinced = me it > the utility 15 years ago.) Wonderful :) If there were more like you it'd be the = IPv6-added-value-showcase that could help the transport concur the World = ;-) -Rick= From paul@cypherpunks.ca Thu Aug 8 12:45: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 38E1511E820C; Thu, 8 Aug 2013 12:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] 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 BK-lrVSUOY7a; Thu, 8 Aug 2013 12:44:55 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 56A4711E820D; Thu, 8 Aug 2013 12:44:54 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cB0R65FYlz47F; Thu, 8 Aug 2013 15:44:50 -0400 (EDT) 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 UnGSUa1YaXQK; Thu, 8 Aug 2013 15:44:49 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 8 Aug 2013 15:44:48 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id E3F2E80EC9; Thu, 8 Aug 2013 15:44:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D686380E8F; Thu, 8 Aug 2013 15:44:49 -0400 (EDT) Date: Thu, 8 Aug 2013 15:44:49 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: John Gilmore In-Reply-To: <201308070106.r7716UgN004651@new.toad.com> Message-ID: References: <030F2A8C-1C25-4C91-88FD-C81AF44FA98E@openfortress.nl> <201308070106.r7716UgN004651@new.toad.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: openpgp@ietf.org, "Rick van Rein \(OpenFortress\)" , "dane@ietf.org" Subject: Re: [dane] Storing public keys in DNS or LDAP, or elsewhere 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, 08 Aug 2013 19:45:01 -0000 On Tue, 6 Aug 2013, John Gilmore wrote: >>> * draft-wouters-dane-openpgp-00 >>> * draft-wouters-dane-otrfp-00 > > These actually specify how to get authenticated key material from the > DNS. (However, they don't encrypt the DNS transaction, so the > identity of the user being communicated with is leaked to NSA and > any other wiretappers...) I would suggest we address DNS query privacy in a generic way for all DNS, although even if you just encrypt, it might not be enough when the adversary has so many listening points, and the user immediately uses the DNS information for another action (eg an IM message or sending an email) Paul From rick@openfortress.nl Thu Aug 8 12:56: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 630A721F8AA1; Thu, 8 Aug 2013 12:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.429 X-Spam-Level: X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdVW-P4wOm1J; Thu, 8 Aug 2013 12:56:24 -0700 (PDT) Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) by ietfa.amsl.com (Postfix) with ESMTP id A8D9A11E8219; Thu, 8 Aug 2013 12:56:02 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id r78JtmqC075505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Aug 2013 21:55:50 +0200 (CEST) (envelope-from rick@openfortress.nl) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=windows-1252 From: "Rick van Rein (OpenFortress)" In-Reply-To: Date: Thu, 8 Aug 2013 21:55:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <530909EF-59D1-47F7-AA29-47A69F4C37C4@openfortress.nl> References: <030F2A8C-1C25-4C91-88FD-C81AF44FA98E@openfortress.nl> <201308070106.r7716UgN004651@new.toad.com> To: Paul Wouters X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: openpgp@ietf.org, "dane@ietf.org" Subject: Re: [dane] Storing public keys in DNS or LDAP, or elsewhere 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, 08 Aug 2013 19:56:54 -0000 Ah! > I would suggest we address DNS query privacy in a generic way for all = DNS, I feel a proposal towards DNS over TLS [1] coming up ;-) -Rick [1] The hard way, even=85 first negotiating ANON-DH, then doing a secure = renegotiation to obtain the identity of the remote server, and finally = retrieving the data requested.= From ogud@ogud.com Fri Aug 9 07:19:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF3E21F9AA4 for ; Fri, 9 Aug 2013 07:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.065 X-Spam-Level: X-Spam-Status: No, score=-102.065 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NyD61Bv8V8M for ; Fri, 9 Aug 2013 07:19:36 -0700 (PDT) Received: from smtp68.ord1c.emailsrvr.com (smtp68.ord1c.emailsrvr.com [108.166.43.68]) by ietfa.amsl.com (Postfix) with ESMTP id C05A011E80DC for ; Fri, 9 Aug 2013 07:19:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 660C21483D5 for ; Fri, 9 Aug 2013 10:19:26 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id A164E1483E3 for ; Fri, 9 Aug 2013 10:19:25 -0400 (EDT) From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_FA12A285-5F31-4772-99CB-E31DFBC2F7B9" Date: Fri, 9 Aug 2013 10:19:25 -0400 References: <20130809141725.3702.71639.idtracker@ietfa.amsl.com> To: "dane@ietf.org list" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dane] Fwd: New Version Notification for draft-dane-registry-acronym-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 14:19:41 -0000 --Apple-Mail=_FA12A285-5F31-4772-99CB-E31DFBC2F7B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Posted as individual submission.=20 Willing to repost as WG document if chairs allow Olafur Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-dane-registry-acronym-00.txt > Date: August 9, 2013 10:17:25 AM EDT > To: Olafur Gudmundsson >=20 >=20 > A new version of I-D, draft-dane-registry-acronym-00.txt > has been successfully submitted by Olafur Gudmundsson and posted to = the > IETF repository. >=20 > Filename: draft-dane-registry-acronym > Revision: 00 > Title: Harmonizing how applications specify DANE-like = usage > Creation date: 2013-08-09 > Group: Individual Submission > Number of pages: 4 > URL: = http://www.ietf.org/internet-drafts/draft-dane-registry-acronym-00.txt > Status: = http://datatracker.ietf.org/doc/draft-dane-registry-acronym > Htmlized: = http://tools.ietf.org/html/draft-dane-registry-acronym-00 >=20 >=20 > Abstract: > Experience has show that people get confused using the three numeric > fields the TLSA record. This document specifies descriptive = acronyms > for the three numeric fields in the TLSA records. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 --Apple-Mail=_FA12A285-5F31-4772-99CB-E31DFBC2F7B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii = Olafur

Begin forwarded = message:

Subject: New Version Notification for = draft-dane-registry-acronym-00.txt
Date: August 9, 2013 = 10:17:25 AM EDT
To: Olafur Gudmundsson <ogud@ogud.com>


A new version of I-D, draft-dane-registry-acronym-00.txt
has = been successfully submitted by Olafur Gudmundsson and posted to = the
IETF repository.

Filename: = draft-dane-registry-acronym
Revision: 00
Title: = Harmonizing how applications specify DANE-like usage
Creation = date: = 2013-08-09
Group: Individual Submission
Number = of pages: 4
URL: =             http://www.ietf.org/internet-drafts/draft-dane-registry-acronym-00.t= xt
Status: =          http:= //datatracker.ietf.org/doc/draft-dane-registry-acronym
Htmlized: =        http://= tools.ietf.org/html/draft-dane-registry-acronym-00


Abstract= :
  Experience has show that people get confused using the = three numeric
  fields the TLSA record.  This = document specifies descriptive acronyms
  for the three = numeric fields in the TLSA records.




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.

The IETF = Secretariat


= --Apple-Mail=_FA12A285-5F31-4772-99CB-E31DFBC2F7B9-- From benlaurie@gmail.com Fri Aug 9 08:00: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 1E9FF21F99DC; Fri, 9 Aug 2013 08:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 GofO3WCmnQDO; Fri, 9 Aug 2013 08:00:46 -0700 (PDT) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1868D21E80A7; Fri, 9 Aug 2013 07:56:01 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id nd7so2380111qeb.38 for ; Fri, 09 Aug 2013 07:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GAP2OeYJB2B1gK0MUZzpvDPFr9T5EjONvZJwayGr460=; b=dF0ExLxPvgAEH+GaP1zzmHVn7yWo0C1X7s4NRXmIBCwgbSyupZ/PIKTGBeDHtdl4zI bwXZ07sTxsDvseL9bsYFfDYc76Wceu4wNOktLc5rn0k5WMmuIvKCjlL4NyPHi/Rmr4n4 PmX5RKkz1z9qCvFMCCGGqqYRDvaWNB0czUc7G8NFBAdXiBSyAR/9UBxhIclu0trDjruV GGvizhRvoiQ6Cplqhxzn1MX2MPSOfELQeHBtsPXO4yeEEto/erQYl5cIHrcnAzw43WJ1 +g8qw9JlnOqtwwX6yu54cSu0hQNgsDWp8mR0fZYCEXHufPLh2QDJjocJFNkd0hpHr87n t9mw== MIME-Version: 1.0 X-Received: by 10.49.105.36 with SMTP id gj4mr1019881qeb.56.1376060160535; Fri, 09 Aug 2013 07:56:00 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.4.227 with HTTP; Fri, 9 Aug 2013 07:56:00 -0700 (PDT) In-Reply-To: <201308070106.r7716UgN004651@new.toad.com> References: <030F2A8C-1C25-4C91-88FD-C81AF44FA98E@openfortress.nl> <201308070106.r7716UgN004651@new.toad.com> Date: Fri, 9 Aug 2013 15:56:00 +0100 X-Google-Sender-Auth: DffmglOJSPol_xfLy5jIdcQlBIA Message-ID: From: Ben Laurie To: John Gilmore Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 09 Aug 2013 08:05:11 -0700 Cc: openpgp@ietf.org, "Rick van Rein \(OpenFortress\)" , "dane@ietf.org" Subject: Re: [dane] [openpgp] Storing public keys in DNS or LDAP, or elsewhere 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, 09 Aug 2013 15:00:47 -0000 On 7 August 2013 02:06, John Gilmore wrote: >> For what it is worth, I agree that using the DNS to store per-user data is >> not a good approach. The DNS administration model is that it makes >> assertions about network names and not individual users. Previous attempts >> to put end users in the DNS have uniformly met with failure. >> >> But that does not mean that LDAP is a useful tool. LDAP has tons of >> complexity and none of it does the slightest bit of good. > > The classic Internet protocol for providing per-user data is "finger", > RFC 742 from 1977. (Note by the way the illustrious users in the > "examples" section.) It has been updated a few times, most recently > in RFC 1288 from 1991. It is a Draft Standard. Many people put their > PGP public key in their .plan file for easy remote access via finger. > > Finger has two drawbacks for this purpose: It is not authenticated nor > encrypted; and it is designed to be human-readable, not > machine-readable. But a simple finger-like protocol, authenticated > and encrypted via keys anchored in DNSSEC, might not only fill the > need to obtain keys, but also offer a secured and machine-readable > replacement for the finger protocol. https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > >> Sounds like you are proposing this. >> http://www.ietf.org/rfc/rfc4386.txt > > Well, no. That just specifies a DNS RR for finding a server that > includes X.509 stuff. It doesn't define a protocol for getting the > stuff from that server, nor is it generic to information beyond X.509. > >>> * draft-wouters-dane-openpgp-00 >>> * draft-wouters-dane-otrfp-00 > > These actually specify how to get authenticated key material from the > DNS. (However, they don't encrypt the DNS transaction, so the > identity of the user being communicated with is leaked to NSA and > any other wiretappers...) > > John > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From paul@cypherpunks.ca Fri Aug 9 13:00: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 7E6D211E81B1; Fri, 9 Aug 2013 13:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 iBt4nfFXJp+x; Fri, 9 Aug 2013 13:00:00 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0994D21F9C7E; Fri, 9 Aug 2013 12:52:08 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cBcXy6GnGz9bF; Fri, 9 Aug 2013 15:52:02 -0400 (EDT) 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 QCAr6bWPUvYl; Fri, 9 Aug 2013 15:52:01 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Fri, 9 Aug 2013 15:52:01 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 93A1480EC9; Fri, 9 Aug 2013 15:52:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 863E280E8F; Fri, 9 Aug 2013 15:52:02 -0400 (EDT) Date: Fri, 9 Aug 2013 15:52:02 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Ben Laurie In-Reply-To: Message-ID: References: <030F2A8C-1C25-4C91-88FD-C81AF44FA98E@openfortress.nl> <201308070106.r7716UgN004651@new.toad.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "Rick van Rein \(OpenFortress\)" , openpgp@ietf.org, "dane@ietf.org" Subject: Re: [dane] [openpgp] Storing public keys in DNS or LDAP, or elsewhere 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, 09 Aug 2013 20:00:05 -0000 On Fri, 9 Aug 2013, Ben Laurie wrote: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ To get back somewhat to the openpgpkey dns record type.... The CERT record (RFC-4398) has a type for PGP (data is key blob) and iPGP (data is URI pointer) http://tools.ietf.org/html/rfc4398#section-2.1 Perhaps the openpgpkey draft can be generalised and obsolete RFC4398. It would allow storing user PKIX certificates in DNS as well pgp keys (or URI's to these respectively) Paul From i.grok@comcast.net Fri Aug 9 19:15: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 9EC5521F9D50 for ; Fri, 9 Aug 2013 19:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 xuFYW9+EtusX for ; Fri, 9 Aug 2013 19:15:36 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB7B11E80E7 for ; Fri, 9 Aug 2013 19:10:11 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta03.westchester.pa.mail.comcast.net with comcast id AnxL1m0020EZKEL53qAAtx; Sat, 10 Aug 2013 02:10:10 +0000 Received: from odin.ulthar.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by omta01.westchester.pa.mail.comcast.net with comcast id AqA91m0022Ekl483MqAABh; Sat, 10 Aug 2013 02:10:10 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.7/8.14.5) with ESMTP id r7A2A8Of023312 for ; Fri, 9 Aug 2013 22:10:08 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.7/8.14.7/Submit) id r7A2A8x9023311 for dane@ietf.org; Fri, 9 Aug 2013 22:10:08 -0400 Date: Fri, 9 Aug 2013 22:10:08 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20130810021008.GA22978@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20130809141725.3702.71639.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376100610; bh=/SDTQvn4N6zCCqXeavHtsA9D+SGUGKYpe3XlDbw/1hk=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=nBDv7gCCtX8sWr5ZRLQSzSrl2aCmSOcjLFc1xuHbl9CCUVpWcmMl/1WzNHNRGWzFi xOWp1tyzta7GqaF/r4IYiv4FnjeJCJ7Nh4tqBzlP8rG5m5mpZu1NNO9FIM8Rp0C6lj 59s7kc6xvDSaIVfJ9t6xaahTF+Y14MG704uyW8DeL25KgDiHXBrYFNNCHQEKJfRGWe GWSpCP0g4RKObS/GugJoZ1oSk/moLV3tZW+zbELcnZUWUWSfiu7E47xxxM+arJJ6pp LubzPfonYDaCnFbSWDpby2I4pP7FBueDagT9+BnwZQWejapg15cooicCA3KENUSjzc RMc5sKTluq3zw== Subject: Re: [dane] Fwd: New Version Notification for draft-dane-registry-acronym-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 02:15:41 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 09, 2013 at 10:19:25AM -0400, Olafur Gudmundsson wrote: > > Abstract: > > Experience has show that people get confused using the three numeric > > fields the TLSA record. This document specifies descriptive acronyms > > for the three numeric fields in the TLSA records. I do find myself a little puzzled that we feel this is necessary -- nobody is calling for this for DNSKEY, RRSIG, or DS records? Anyway, we aren't generating acronyms for the numbers -- we're identifying enumeration values. In Table 2, "Hash" should be "SPKI", "Full" should probably be "Cert". In Table 3, "NoHash" should be "Full". I'm not convinced that Priv* will see enough use to be worth making an enumeration value for them. If you're going to have them, "PrivHash" needs to be "PrivMatch". Otherwise you'll end up with weird things like: * PKIX-CA Hash NoHash * DANE-EE Full SHA2-256 * DANE-TA Full NoHash instead of: * PKIX-CA SPKI Full * DANE-EE Cert SHA2-256 * DANE-TA Cert Full Other questions not addressed in the draft: * Case sensitive or not? * Probably should show some examples of use? * Can I mix enumerations with the numbers? * What if the enumerations are used out of order? --=20 Scott Schmit --tKW2IUtsqtDRztdT Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIPLwYJKoZIhvcNAQcCoIIPIDCCDxwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DGAwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBiQwggUMoAMCAQICAwbpNjANBgkqhkiG 9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEzMDYyNjE2 MDUyM1oXDTE0MDYyNzEwMTAyNlowQDEbMBkGA1UEAwwSaS5ncm9rQGNvbWNhc3QubmV0MSEw HwYJKoZIhvcNAQkBFhJpLmdyb2tAY29tY2FzdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDAREVv2/t9gYw3iKbjqn5dLvXydoE4kw1yMlTWSPq0nBJWUFKKilxm9Afw IFqSuHW27lr79o0AuietIVKEG1fl0JouU3TdPyCDvV3fDmFy+0m5rMMYjipA+PoLfXNsKwRQ Z9J5XFtPsvS3uRKqU2THtVxtOr3AGlD4jhVpF9k2gbXxKNHQ999xbmTEuZPCaN0L3zL//Y8w hBPDP/w2U7dG1r44z3lY0mCu3jf838PewB8/Yq0P+0RKPncULBlwlbqVYCqdZMKOiMrjqAQs ruQ6HgXUbg4d8MsKTJ/Un/nDfWCh54gAQKyje/97DTz/DTRKV0OzyqiHSGHwkgZQpGSPAgMB AAGjggLYMIIC1DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcD AgYIKwYBBQUHAwQwHQYDVR0OBBYEFK0MFQ/rscPQn7iGRFV8E6IJAJI+MB8GA1UdIwQYMBaA FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB0GA1UdEQQWMBSBEmkuZ3Jva0Bjb21jYXN0Lm5ldDCC AUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3 YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVt ZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUg aW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9i bGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBAEw9 N2rGlwBxaTMJwi/9HFtF58hD9C9/rgeNzMkURfSPplMggJpvg3Do0HfidcFFSPE6gpbVwA8i BUm2DKQpJ9MycNLx8xCyB/mv3w7Ui7OVFobujza7HFzwk+fHSVs9ymzSt/fw3tfHXhxoU4Xw lo5COTMwAh0BNlJQMyMxhKJLsxokn840JDzanR/qmApKx9eRdtPQuYhDjCUY/GYLFfslOkS9 59h7/7FohrOm88XAbjK9kfZ6pZk4yqg65jlPQ8k+4V3xuTAHjZ7X2LLdjx0G8Ld0InnQOE0c yPlvuHEp37gnilDUGdoT9M6WzH+P3TOJut5aythsKEZyjtgEb4AxggKXMIICkwIBATCBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMG6TYwCQYFKw4DAhoFAKCB2DAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA4MTAwMjEwMDha MCMGCSqGSIb3DQEJBDEWBBR5Ne+GkHjk3RB/Z4TFHaFMs5W8OTB5BgkqhkiG9w0BCQ8xbDBq MAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAN BgkqhkiG9w0BAQEFAASCAQCIRaos/Q92DWY6k+MCl9t2nevzUnxgf8kvuvuWaK6VYzGoHpIH SKPHlzDy/Uv69gljLyeAzbhn56foeLCeHDer/2K6/F1aKILIg5UQh0NiL7sF30JRZ2t91bbD WxoQPjNtTBDtUZ3aihnQ0IK9tK4u5ZHsNICm93OTP+FoqxiCEIAcR+EjumtacfwE9Cs9KSsq Qy5UoRU/8OvMzUjt5P+FtZZaA7lW8h3v5KZjihkHCNqDnYDfu/YIGCqZq7lelSNuZPqBrhHj KEg4qrleKF30P1hhLAaDb4dthuo8ULyibSvIgOMuMXBFjeDWhZImb1Xfxi6zn1ICmJH+VQ3q 5fUu --tKW2IUtsqtDRztdT-- From gnu@toad.com Sat Aug 10 12:41: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 7662D11E819B for ; Sat, 10 Aug 2013 12:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59EiZ-Cvzjvr for ; Sat, 10 Aug 2013 12:41:51 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 71E1F11E8198 for ; Sat, 10 Aug 2013 12:34:04 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id r7AJY36a027498 for ; Sat, 10 Aug 2013 12:34:03 -0700 Message-Id: <201308101934.r7AJY36a027498@new.toad.com> To: dane@ietf.org In-reply-to: <20130810021008.GA22978@odin.ulthar.us> References: <20130809141725.3702.71639.idtracker@ietfa.amsl.com> <20130810021008.GA22978@odin.ulthar.us> Comments: In-reply-to Scott Schmit message dated "Fri, 09 Aug 2013 22:10:08 -0400." Date: Sat, 10 Aug 2013 12:34:03 -0700 From: John Gilmore Subject: Re: [dane] Fwd: New Version Notification for draft-dane-registry-acronym-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 19:41:56 -0000 > I do find myself a little puzzled that we feel this is necessary -- > nobody is calling for this for DNSKEY, RRSIG, or DS records? If nobody is adopting your hard-fought standard to secure the Web, perhaps it's time to rearrange the deck chairs, just in case that's why the ship is sinking. John From ogud@ogud.com Sun Aug 11 09:46:52 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1178421F9808 for ; Sun, 11 Aug 2013 09:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 NX4B7030Lx6M for ; Sun, 11 Aug 2013 09:46:48 -0700 (PDT) Received: from smtp92.ord1c.emailsrvr.com (smtp92.ord1c.emailsrvr.com [108.166.43.92]) by ietfa.amsl.com (Postfix) with ESMTP id B673311E815A for ; Sun, 11 Aug 2013 09:40:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 6A69614016C; Sun, 11 Aug 2013 12:40:23 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 3A5B914016A; Sun, 11 Aug 2013 12:40:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olafur Gudmundsson In-Reply-To: <20130810021008.GA22978@odin.ulthar.us> Date: Sun, 11 Aug 2013 12:40:22 -0400 Content-Transfer-Encoding: 7bit Message-Id: <9E2A9289-45F4-41FF-8E66-929B2ECF6316@ogud.com> References: <20130809141725.3702.71639.idtracker@ietfa.amsl.com> <20130810021008.GA22978@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1508) Cc: dane@ietf.org Subject: Re: [dane] Fwd: New Version Notification for draft-dane-registry-acronym-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 16:46:52 -0000 On Aug 9, 2013, at 10:10 PM, Scott Schmit wrote: > On Fri, Aug 09, 2013 at 10:19:25AM -0400, Olafur Gudmundsson wrote: >>> Abstract: >>> Experience has show that people get confused using the three numeric >>> fields the TLSA record. This document specifies descriptive acronyms >>> for the three numeric fields in the TLSA records. > > I do find myself a little puzzled that we feel this is necessary -- > nobody is calling for this for DNSKEY, RRSIG, or DS records? > ] Because the registries had acronym's from day one there. > Anyway, we aren't generating acronyms for the numbers -- we're > identifying enumeration values. > > In Table 2, "Hash" should be "SPKI", "Full" should probably be "Cert". > In Table 3, "NoHash" should be "Full". > > I'm not convinced that Priv* will see enough use to be worth making an > enumeration value for them. If you're going to have them, "PrivHash" > needs to be "PrivMatch". > > Otherwise you'll end up with weird things like: > * PKIX-CA Hash NoHash > * DANE-EE Full SHA2-256 > * DANE-TA Full NoHash > > instead of: > * PKIX-CA SPKI Full > * DANE-EE Cert SHA2-256 > * DANE-TA Cert Full > > Other questions not addressed in the draft: > * Case sensitive or not? > * Probably should show some examples of use? > * Can I mix enumerations with the numbers? > * What if the enumerations are used out of order? > > -- > Scott Schmit > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From benl@google.com Tue Aug 13 08:15: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 C083311E814D for ; Tue, 13 Aug 2013 08:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.223 X-Spam-Level: * X-Spam-Status: No, score=1.223 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 Zrjj305XtccL for ; Tue, 13 Aug 2013 08:15:55 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0335511E8176 for ; Tue, 13 Aug 2013 08:15:54 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id c1so4123238qcz.5 for ; Tue, 13 Aug 2013 08:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KsbcBVyeiFDv02CuCT62sNbwOF4pqriYqB+vVjAvg78=; b=hjgUl2NNzdA9ZNtg6NTendEgr5mFpSHwsMIFt4KQpW3YRc3myss+qby6CXegxYoK2t pms6AYHRWP16CRoDhl9RCZM4cxNxzGfXeL3/eNAzOhT0lHLKTMIA5LCXTK1KxLuKOTOD 4cfEOcrtO3kkmdfOo++Y142fv4u35zOHYrLNN6hZWBe0oVp683K0yh+WVVlZ2qBIVTbN tJss2QIrJea2sE9vkNy9cl7Dzw9bvjlxQccy/Yn1FDnknw4ywLXEuQKMXJrvAOkHNPYy fpVcvoVZ4Tm9fmJAY7NuGPjAQGEYzUvmerS0Rlfmzfvq81MUI8Dr8BhHZLMKpnXy9jnJ eHbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=KsbcBVyeiFDv02CuCT62sNbwOF4pqriYqB+vVjAvg78=; b=pki/YotBi3Xhu5vXY2OM8Jbu6DKOWzHlIxLRQ9hYHP4XOj/+lPWhdHFvF5X9QyxUrs gpTlla6H1v72+Ik0c77C3sINoggaT6p3hfvrEvq1o/xRH9NTstWTu8X5SzF/AJAOGp8K DU4FXHAe1VbRr2QIb2ZOSSZLg5CcTlFabZacEy6HWsbvlkpD5fqxM5wDxou8ccTMrGHQ udcg2i2H/IggOe3vw7DhRfKV+MEt91/8bG/jad2OLdPvU7Tf3o2alrKthvZ2slQbwpmP FaNntPH+zQMtXLxisCax6CPIgsULf0c0/Cx1dGVpkK8ZM4O9wWuuPqflQYYFYXXCX6Jy 2fWg== X-Gm-Message-State: ALoCoQklk0fb3I3qYREzeVt+2GjUJMzwgPN77Jq08S+x0MAr4jYvyKhjQ+HcqIYcsnRsC3lhKX56+L6Of6XcXZ2E8XM2/69nrExpTnHLa0dyivaZwxFEGh2aGvb7nDGUyTcp/7vkz6y03MPmKNjY41DF7oLf8DpMQGcd1MFekmnj8BQN50CAxQPlH3fHfjr20jxM8tPMVkXv MIME-Version: 1.0 X-Received: by 10.49.105.170 with SMTP id gn10mr5215595qeb.20.1376406954386; Tue, 13 Aug 2013 08:15:54 -0700 (PDT) Received: by 10.229.169.196 with HTTP; Tue, 13 Aug 2013 08:15:54 -0700 (PDT) Date: Tue, 13 Aug 2013 11:15:54 -0400 Message-ID: From: Ben Laurie To: "tls@ietf.org" , IETF DANE WG list , "therightkey@ietf.org" , certificate-transparency@googlegroups.com Content-Type: multipart/alternative; boundary=047d7b67845e954dd304e3d5b734 Subject: [dane] Certificate Transparency Hack Day 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, 13 Aug 2013 15:15:55 -0000 --047d7b67845e954dd304e3d5b734 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The Certificate Transparency hack day will take place at Google=92s London offices on Wednesday, the 28th of August, 2013. Please sign up on this form by August 22nd, to let us know you plan to attend. Where & When: The hack day will be at Google=92s offices in Belgrave House, 76 Buckingham Palace Road, London, SW1W 9TQ . Breakfast is at 8:30am, badges will be handed out at Belgrave House reception. The day itself will start with Ben=92s introduction at 9am, ending by 6pm, with a lunch break at around 1:30pm. There=92ll be drinks at a nearby pub afterwards. What to prepare: In order to make the most of the time we have on the day, you=92ll need to = do a little preparation. Please bring your own laptop with either: * A copy of the CT repository- check you have all the necessary dependencies and are able to compile it(instructions here), or * A copy of CT development Linux VMware image (available with instructions here ) Regards, Ben and the Certificate Transparency team at Google --047d7b67845e954dd304e3d5b734 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

The Certificate Transparency hack day will take place at Google=92s London= offices on Wednesday, the 28th of August, 2013.

Please= sign up on this form by A= ugust 22nd, to let us know you plan to attend.


Where & When:

= The hack d= ay will be at Google=92s offices in Belgrave House, 76 Buckingham Pala= ce Road, London, SW1W 9TQ.


Breakfast= is at 8:30am, badges will be handed out at Belgrave House reception.

= The day it= self will start with Ben=92s introduction at 9am, ending by 6pm, with a lun= ch break at around 1:30pm. There=92ll be drinks at a nearby pub afterwards.=


What to prepare:

= In order t= o make the most of the time we have on the day, you=92ll need to do a littl= e preparation.

= Please bri= ng your own laptop with either:

= * A copy o= f the CT repository - check you have all the nece= ssary dependencies and are able to compile it(instructions here), or

= * A copy o= f CT development Linux VMware image (available with instructions here)


Regards,<= /span>

= Ben and th= e Certificate Transparency team at Google


<= /span>
--047d7b67845e954dd304e3d5b734-- From viktor1dane@dukhovni.org Mon Aug 26 11:13: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 03D2011E81F4 for ; Mon, 26 Aug 2013 11:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLkQ9Rdra7dJ for ; Mon, 26 Aug 2013 11:13:39 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 6C71511E81F3 for ; Mon, 26 Aug 2013 11:13:38 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 777AC2AB05B; Mon, 26 Aug 2013 18:13:33 +0000 (UTC) Date: Mon, 26 Aug 2013 18:13:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130826181333.GE29796@mournblade.imrryr.org> References: <39018622-D8A7-4E30-A137-C7BE15DB3A88@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39018622-D8A7-4E30-A137-C7BE15DB3A88@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Postfix Ubuntu packages with DANE support 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, 26 Aug 2013 18:13:44 -0000 On Fri, Aug 02, 2013 at 11:02:28AM +0200, Ond?ej Sur? wrote: > I have created an Ubuntu PPA repository with Postfix 2.11-development snapshot > with DANE support in case you are running Ubuntu and you are too lazy to > compile from the source: I also notice that nic.cz now has working TLSA RRs for SMTP. Thanks. I recall some consensus at IETF Berlin to have ietf.org enable TLS with DANE for SMTP. Is that likely to move forward? In the mean-time, Postfix 2.11-20130825 contains all my DANE patches, so on platforms other than Debian you can build directly from Wietse's source. Debian modifies Postfix to dynamically load table drivers, ... so some additional tweaks are required to build Postfix for Debian or Ubuntu systems. -- Viktor. From warren@kumari.net Mon Aug 26 12:18:43 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F5711E81E0 for ; Mon, 26 Aug 2013 12:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 iZuMjJrVk8Kl for ; Mon, 26 Aug 2013 12:18:28 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF6011E81C8 for ; Mon, 26 Aug 2013 12:18:27 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.89]) by vimes.kumari.net (Postfix) with ESMTPSA id 476511B40CAC; Mon, 26 Aug 2013 15:18:27 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Warren Kumari In-Reply-To: <20130826181333.GE29796@mournblade.imrryr.org> Date: Mon, 26 Aug 2013 15:18:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <39018622-D8A7-4E30-A137-C7BE15DB3A88@nic.cz> <20130826181333.GE29796@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [dane] Postfix Ubuntu packages with DANE support 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, 26 Aug 2013 19:18:43 -0000 On Aug 26, 2013, at 2:13 PM, Viktor Dukhovni = wrote: > On Fri, Aug 02, 2013 at 11:02:28AM +0200, Ond?ej Sur? wrote: >=20 >> I have created an Ubuntu PPA repository with Postfix 2.11-development = snapshot >> with DANE support in case you are running Ubuntu and you are too lazy = to >> compile from the source: >=20 > I also notice that nic.cz now has working TLSA RRs for SMTP. > Thanks. I recall some consensus at IETF Berlin to have ietf.org > enable TLS with DANE for SMTP. Is that likely to move forward? Yes.=20 A few participants suggested that the folk running the IETF = infrastructure monitor for $something when enabling this. AFAIR, = $someone[0] was supposed to provide some things to monitor for=85 We also still have the issue that mail.ietf.org: 250-ietfa.amsl.com 250-PIPELINING 250-SIZE 67108864 250-ETRN 250-AUTH LOGIN PLAIN 250-AUTH=3DLOGIN PLAIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN is missing STARTTLS :-( I have a todo to poke someone about this, but got sidetracked=85 Will do = so now... W >=20 > In the mean-time, Postfix 2.11-20130825 contains all my DANE patches, > so on platforms other than Debian you can build directly from > Wietse's source. Debian modifies Postfix to dynamically load > table drivers, ... so some additional tweaks are required to build > Postfix for Debian or Ubuntu systems. >=20 > --=20 > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 -- "Go on, prove me wrong. Destroy the fabric of the universe. See if I = care." -- Terry Prachett=20 From viktor1dane@dukhovni.org Mon Aug 26 12:33: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 2608511E8212 for ; Mon, 26 Aug 2013 12:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEASNZOurbvj for ; Mon, 26 Aug 2013 12:33:17 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id C010911E820D for ; Mon, 26 Aug 2013 12:33:17 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 195692AAB50; Mon, 26 Aug 2013 19:33:17 +0000 (UTC) Date: Mon, 26 Aug 2013 19:33:17 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130826193316.GG29796@mournblade.imrryr.org> References: <39018622-D8A7-4E30-A137-C7BE15DB3A88@nic.cz> <20130826181333.GE29796@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] Postfix Ubuntu packages with DANE support 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, 26 Aug 2013 19:33:30 -0000 On Mon, Aug 26, 2013 at 03:18:24PM -0400, Warren Kumari wrote: > A few participants suggested that the folk running the IETF > infrastructure monitor for $something when enabling this. AFAIR, > $someone[0] was supposed to provide some things to monitor for? If they implement in stages: - The first step is to configure a suitable self-signed certificate for the SMTP server and enable STARTTLS. Some small fraction of SMTP connections will fail the TLS handshake. Generally the sending system will fallback to plaintext and deliver anyway. One can monitor the logs to identify any systems that consistently fail to establish a TLS connection, and gather statistics on the source IPs and frequency. - The second step is to publish corresponding TLSA RRs (either 3 1 1 for a self-signed cert, or 2 1 1 if they elect instead to go with some issuing CA). At this point one can monitor for any changes in the frequency of failed TLS sessions. It should also be noted that some (for example Postfix) SMTP clients will not abort the TLS handshake when server authentication fails. Rather, the TLS handshake will be completed, and the client will send a "QUIT" to gracefully close the session at the SMTP layer. Therefore, they should also monitor for connections that close gracefully without delivering any mail. -- Viktor. From warren@kumari.net Mon Aug 26 14:39:33 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8839621F9CF8 for ; Mon, 26 Aug 2013 14:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.757 X-Spam-Level: X-Spam-Status: No, score=-101.757 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_00=-2.599, FRT_STRONG2=1.535, 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 cOdD2uMvKTET for ; Mon, 26 Aug 2013 14:39:28 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FEB21F9B26 for ; Mon, 26 Aug 2013 14:39:28 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.89]) by vimes.kumari.net (Postfix) with ESMTPSA id 2F6851B40357; Mon, 26 Aug 2013 17:39:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Warren Kumari In-Reply-To: <20130826193316.GG29796@mournblade.imrryr.org> Date: Mon, 26 Aug 2013 17:39:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <39018622-D8A7-4E30-A137-C7BE15DB3A88@nic.cz> <20130826181333.GE29796@mournblade.imrryr.org> <20130826193316.GG29796@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [dane] Postfix Ubuntu packages with DANE support 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, 26 Aug 2013 21:39:33 -0000 On Aug 26, 2013, at 3:33 PM, Viktor Dukhovni = wrote: > On Mon, Aug 26, 2013 at 03:18:24PM -0400, Warren Kumari wrote: >=20 >> A few participants suggested that the folk running the IETF >> infrastructure monitor for $something when enabling this. AFAIR, >> $someone[0] was supposed to provide some things to monitor for? >=20 > If they implement in stages: >=20 > - The first step is to configure a suitable self-signed certificate > for the SMTP server and enable STARTTLS. =20 I received a reply from the AMS folk (who, as always, are friendly and = helpful) Part of the delay[0] is that the IETF server infrastructure is in the = process of being upgraded. New machines are being deployed, and then there will be some config / = tuning / testing. Hopefully the new stuff will be ready sometime = mid-September, and then we can continue. > Some small fraction > of SMTP connections will fail the TLS handshake. Generally the > sending system will fallback to plaintext and deliver anyway. > One can monitor the logs to identify any systems that consistently > fail to establish a TLS connection, and gather statistics on the > source IPs and frequency. >=20 > - The second step is to publish corresponding TLSA RRs (either > 3 1 1 for a self-signed cert, or 2 1 1 if they elect instead to go > with some issuing CA). At this point one can monitor for any = changes > in the frequency of failed TLS sessions. >=20 >=20 > It should also be noted that some (for example Postfix) SMTP clients > will not abort the TLS handshake when server authentication fails. > Rather, the TLS handshake will be completed, and the client will > send a "QUIT" to gracefully close the session at the SMTP layer. > Therefore, they should also monitor for connections that close > gracefully without delivering any mail. Cool. W [0]: Yeah, it's a tiny bit -- the huge majority is me getting = sidetracked and not, you know, actually asking them till now :-) >=20 > --=20 > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 -- There were such things as dwarf gods. Dwarfs were not a naturally = religious species, but in a world where pit props could crack without = warning and pockets of fire damp could suddenly explode they'd seen the = need for gods as the sort of supernatural equivalent of a hard hat. = Besides, when you hit your thumb with an eight-pound hammer it's nice to = be able to blaspheme. It takes a very special and straong-minded kind of = atheist to jump up and down with their hand clasped under their other = armpit and shout, "Oh, random-fluctuations-in-the-space-time-continuum!" = or "Aaargh, primitive-and-outmoded-concept on a crutch!" -- Terry Pratchett From sklist@kitterman.com Mon Aug 26 18:26: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 9A79F11E822D for ; Mon, 26 Aug 2013 18:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXHXhAOhDHeK for ; Mon, 26 Aug 2013 18:26:51 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 740D611E8126 for ; Mon, 26 Aug 2013 18:26:50 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9FD7A20E40F6; Mon, 26 Aug 2013 21:26:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377566807; bh=N8FpfVu0Bc2RV06004fDHYQwY8pZpEZrHbaYHv4EeP0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jbxw5s8+pQdf4mheGlIgdmq8a/JN40+L1MQni2LLGiQpX9FVVSUPKU4AUaiukC9o7 jySspm6h3R5e/R1YJ9Fe3hY+KfBZYwqqhvlcWxSz/PyUZZDxyjlg0mjTAN7Tjz2HMJ TqLlo4GbK75w0pvI250XgMEPoxer18RDQIGro7GI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7EB5020E4043; Mon, 26 Aug 2013 21:26:47 -0400 (EDT) From: Scott Kitterman To: dane@ietf.org Date: Mon, 26 Aug 2013 21:26:46 -0400 Message-ID: <4401281.kQr7aVqxRt@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <20130826181333.GE29796@mournblade.imrryr.org> References: <39018622-D8A7-4E30-A137-C7BE15DB3A88@nic.cz> <20130826181333.GE29796@mournblade.imrryr.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dane] Postfix Ubuntu packages with DANE support 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, 27 Aug 2013 01:26:55 -0000 On Monday, August 26, 2013 18:13:33 Viktor Dukhovni wrote: > On Fri, Aug 02, 2013 at 11:02:28AM +0200, Ond?ej Sur? wrote: > > I have created an Ubuntu PPA repository with Postfix 2.11-development > > snapshot with DANE support in case you are running Ubuntu and you are too > > lazy to > > compile from the source: > I also notice that nic.cz now has working TLSA RRs for SMTP. > Thanks. I recall some consensus at IETF Berlin to have ietf.org > enable TLS with DANE for SMTP. Is that likely to move forward? > > In the mean-time, Postfix 2.11-20130825 contains all my DANE patches, > so on platforms other than Debian you can build directly from > Wietse's source. Debian modifies Postfix to dynamically load > table drivers, ... so some additional tweaks are required to build > Postfix for Debian or Ubuntu systems. We should have a current snapshot in Debian experimental built with the Debian modifications in the next day or two. Scott K From sklist@kitterman.com Sat Aug 31 09:59:49 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 4DD3321E80B0 for ; Sat, 31 Aug 2013 09:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbtVTuELHaMd for ; Sat, 31 Aug 2013 09:59:45 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 656D521E80A7 for ; Sat, 31 Aug 2013 09:59:42 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 24CCC20E40FD; Sat, 31 Aug 2013 12:59:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377968379; bh=AlPCQkZJrl3ZIrIF11lQIRrIHzO0Eb4Nx/7fPpUxLqY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Xa9wa4cmRlLTHkzxNNF+62g52HeK6xY1Lashg+1OPxQqsMf9F8yUU55a1YrReLvld dM3PhiX7AFNR4pIlqoZzkTo1gthpbyVaH7H/oJHIH13w5nFTqvMyd+0tw7LaOC6oQy zBdsMHiqyChD70AlW/PCgRAEhgrwkAKWmKli9CdQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0623920E40C8; Sat, 31 Aug 2013 12:59:38 -0400 (EDT) From: Scott Kitterman To: dane@ietf.org Date: Sat, 31 Aug 2013 12:59:38 -0400 Message-ID: <1620529.r24WqBgGtx@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <4401281.kQr7aVqxRt@scott-latitude-e6320> References: <39018622-D8A7-4E30-A137-C7BE15DB3A88@nic.cz> <20130826181333.GE29796@mournblade.imrryr.org> <4401281.kQr7aVqxRt@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dane] Postfix Ubuntu packages with DANE support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 16:59:49 -0000 On Monday, August 26, 2013 21:26:46 Scott Kitterman wrote: > On Monday, August 26, 2013 18:13:33 Viktor Dukhovni wrote: > > On Fri, Aug 02, 2013 at 11:02:28AM +0200, Ond?ej Sur? wrote: > > > I have created an Ubuntu PPA repository with Postfix 2.11-development > > > snapshot with DANE support in case you are running Ubuntu and you are > > > too > > > lazy to > > > > > compile from the source: > > I also notice that nic.cz now has working TLSA RRs for SMTP. > > Thanks. I recall some consensus at IETF Berlin to have ietf.org > > enable TLS with DANE for SMTP. Is that likely to move forward? > > > > In the mean-time, Postfix 2.11-20130825 contains all my DANE patches, > > so on platforms other than Debian you can build directly from > > Wietse's source. Debian modifies Postfix to dynamically load > > table drivers, ... so some additional tweaks are required to build > > Postfix for Debian or Ubuntu systems. > > We should have a current snapshot in Debian experimental built with the > Debian modifications in the next day or two. It took slightly longer, but this is now done as well. Scott K
Value 
Full = certificate[RFC6698]
1SubjectPublicKeyInfo[RFC6698]