From nobody Mon Jan 4 07:22:23 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB78F1A896C for ; Mon, 4 Jan 2016 07:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-mnjxLKDJVW for ; Mon, 4 Jan 2016 07:22:20 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0143.outbound.protection.outlook.com [207.46.100.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810FF1A8987 for ; Mon, 4 Jan 2016 07:22:20 -0800 (PST) Received: from CY1PR09MB0645.namprd09.prod.outlook.com (10.161.172.155) by CY1PR09MB0635.namprd09.prod.outlook.com (10.160.151.22) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 4 Jan 2016 15:22:20 +0000 Received: from CY1PR09MB0647.namprd09.prod.outlook.com (10.161.172.17) by CY1PR09MB0645.namprd09.prod.outlook.com (10.161.172.155) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 4 Jan 2016 15:22:19 +0000 Received: from CY1PR09MB0647.namprd09.prod.outlook.com ([10.161.172.17]) by CY1PR09MB0647.namprd09.prod.outlook.com ([10.161.172.17]) with mapi id 15.01.0361.006; Mon, 4 Jan 2016 15:22:19 +0000 From: "Garfinkel, Simson L." To: "dane@ietf.org" Thread-Topic: SMIMEA test vectors Thread-Index: AQHRRwOzaM165Rl/gE+iisEVBB2OQg== Date: Mon, 4 Jan 2016 15:22:19 +0000 Message-ID: <6AF3B656-EF46-4E73-8B47-66AF837242F8@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) authentication-results: spf=none (sender IP is ) smtp.mailfrom=simson.garfinkel@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.222.235] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0645; 5:/zFkElWoywyFxKfFnmQEI00B4MYVEKtYnqZjSy/Pk6AkMMM7NShJsuvbKfsTiwMqzWdET1llAdUw9osRFZYumVTLBjBrNCsKMCaTB/XajXvpL3m+1vbbMrD2GULGgW7ET7/8uFpE4kAl8XaVobIImQ==; 24:KkDYhoL/dOWwxjbI1awt6ve6bvle6e3wu4mFHPKttjc6p41/2kyX2xV7AuZ7JPOW0oN8mdaBansxGV99EjOlqD3YDSloCYMY8AE7XSwUdcU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR09MB0645; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0645; x-forefront-prvs: 08118EFC2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(5004730100002)(450100001)(33656002)(2351001)(36756003)(105586002)(189998001)(83716003)(2900100001)(50986999)(5002640100001)(50226001)(77096005)(110136002)(229853001)(86362001)(106116001)(97736004)(107886002)(99286002)(106356001)(5001960100002)(101416001)(586003)(10400500002)(2501003)(82746002)(57306001)(6116002)(66066001)(558084003)(40100003)(1730700002)(87936001)(1220700001)(11100500001)(102836003)(92566002)(1096002)(122556002)(5008740100001)(3846002)(81156007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0645; H:CY1PR09MB0647.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <28C946C69E6EC94C9484706712A3D2D0@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2016 15:22:19.2060 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0645 X-Microsoft-Exchange-Diagnostics: 1; CY1PR09MB0635; 2:NIULgjIAz3pKTer5cR7aPK1SbFdAxnX8EVzN1lreJiAD37IEVFs9DKrCvl0QMi/i9Zgl5wNcwN4oWps/Lcn1I2CeEXJQKtKnsuR7Rk18m0yG4z918iOOjVq+kFJ5onANnh2ew9NaQ8vVxKR9lbcZbg==; 23:po2n/RkoKRsCZI2glzRSrGhDiLxp/poWGR9u1gAm1UcTxuJpGsottXvSQmIZN+4HJcc9OROjleeaU4IRG4cKiK0FU6YdEoJ4VGpNTg7+TOUtgajqApgSkBgbcuy3AoF0whNs4AnOwgNsDj7EVxxbuHM0Rr2vR5Emj4B8F5FtHTNpBZYUyAeVVkIh+jNhYDl5 X-OriginatorOrg: nist.gov Archived-At: Subject: [dane] SMIMEA test vectors X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 15:22:22 -0000 R3JlZXRpbmdzLA0KDQpBcmUgdGhlcmUgYW55IHB1YmxpYyBTTUlNRUEgdGVzdCB2ZWN0b3JzPyAg SeKAmW0gbG9va2luZyBmb3IgREFORSBTTUlNRUEgcmVjb3JkcyB0aGF0IEkgY2FuIHVzZSB0byBn ZXQgYW4gUy9NSU1FIGNlcnRpZmljYXRlLCBzZW5kIGFuZCBlbWFpbCBtZXNzYWdlIHRoYXTigJlz IChvcHRpb25hbGx5KSBlbmNyeXB0ZWQsIGFuZCBnZXQgYSByZXNwb25zZSB0aGF04oCZcyBkaWdp dGFsbHkgc2lnbmVkLg0KDQpSZWdhcmRzLA0KDQpTaW1zb24NCg0K From nobody Mon Jan 4 13:13:25 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE431ABD38 for ; Mon, 4 Jan 2016 13:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-38iUYRtc4K for ; Mon, 4 Jan 2016 13:13:22 -0800 (PST) Received: from mail-oi0-x264.google.com (mail-oi0-x264.google.com [IPv6:2607:f8b0:4003:c06::264]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F511ABD37 for ; Mon, 4 Jan 2016 13:13:22 -0800 (PST) Received: by mail-oi0-x264.google.com with SMTP id l9so35691977oia.1 for ; Mon, 04 Jan 2016 13:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:content-id:content-transfer-encoding:mime-version; bh=LLxyyg3Ewn37RYRhrfbjHVpsNbdgI7WY64GyI8iOXXc=; b=zBInHjLo61PDnhy2VYvby9LGuehVpsurr38pAll42EuzKoMVH/lhZde+ULv+BL1S2C ApwfZEzD1qHgxhlqIV6fUlCOgkTF2ZnDmuSvJcoAyzwSmRuuClBUwVBD6LXTrPnPmSPe qqMLizF9VBb+4qF8jXAVBxvDgXrGqbY4DRLP92Oq0sOsL8rmt5JuJzn1g+CmtBqlVeQM uQtPcSWLoXaB7760yytB/q4CPyP+a4WOP+Qw/u5R5BK1Kb9evl6M9XTg/hkK76K0wKRI qY6xMi0zddb0CH4gS3D7GSpb4aEG28jPm/hPz/c/7YVRtYA1cuHRK1sY8z2nhLPwJNFs NCzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:content-id:content-transfer-encoding :mime-version; bh=LLxyyg3Ewn37RYRhrfbjHVpsNbdgI7WY64GyI8iOXXc=; b=BaZDhCb8X4rTIYkJo1C+D6alK2pFEWYNcTv1lpc6SD3+qL7CjVgCpUB6xpqoZEb4K9 0zebOPEvaJ8ulyQCU/GV3GNh9SF0OYN1ZwJBgu5i+zEJPHS/y7mPXf1e5nWCPrOcenVj PdfO0PhFiLXqcp0yJhpZDkOZu1PtOFIS9FykDrK5XEvFAWhBHFTsEWQim074poQRP6ts Hgo6dvpBB/qisK7Q4GV9e0hVlwlZJN5Ysm6HG3aAhfGcje4MOYiPsSkwoU89XCAw/jMD nC+b8ZFRdL+YTn/RJbbhD1a8rgCfGpCZ8RUP+b3IztDs1GDUfhK4K/GVmWDNY8cl/qJs wA1A== X-Gm-Message-State: ALoCoQkvbsgkILoRvhE8eMgALqze8VE9f3eTUySWxUlRGipGlQIUAKyJ72oItbYFUQgnNTFGwOHZ+ZG4KJiOKXhTPezYHeW1T3s1M2YQqY69ztjWfKehds4= X-Received: by 10.55.214.150 with SMTP id p22mr29827769qkl.8.1451942001995; Mon, 04 Jan 2016 13:13:21 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id p25sm637434qkl.13.2016.01.04.13.13.21 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 04 Jan 2016 13:13:21 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u04LDL7d031109 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Jan 2016 16:13:21 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 4 Jan 2016 16:13:21 -0500 From: "Osterweil, Eric" To: "Garfinkel, Simson L." Thread-Topic: [dane] SMIMEA test vectors Thread-Index: AQHRRwOzaM165Rl/gE+iisEVBB2OQp7sL0KA Date: Mon, 4 Jan 2016 21:13:20 +0000 Message-ID: <68B4DB21-D91A-4CB5-87A0-ED47B5528BEF@verisign.com> References: <6AF3B656-EF46-4E73-8B47-66AF837242F8@nist.gov> In-Reply-To: <6AF3B656-EF46-4E73-8B47-66AF837242F8@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] SMIMEA test vectors X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 21:13:24 -0000 DQo+IE9uIEphbiA0LCAyMDE2LCBhdCAxMDoyMiBBTSwgR2FyZmlua2VsLCBTaW1zb24gTC4gPHNp bXNvbi5nYXJmaW5rZWxAbmlzdC5nb3Y+IHdyb3RlOg0KPiANCj4gR3JlZXRpbmdzLA0KPiANCj4g QXJlIHRoZXJlIGFueSBwdWJsaWMgU01JTUVBIHRlc3QgdmVjdG9ycz8gIEnigJltIGxvb2tpbmcg Zm9yIERBTkUgU01JTUVBIHJlY29yZHMgdGhhdCBJIGNhbiB1c2UgdG8gZ2V0IGFuIFMvTUlNRSBj ZXJ0aWZpY2F0ZSwgc2VuZCBhbmQgZW1haWwgbWVzc2FnZSB0aGF04oCZcyAob3B0aW9uYWxseSkg ZW5jcnlwdGVkLCBhbmQgZ2V0IGEgcmVzcG9uc2UgdGhhdOKAmXMgZGlnaXRhbGx5IHNpZ25lZC4N Cg0KSGV5IFNpbXNvbiwNCg0KVGhlcmUgYXJlIGxpYnNtYXVnIGFuZCBpdHMgYXNzb2NpYXRlZCBU aHVuZGVyYmlyZCBQbHVnaW46DQoJaHR0cHM6Ly9naXRodWIuY29tL3ZlcmlzaWduL3NtYXVnDQoJ aHR0cHM6Ly9naXRodWIuY29tL3ZlcmlzaWduL3NtYXVnLXRiaXJkLXBsdWdpbg0KDQpUaGUgbGli cmFyeSBzaG91bGQgZWFzaWx5IGJlIHVzZWFibGUgdG8gaW1wbGVtZW50IGEgdGVzdCBoYXJuZXNz Lg0KDQpFcmlj From nobody Mon Jan 4 13:58:39 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213B11A033B for ; Mon, 4 Jan 2016 13:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9NoHAd6n3Xz for ; Mon, 4 Jan 2016 13:58:34 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:789]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3791A0338 for ; Mon, 4 Jan 2016 13:58:34 -0800 (PST) Received: from CY1PR09MB0647.namprd09.prod.outlook.com (10.161.172.17) by CY1PR09MB0648.namprd09.prod.outlook.com (10.161.172.18) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 4 Jan 2016 21:58:14 +0000 Received: from CY1PR09MB0647.namprd09.prod.outlook.com ([10.161.172.17]) by CY1PR09MB0647.namprd09.prod.outlook.com ([10.161.172.17]) with mapi id 15.01.0361.006; Mon, 4 Jan 2016 21:58:14 +0000 From: "Garfinkel, Simson L." To: "Osterweil, Eric" Thread-Topic: [dane] SMIMEA test vectors Thread-Index: AQHRRwOzxjngS5PjBE2ixBMRGV8Xfp7r23EAgAAMhoA= Date: Mon, 4 Jan 2016 21:58:14 +0000 Message-ID: <1DD8EAF2-9BF6-4B0C-B511-53B4523C8AD1@nist.gov> References: <6AF3B656-EF46-4E73-8B47-66AF837242F8@nist.gov> <68B4DB21-D91A-4CB5-87A0-ED47B5528BEF@verisign.com> In-Reply-To: <68B4DB21-D91A-4CB5-87A0-ED47B5528BEF@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2104) authentication-results: spf=none (sender IP is ) smtp.mailfrom=simson.garfinkel@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.84.113] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0648; 5:HuL2zxs5iW/OAw036I3ZbaedCPw+4FkjynAMYX3H2EQzwFGjkJtr7Ro4/Tu+IT2e3jlbb9Y2RlFKnXrY4WQxj+AQRZdBPT8yvKfJkyJvtDd2SA3LLNN680DyRDiCGSOi5t1uq/vYE5fugMIC6VrAXA==; 24:ABatow0vHjLTo93QQPNOs52YqQmX4dTBvy4XYvdkVhL/+bg2Oc3DH3DbxoFJLVyefLoVi3VzQ6G7powyCzA36Hfma41payYzqVXVhxL7xx0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0648; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:CY1PR09MB0648; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0648; x-forefront-prvs: 08118EFC2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(189002)(199003)(52604005)(101416001)(66066001)(11100500001)(50986999)(102836003)(105586002)(33656002)(15975445007)(106356001)(99286002)(2900100001)(50226001)(92566002)(5002640100001)(40100003)(5004730100002)(77096005)(2950100001)(122556002)(3846002)(36756003)(57306001)(97736004)(76176999)(110136002)(586003)(19580405001)(10400500002)(1220700001)(81156007)(5001960100002)(1096002)(82746002)(19580395003)(4326007)(106116001)(87936001)(6116002)(83716003)(189998001)(86362001)(5008740100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0648; H:CY1PR09MB0647.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2016 21:58:14.0036 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0648 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] SMIMEA test vectors X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 21:58:37 -0000 SGkgRXJpYywNCg0KVGhhbmtzIGZvciBwb2ludGluZyBtZSBhdCB0aGlzLiBJ4oCZbSBhY3R1YWxs eSB3cml0aW5nIGEgc2Vjb25kIFNNSU1FQSBpbXBsZW1lbnRhdGlvbiB0aGF0IGlzIHNwZWNpZmlj YWxseSBjcmVhdGVkIHRvIGJlIGEgdGVzdCBoYXJuZXNzLCBzbyBJ4oCZbSBsb29raW5nIGFjdHVh bGx5IGxvb2tpbmcgZm9yIHRlc3QgdmVjdG9ycyBpbiB0aGUgcHVibGljIEROUywgcmF0aGVyIHRo YW4gYSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24uICBBcmUgdGhlcmUgU01JTUVBIGFubm91bmNl bWVudHMgZm9yIGFueSBWZXJpU2lnbiBlbWFpbCBhZGRyZXNzZXM/DQoNCldoaWxlIEkgaGF2ZSB5 b3VyIGF0dGVudGlvbiDigJQgd2hpY2ggYXJlIHRoZSBTTUlNRUEga2V5IHVzYWdlcyB0aGF0IG1h a2Ugc2Vuc2U/ICBTZXZlcmFsIG9mIHRoZW0gc2VlbSBub25zZW5zaWNhbC4gIEZvciBleGFtcGxl LCBob3cgd291bGQgYSBtYXRjaGluZyB0eXBlIG9mIDEgYmUgdXNlZD8gIERvIHlvdSBhbnRpY2lw YXRlIHRoYXQgYW55b25lIHdpbGwgdXNlIGEgc2VsZWN0b3Igb2YgMT8NCg0KU2ltc29uDQoNCj4g T24gSmFuIDQsIDIwMTYsIGF0IDQ6MTMgUE0sIE9zdGVyd2VpbCwgRXJpYyA8ZW9zdGVyd2VpbEB2 ZXJpc2lnbi5jb20+IHdyb3RlOg0KPiANCj4gDQo+PiBPbiBKYW4gNCwgMjAxNiwgYXQgMTA6MjIg QU0sIEdhcmZpbmtlbCwgU2ltc29uIEwuIDxzaW1zb24uZ2FyZmlua2VsQG5pc3QuZ292PiB3cm90 ZToNCj4+IA0KPj4gR3JlZXRpbmdzLA0KPj4gDQo+PiBBcmUgdGhlcmUgYW55IHB1YmxpYyBTTUlN RUEgdGVzdCB2ZWN0b3JzPyAgSeKAmW0gbG9va2luZyBmb3IgREFORSBTTUlNRUEgcmVjb3JkcyB0 aGF0IEkgY2FuIHVzZSB0byBnZXQgYW4gUy9NSU1FIGNlcnRpZmljYXRlLCBzZW5kIGFuZCBlbWFp bCBtZXNzYWdlIHRoYXTigJlzIChvcHRpb25hbGx5KSBlbmNyeXB0ZWQsIGFuZCBnZXQgYSByZXNw b25zZSB0aGF04oCZcyBkaWdpdGFsbHkgc2lnbmVkLg0KPiANCj4gSGV5IFNpbXNvbiwNCj4gDQo+ IFRoZXJlIGFyZSBsaWJzbWF1ZyBhbmQgaXRzIGFzc29jaWF0ZWQgVGh1bmRlcmJpcmQgUGx1Z2lu Og0KPiAJaHR0cHM6Ly9naXRodWIuY29tL3ZlcmlzaWduL3NtYXVnDQo+IAlodHRwczovL2dpdGh1 Yi5jb20vdmVyaXNpZ24vc21hdWctdGJpcmQtcGx1Z2luDQo+IA0KPiBUaGUgbGlicmFyeSBzaG91 bGQgZWFzaWx5IGJlIHVzZWFibGUgdG8gaW1wbGVtZW50IGEgdGVzdCBoYXJuZXNzLg0KPiANCj4g RXJpYw0KDQo= From nobody Wed Jan 6 04:07:30 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFFF1ACF08 for ; Wed, 6 Jan 2016 04:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiy7iyk-GBce for ; Wed, 6 Jan 2016 04:07:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B44431ACEFC for ; Wed, 6 Jan 2016 04:07:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCO37772; Wed, 06 Jan 2016 12:07:25 +0000 (GMT) Received: from LHREML701-CAH.china.huawei.com (10.201.5.93) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Jan 2016 12:07:24 +0000 Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml701-cah.china.huawei.com ([10.201.5.93]) with mapi id 14.03.0235.001; Wed, 6 Jan 2016 12:07:20 +0000 From: Hosnieh Rafiee To: "dane@ietf.org" Thread-Topic: any statistics of deployment available? Thread-Index: AdFIeslBxynRdYetRzmHZNYubTMahg== Date: Wed, 6 Jan 2016 12:07:20 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.218.212] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.568D037D.0197, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6c14caa933a56707144ed897e8c29b89 Archived-At: Subject: [dane] any statistics of deployment available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 12:07:30 -0000 Hi, Is there any statistics or a site that I can find regarding the deployment = of DANE over the internet? I would appreciate it if you send me such info. Thanks, Best, Hosnieh=20 ------------------ Dr. Hosnieh Rafiee Senior Security Researcher=20 Security Compentence Center=20 From nobody Wed Jan 6 04:34:19 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514BC1B2A52 for ; Wed, 6 Jan 2016 04:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od28y0gHsU5U for ; Wed, 6 Jan 2016 04:34:08 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0632.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8DD1B2A16 for ; Wed, 6 Jan 2016 04:34:08 -0800 (PST) Received: from CY1PR0601MB1657.namprd06.prod.outlook.com (10.163.232.19) by CY1PR0601MB1659.namprd06.prod.outlook.com (10.163.232.21) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 6 Jan 2016 12:33:49 +0000 Received: from CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) by CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) with mapi id 15.01.0361.006; Wed, 6 Jan 2016 12:33:49 +0000 From: Dan York To: Hosnieh Rafiee Thread-Topic: [dane] any statistics of deployment available? Thread-Index: AdFIeslBxynRdYetRzmHZNYubTMahgAA7MYA Date: Wed, 6 Jan 2016 12:33:48 +0000 Message-ID: <6463EBE2-E815-4B04-BD38-41CCDEE831E2@isoc.org> References: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=york@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [74.69.229.215] x-microsoft-exchange-diagnostics: 1; CY1PR0601MB1659; 5:15yySFZzVNwGuYHT5J/L3cSPmPMel4zAreAQyI3ttx8WHSQHVVELp0BqC2NhhI1JGYXSv6Yzddn66WCdvlFO5VAbsdNVIyDgwY1vbvG25N+qQz5r7W7Xy+tomb358/YrkJ0dmcS763U/8wT2mN9YCg==; 24:vgGcGVSDKgKJas6QnEpAX21jBmIvi+FDgyjMFZ+XhgnvPELOjLUgiW5SR5AXfcE4O0xbDBQaXMzhYgMaD5VjITx/0K+p3rYMAN3l2wKQ6ic= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1659; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(51492898944892); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:CY1PR0601MB1659; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1659; x-forefront-prvs: 0813C68E65 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(199003)(377454003)(189002)(189998001)(110136002)(5001960100002)(83716003)(87936001)(10400500002)(54356999)(76176999)(50986999)(101416001)(33656002)(82746002)(86362001)(16236675004)(15395725005)(19617315012)(19580405001)(19580395003)(11100500001)(16799955002)(97736004)(81156007)(5004730100002)(2950100001)(2900100001)(15975445007)(77096005)(36756003)(1220700001)(5008740100001)(586003)(1096002)(6116002)(102836003)(3846002)(4326007)(5002640100001)(92566002)(66066001)(106356001)(122556002)(40100003)(105586002)(99286002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1659; H:CY1PR0601MB1657.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_6463EBE2E8154B04BD3841CCDEE831E2isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2016 12:33:48.8766 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1659 Archived-At: Cc: IETF DANE Mailinglist Subject: Re: [dane] any statistics of deployment available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 12:34:16 -0000 --_000_6463EBE2E8154B04BD3841CCDEE831E2isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hosnieh, On Jan 6, 2016, at 7:07 AM, Hosnieh Rafiee > wrote: Is there any statistics or a site that I can find regarding the deployment = of DANE over the internet? We have a list of sites providing DNSSEC statistics at: http://www.internetsociety.org/deploy360/dnssec/statistics/ but as I look at that I realized that we haven't listed any sites with DANE= statistics. One that I know of is: https://xmpp.net/reports.php#dnssecdane that lists the number of XMPP (Jabber) servers with DANE records. It would be great if we had more statistics on DANE deployment. If anyone = else has such a site out there please let me know and I'll be glad to add i= t to the Deploy360 list. Dan P.S. We also have the list of DANE test sites at: http://www.internetsociety.org/deploy360/resources/dane-test-sites/ but there aren't statistics associated with any of those sites that I can s= ee. -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/ --_000_6463EBE2E8154B04BD3841CCDEE831E2isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hosnieh,

On Jan 6, 2016, at 7:07 AM, Hosnieh Rafiee <hosnieh.rafiee@huawei.com&g= t; wrote:

Is there any statistics or a site that I can find regarding= the deployment of DANE over the internet?

We have a list of sites providing DNSSEC statistics at:

http://www.internetsociety.org/deploy360/dnssec/sta= tistics/

but as I look at that I realized that we haven't listed any= sites with DANE statistics.  One that I know of is:

https://xmpp.net/reports.php#dnssecdane

that lists the number of XMPP (Jabber) servers with DANE re= cords.  

It would be great if we had more statistics on DANE deploym= ent.  If anyone else has such a site out there please let me know and = I'll be glad to add it to the Deploy360 list.

Dan

P.S. We also have the list of DANE test sites at: 

http://www.internetsociety.org/deploy360/re= sources/dane-test-sites/

but there aren't statistics associated with any of those si= tes that I can see.
--
Dan York
Senior Content Strategist, Int= ernet Society
york@isoc.org   +1-802-735-1624
Jabber: york@jabber.isoc.org 
Skype: danyork   http://twitter.com/danyork

http://www.internets= ociety.org/




--_000_6463EBE2E8154B04BD3841CCDEE831E2isocorg_-- From nobody Wed Jan 6 04:46:01 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBF11B2B27 for ; Wed, 6 Jan 2016 04:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UgbKQvXx_8Q for ; Wed, 6 Jan 2016 04:45:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C9C1B2B1B for ; Wed, 6 Jan 2016 04:45:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCO41813; Wed, 06 Jan 2016 12:45:52 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0235.001; Wed, 6 Jan 2016 12:45:48 +0000 From: Hosnieh Rafiee To: Dan York Thread-Topic: [dane] any statistics of deployment available? Thread-Index: AdFIeslBxynRdYetRzmHZNYubTMahgAA7MYAAABVeAA= Date: Wed, 6 Jan 2016 12:45:48 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A715B0AF4A@lhreml504-mbs> References: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> <6463EBE2-E815-4B04-BD38-41CCDEE831E2@isoc.org> In-Reply-To: <6463EBE2-E815-4B04-BD38-41CCDEE831E2@isoc.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.218.212] Content-Type: multipart/alternative; boundary="_000_814D0BFB77D95844A01CA29B44CBF8A715B0AF4Alhreml504mbs_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.568D0C80.013F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a35c591445973c6eb2256b16270f084b Archived-At: Cc: IETF DANE Mailinglist Subject: Re: [dane] any statistics of deployment available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 12:46:00 -0000 --_000_814D0BFB77D95844A01CA29B44CBF8A715B0AF4Alhreml504mbs_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks a lot! Really helpful. Best, Hosnieh From: Dan York [mailto:york@isoc.org] Sent: 06 January, 2016 1:34 PM To: Hosnieh Rafiee Cc: IETF DANE Mailinglist Subject: Re: [dane] any statistics of deployment available? Hosnieh, On Jan 6, 2016, at 7:07 AM, Hosnieh Rafiee > wrote: Is there any statistics or a site that I can find regarding the deployment = of DANE over the internet? We have a list of sites providing DNSSEC statistics at: http://www.internetsociety.org/deploy360/dnssec/statistics/ but as I look at that I realized that we haven't listed any sites with DANE= statistics. One that I know of is: https://xmpp.net/reports.php#dnssecdane that lists the number of XMPP (Jabber) servers with DANE records. It would be great if we had more statistics on DANE deployment. If anyone = else has such a site out there please let me know and I'll be glad to add i= t to the Deploy360 list. Dan P.S. We also have the list of DANE test sites at: http://www.internetsociety.org/deploy360/resources/dane-test-sites/ but there aren't statistics associated with any of those sites that I can s= ee. --_000_814D0BFB77D95844A01CA29B44CBF8A715B0AF4Alhreml504mbs_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks a lot!

Really helpful.

Best,

Hosnieh=

 <= /p>

From: Dan York= [mailto:york@isoc.org]
Sent: 06 January, 2016 1:34 PM
To: Hosnieh Rafiee
Cc: IETF DANE Mailinglist
Subject: Re: [dane] any statistics of deployment available?

 

Hosnieh,

 

On Jan 6, 2016, at 7:07 AM, Hosnieh Rafiee <hosnieh.rafiee@huawei.com> w= rote:

 

Is there any statistics or a site that I can find re= garding the deployment of DANE over the internet?

 

We have a list of sites providing DNSSEC statistics = at:

 

 

but as I look at that I realized that we haven't lis= ted any sites with DANE statistics.  One that I know of is:=

 

 

that lists the number of XMPP (Jabber) servers with = DANE records.  

 

It would be great if we had more statistics on DANE = deployment.  If anyone else has such a site out there please let me kn= ow and I'll be glad to add it to the Deploy360 list.

 

Dan

 

P.S. We also have the list of DANE test sites at:&nb= sp;

 

 

but there aren't statistics associated with any of t= hose sites that I can see.

 =

 

 

--_000_814D0BFB77D95844A01CA29B44CBF8A715B0AF4Alhreml504mbs_-- From nobody Wed Jan 6 05:11:15 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE041B2B68 for ; Wed, 6 Jan 2016 05:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.238 X-Spam-Level: X-Spam-Status: No, score=0.238 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzHPQJxGgQWU for ; Wed, 6 Jan 2016 05:11:12 -0800 (PST) Received: from mail.sys4.de (mail.sys4.de [IPv6:2001:1578:400:111::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE28F1B2B63 for ; Wed, 6 Jan 2016 05:11:11 -0800 (PST) Received: from localhost (echo.sys4.de [127.0.0.1]) by mail.sys4.de (Postfix) with ESMTP id 3pbB0F0CnBz1GZZ for ; Wed, 6 Jan 2016 14:11:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; s=p-sys4-de-201501; t=1452085869; bh=XQHUwe6FdPTxpl0G4loTnNBJsulfaATCFma+LmPZ2jk=; h=Date:From:To:Subject:References:In-Reply-To; b=LpOeuabJrcvOwokwDrluvaZSR68WBDEO/0uFl8q+a15u/JSSUkS9JLsiVQynTGFhh ag9mOuvFphVyk1QZcSuJtW3JdwoMOXQOxMKKdK3sJmEJAVEuYXJ4QdnSxu/Zj7p0Hu UqhzlDJWhD+GDiaIadVcmnZlLeQw5JOjMlO35l8+M50yhbiWk8firneNqCPO/T/5OR 6ZPff5Vq6dxLGH+a+yeZkQ1DEMIWun6+lQbCnkwy4Fz8AEdOX8jt/TGqeBl5gUK910 dgvzqMGnesSUIvF4Q7ax9jfQEFIG1qHao6Msl2EOhcLEvY37Ii7fzzLtXU9Z0h5/D/ mxnq/8LYGGS9A== X-Virus-Scanned: amavisd-new at sys4.de Received: from sys4.de (ipbcc1a307.dynamic.kabel-deutschland.de [188.193.163.7]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3pbB0D40rqz1G0w for ; Wed, 6 Jan 2016 14:11:08 +0100 (CET) Date: Wed, 6 Jan 2016 14:11:06 +0100 From: Patrick Ben Koetter To: dane@ietf.org Message-ID: <20160106131105.GC14398@sys4.de> References: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> Archived-At: Subject: Re: [dane] any statistics of deployment available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 13:11:13 -0000 * Hosnieh Rafiee : > Hi, > > Is there any statistics or a site that I can find regarding the deployment of DANE over the internet? We did a complete IPv4 scan two weeks ago. AFAIK Viktor is about to analyse the data. But I don't know when he will be able to present results. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Wed Jan 6 06:16:38 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E7B1B2BF5 for ; Wed, 6 Jan 2016 06:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uuqx5CcF8r06 for ; Wed, 6 Jan 2016 06:16:35 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63ED11B2BF2 for ; Wed, 6 Jan 2016 06:16:35 -0800 (PST) Received: by mail-qg0-x232.google.com with SMTP id 6so224682707qgy.1 for ; Wed, 06 Jan 2016 06:16:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CJXiZ3EBLdSq9yULEcusVwdfcUAd//c75eJluFCcVkg=; b=SfYHhQjoHJDmlMff+fGEC9YhYePdWycPTxOR8O+Mn1rVBFRQ77sdzXdMbfrbIGCB3e Yt8miIFLFaohrR96FY0qu7lYfwPHIuyzxPabMlKLFFeHgaPVy4hD4Iz2gRF1KRDKXMY7 xQuf3X6Tam7RzZOU+8Yd3KxG07w0tSNRtj/wIKpF9mRrpcljokTLQjRt/22wfQ/46cTB uLSFRLtMUzl76rE/YucTB/uXWrkUc/fhiisRGctSCcPYQYqZzu7Zp+7hU2Pk+lwY5SVD DK3sjIfQgglzEzXcYGuNTFoylKBR49VQquFKatiFQXahizOXxiYx5wH6jNLyo5CmVYEL AJXg== MIME-Version: 1.0 X-Received: by 10.140.255.9 with SMTP id a9mr64247463qhd.103.1452089794632; Wed, 06 Jan 2016 06:16:34 -0800 (PST) Received: by 10.140.102.9 with HTTP; Wed, 6 Jan 2016 06:16:34 -0800 (PST) In-Reply-To: <20160106131105.GC14398@sys4.de> References: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> <20160106131105.GC14398@sys4.de> Date: Wed, 6 Jan 2016 09:16:34 -0500 Message-ID: From: Shumon Huque To: "" Content-Type: multipart/alternative; boundary=001a1139ff506421390528ab0047 Archived-At: Subject: Re: [dane] any statistics of deployment available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 14:16:37 -0000 --001a1139ff506421390528ab0047 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 6, 2016 at 8:11 AM, Patrick Ben Koetter wrote: > * Hosnieh Rafiee : > > Hi, > > > > Is there any statistics or a site that I can find regarding the > deployment of DANE over the internet? > > We did a complete IPv4 scan two weeks ago. AFAIK Viktor is about to analyse > the data. But I don't know when he will be able to present results. > > p@rick > I did a targeted survey of DANE TLSA record deployment (of some key application services: HTTPS, SMTP, and XMPP) at COM, NET, and the Alexa top 100K recently. See page 11 through 16 of the following presentation (DNS-OARC, October 2015): https://speakerdeck.com/shuque/next-steps-in-dane-adoption -- Shumon Huque --001a1139ff506421390528ab0047 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 6, 2016 at 8:11 AM, Patrick Ben Koetter <p@sys4.de> wrote:
* Hosnieh Rafiee <hosnieh.rafiee@huawei.com>:
> Hi,
>
> Is there any statistics or a site that I can find regarding the deploy= ment of DANE over the internet?

We did a complete IPv4 scan two weeks ago. AFAIK Viktor is about to = analyse
the data. But I don't know when he will be able to present results.

p@rick

I did a targeted survey of DANE = TLSA record deployment (of some key application services: HTTPS, SMTP, and = XMPP) at COM, NET, and the Alexa top 100K recently. See page 11 through 16 = of the following presentation (DNS-OARC, October 2015):
--001a1139ff506421390528ab0047-- From nobody Wed Jan 6 06:39:55 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD7C1B2C58 for ; Wed, 6 Jan 2016 06:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVdaqO03hZNS for ; Wed, 6 Jan 2016 06:39:53 -0800 (PST) Received: from mail-qg0-x263.google.com (mail-qg0-x263.google.com [IPv6:2607:f8b0:400d:c04::263]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3BA41B2C3C for ; Wed, 6 Jan 2016 06:39:52 -0800 (PST) Received: by mail-qg0-x263.google.com with SMTP id b35so22985438qge.0 for ; Wed, 06 Jan 2016 06:39:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:content-id:content-transfer-encoding:mime-version; bh=HZcdVoLe5TkOw2AxU/3CjB4BsmbeFNeAxkGYiOxPbzk=; b=0nqR2Q8gb7mpFubWmrBHrh0l8oL+1bxS2Om2/4mgnIF0YVO+foqheB9A0+aMf42ZmM 7Gv0s/8xqRbrWT9+Dt3KixJmwbdZlQQFNYY9Viio9xa5fRssebyEpKCRgorVoNVMaf8d Za6D5j9a6haACw9V6oL9JHajC68hgLMiYQNGSoaC9mffnee7gvtmKQLa6QyvkYr278VQ YvUHiZhjshydVrdxQsaGc2v4nK3fxtCvQC6UqtD1+UVismHYFvBNBY1isCJL037Patlr jX69x1SQlvTbHHFdrTB37dgSNfH6iarWK7RBB3K3utVAl3NnP+DjEmDuYReYZZm5PnWq 5+RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:content-id:content-transfer-encoding :mime-version; bh=HZcdVoLe5TkOw2AxU/3CjB4BsmbeFNeAxkGYiOxPbzk=; b=OmgR27HU1DUQPJNFEgcBYKuU9ziubgxqQRsOwSr5jZ57HTZKp0lI1bcqILueMiJYaD VJnjx4oRptN77/ceo4UfcRKgXiF80DcAgZ1nozz4/HmTlN2vFYlxcnwZ1RCB5Sve8DCF p4r6Iy1ewgJvJ8/YeN0QyFVf6ckXf73pszNMGRVgMfXwJ2VeNvVqVPwp7YjHMQT5JIOj WSiuq892q1/5xGQUU9/0qE0LpIEjIcOHF581HRtWN07h8fyj0LdPTySEyv0vWfi2vPSz sWeebI6hN3uikxIYpRXmAibhzbB+escIlc+4QhZ0Vg6CHyMJJBtqahHF5jOT3ndbfpil wzgQ== X-Gm-Message-State: ALoCoQmXuZCZbnwt86KHOjEILQoK14rXei33XFAoNtnxM3VgforivObyYSzbezlIdI42cjUd/hdLssiL6GoaRSID6HIYyXoAUP40xQfnCII4eDjpOJr1XOg= X-Received: by 10.140.91.73 with SMTP id y67mr128218044qgd.42.1452091192149; Wed, 06 Jan 2016 06:39:52 -0800 (PST) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id b90sm11990830qkj.7.2016.01.06.06.39.51 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 06 Jan 2016 06:39:52 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u06EdpSG032248 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jan 2016 09:39:51 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 6 Jan 2016 09:39:51 -0500 From: "Osterweil, Eric" To: Shumon Huque Thread-Topic: [dane] any statistics of deployment available? Thread-Index: AdFIeslBxynRdYetRzmHZNYubTMahgAMtMUAAAJJUgAAAJxQgA== Date: Wed, 6 Jan 2016 14:39:50 +0000 Message-ID: <7AD1AC24-6B15-45A8-886A-7136016DBA02@verisign.com> References: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> <20160106131105.GC14398@sys4.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <32C1E82A18877647BE7B53B9CC9C9075@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [dane] any statistics of deployment available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 14:39:55 -0000 There is also SecSpider. It tracks deployment stats here: http://secspider.verisignlabs.com/stats.html and deployment growth here: secspider.verisignlabs.com/growth.html Both pages include DNSSEC and DANE stats. Comments are very welcome. Eric > On Jan 6, 2016, at 9:16 AM, Shumon Huque wrote: >=20 > On Wed, Jan 6, 2016 at 8:11 AM, Patrick Ben Koetter wrote: > * Hosnieh Rafiee : > > Hi, > > > > Is there any statistics or a site that I can find regarding the deploym= ent of DANE over the internet? >=20 > We did a complete IPv4 scan two weeks ago. AFAIK Viktor is about to analy= se > the data. But I don't know when he will be able to present results. >=20 > p@rick >=20 > I did a targeted survey of DANE TLSA record deployment (of some key appli= cation services: HTTPS, SMTP, and XMPP) at COM, NET, and the Alexa top 100K= recently. See page 11 through 16 of the following presentation (DNS-OARC, = October 2015): >=20 > https://speakerdeck.com/shuque/next-steps-in-dane-adoption >=20 > --=20 > Shumon Huque >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Wed Jan 6 11:13:50 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696681A0116 for ; Wed, 6 Jan 2016 11:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E7fJkOIvztf for ; Wed, 6 Jan 2016 11:13:47 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B782E1A010B for ; Wed, 6 Jan 2016 11:13:47 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6BDF2284AED; Wed, 6 Jan 2016 19:13:46 +0000 (UTC) Date: Wed, 6 Jan 2016 19:13:46 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160106191346.GF18704@mournblade.imrryr.org> References: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> <20160106131105.GC14398@sys4.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160106131105.GC14398@sys4.de> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] any statistics of deployment available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 19:13:49 -0000 On Wed, Jan 06, 2016 at 02:11:06PM +0100, Patrick Ben Koetter wrote: > > Is there any statistics or a site that I can find regarding the deployment of DANE over the internet? > > We did a complete IPv4 scan two weeks ago. AFAIK Viktor is about to analyse > the data. But I don't know when he will be able to present results. I don't have the scan data yet, but I will look. At present my survey has found just over 10400 domains with working DANE TLSA records for SMTP, a majority of these are from a three hosting providers: 5146 udmedia.de 1199 mx.transip.email 933 mx.nederhost.net Based on email discussion with the top two, it seems I've captured around 10% of their actual deployed numbers, so the number of SMTP domains is around 100k, with over 95% of these hosted by the above providers. The number of SMTP DANE domains that are "large enough" by whatever criteria Gmail uses to list a domain in its email transparency report stands at 30 (was 24 in early October). We're still early in the deployment process, but DANE support in OpenSSL will be available soon, which I think will help. Hard to adopt a standard with no "running code". Two of the six DANE patches scheduled for review have been reviewed and are now part of OpenSSL 1.1.0-dev, the rest will join them soon I hope. -- Viktor. From nobody Fri Jan 8 12:13:11 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072CA1B2B6F for ; Fri, 8 Jan 2016 12:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0yyO8y28RqG for ; Fri, 8 Jan 2016 12:13:01 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69A81B2B6E for ; Fri, 8 Jan 2016 12:13:01 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E3130284DA6; Fri, 8 Jan 2016 20:13:00 +0000 (UTC) Date: Fri, 8 Jan 2016 20:13:00 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160108201300.GN18704@mournblade.imrryr.org> References: <20151227092706.GN18704@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151227092706.GN18704@mournblade.imrryr.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] DANE TLSA support in OpenSSL 1.1.0 coming soon... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 20:13:05 -0000 On Sun, Dec 27, 2015 at 09:27:06AM +0000, Viktor Dukhovni wrote: > The OpenSSL code for DANE 1.1.0 is done, pending internal team > review. I am hoping it will appear in 1.1.0-pre2 in early January. > If the review takes too long, it might slip into 1.1.0-pre3 in > February. I'm working to avoid that. The review is complete, barring any last-minute issues the alpha2 release with DANE support should be available late next week. Previews available via the "master" OpenSSL branch on github. git clone https://github.com/openssl/openssl.git [ Separately, I changed how deprecated features are handled to make it easier to maintain as much backwards-compatibility as possible+desired, but this breaks the automated construction of library exported symbols, especially on Windows, so that needs to be fixed before there's an alpha2 release. ] -- Viktor. From nobody Fri Jan 8 12:17:58 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8332F1B2B78 for ; Fri, 8 Jan 2016 12:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xg1L4IaHsVUD for ; Fri, 8 Jan 2016 12:17:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1611B2B77 for ; Fri, 8 Jan 2016 12:17:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGN80517; Fri, 08 Jan 2016 20:17:48 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0235.001; Fri, 8 Jan 2016 20:17:46 +0000 From: Hosnieh Rafiee To: "dane@ietf.org" Thread-Topic: [dane] any statistics of deployment available? Thread-Index: AdFIeslBxynRdYetRzmHZNYubTMahgACOpAAAAyqfgAAZr4wMA== Date: Fri, 8 Jan 2016 20:17:45 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A715B0BB55@lhreml504-mbs> References: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> <20160106131105.GC14398@sys4.de> <20160106191346.GF18704@mournblade.imrryr.org> In-Reply-To: <20160106191346.GF18704@mournblade.imrryr.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.217.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5690196C.01FF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c223e647c4a85613a34b1bdea05bba3a Archived-At: Subject: Re: [dane] any statistics of deployment available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 20:17:55 -0000 -----Original Message----- From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Viktor Dukhovni Sent: 06 January, 2016 8:14 PM To: dane@ietf.org Subject: Re: [dane] any statistics of deployment available? On Wed, Jan 06, 2016 at 02:11:06PM +0100, Patrick Ben Koetter wrote: > > Is there any statistics or a site that I can find regarding the deploym= ent of DANE over the internet? >=20 > We did a complete IPv4 scan two weeks ago. AFAIK Viktor is about to=20 > analyse the data. But I don't know when he will be able to present result= s. I don't have the scan data yet, but I will look. At present my survey has = found just over 10400 domains with working DANE TLSA records for SMTP, a ma= jority of these are from a three hosting providers: 5146 udmedia.de 1199 mx.transip.email 933 mx.nederhost.net Based on email discussion with the top two, it seems I've captured around 1= 0% of their actual deployed numbers, so the number of SMTP domains is aroun= d 100k, with over 95% of these hosted by the above providers. The number of SMTP DANE domains that are "large enough" by whatever criteri= a Gmail uses to list a domain in its email transparency report stands at 30= (was 24 in early October). We're still early in the deployment process, but DANE support in OpenSSL wi= ll be available soon, which I think will help. Hard to adopt a standard wi= th no "running code". Two of the six DANE patches scheduled for review have been reviewed and are= now part of OpenSSL 1.1.0-dev, the rest will join them soon I hope. [Hosnieh] Thanks a lot Viktor. Is there any estimation on when this will be= available? Thanks, Best, Hosnieh From nobody Fri Jan 8 12:26:20 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8011B2B84 for ; Fri, 8 Jan 2016 12:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1Gw1SUupYiN for ; Fri, 8 Jan 2016 12:26:17 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F028E1B2B81 for ; Fri, 8 Jan 2016 12:26:16 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1C660284DA6; Fri, 8 Jan 2016 20:26:16 +0000 (UTC) Date: Fri, 8 Jan 2016 20:26:16 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160108202615.GP18704@mournblade.imrryr.org> References: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> <20160106131105.GC14398@sys4.de> <20160106191346.GF18704@mournblade.imrryr.org> <814D0BFB77D95844A01CA29B44CBF8A715B0BB55@lhreml504-mbs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A715B0BB55@lhreml504-mbs> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] any statistics of deployment available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 20:26:19 -0000 On Fri, Jan 08, 2016 at 08:17:45PM +0000, Hosnieh Rafiee wrote: > Two of the six DANE patches scheduled for review have been reviewed and > are now part of OpenSSL 1.1.0-dev, the rest will join them soon I hope. > > [Hosnieh] Thanks a lot Viktor. Is there any estimation on when this will be available? commit 59fd40d4e5030a7257edd11d758eab1dcebb3787 Author: Viktor Dukhovni Date: Thu Jan 7 22:00:14 2016 -0500 DANE CHANGES Reviewed-by: Richard Levitte -- Viktor. From nobody Tue Jan 12 07:15:40 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973091B2A9A for ; Tue, 12 Jan 2016 07:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2B2xfy0yYba for ; Tue, 12 Jan 2016 07:15:37 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93BB51B2A9D for ; Tue, 12 Jan 2016 07:15:37 -0800 (PST) Received: by mail-qg0-x22e.google.com with SMTP id e32so341695754qgf.3 for ; Tue, 12 Jan 2016 07:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=w4bFP/AXYpOGY2YXgWcohbEoAK1Z6wsoDQUgsGCqJDA=; b=yo7M4nMLYwCqC6b06v9yULX7F4v7ET++cpJb7gyS8ndv0tHXAjH/FRC/QQpydkouXW l1EUOg8Tp2zSD7Sl7x5GXX1jC9HSNY3TEis/UGZT0KzfFQR7viUSc9Qjk+lQbCY8rPVR AVD7gWixmoEp2SbouRKgFv1zlLTyqPUc7QGDux+WVOrtkvDbtoNwaPn97V3NUT3p9Edh lEuHSsipcjb0H4WFjwteuYluQzDkoffyG70rkkbgRSMFZNg/0T0ePrM1El5GmnD7NaP2 ORV4wPli2Vl1otRCpx/tHdudybFJynnUglp1nTkQLbXYhqX36lIedInBu+qt528Qh/oF CjYw== MIME-Version: 1.0 X-Received: by 10.141.3.9 with SMTP id f9mr179624118qhd.98.1452611736778; Tue, 12 Jan 2016 07:15:36 -0800 (PST) Received: by 10.140.102.9 with HTTP; Tue, 12 Jan 2016 07:15:36 -0800 (PST) Date: Tue, 12 Jan 2016 10:15:36 -0500 Message-ID: From: Shumon Huque To: "" Content-Type: multipart/alternative; boundary=001a1139b9c49141ed0529248604 Archived-At: Subject: [dane] DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 15:15:39 -0000 --001a1139b9c49141ed0529248604 Content-Type: text/plain; charset=UTF-8 Hi folks, We've updated the DANE Client Certificates draft, and also posted a new draft describing a TLS extension to convey a DANE client identity to a TLS server. Reviews/feedback/questions appreciated. TLS Extension for DANE Client Identity: https://tools.ietf.org/html/draft-huque-tls-dane-clientid-00 Describes a new (D)TLS extension to convey a DANE client identity. This enables the use of raw public key client authentication with DANE. It also helps client certificate authentication work better and more efficiently. (We'll post this to the TLS working group also.) TLS Client Authentication via DANE TLSA Records: https://tools.ietf.org/html/draft-huque-dane-client-cert-02 This is an update of the DANE client certificates draft we introduced just before IETF93. It is now renamed to "TLS Client Authentication" because it deals with more than just client certificates, treating raw public key auth on par with the former throughout (rather than mostly as a footnote in the earlier version). It references the TLS extension draft and updates the expected protocol behavior accordingly. There are also updated references to documents that have now become RFCs (notably 7671 - DANE Updates and Ops guidance). -- Shumon Huque --001a1139b9c49141ed0529248604 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= br>
=C2=A0 Describes a new (D)TLS extension to convey a DANE clie= nt
=C2=A0 identity. This enables the use of raw public key client=
=C2=A0 authentication with DANE. It also helps client certificat= e
=C2=A0 authentication work better and more efficiently.

=C2=A0 (We'll post this to the TLS working group also= .)

TLS Client Authentication via DANE TLSA Records= :
https://tools.ietf.org/html/draft-huque-dane-client-cert-02

=C2=A0 This is an update of the DANE client certific= ates draft
=C2=A0 we introduced just before IETF93. It is now ren= amed to
=C2=A0 "TLS Client Authentication" because it d= eals with more
=C2=A0 than just client certificates, treating raw= public key
=C2=A0 auth on par with the former throughout (rather= than mostly
=C2=A0 as a footnote in the earlier version). It ref= erences the
=C2=A0 TLS extension draft and updates the expected p= rotocol behavior
=C2=A0 accordingly. There are also updated refer= ences to documents
=C2=A0 that have now become RFCs (notably 7671= - DANE Updates and
=C2=A0 Ops guidance).

--
Shumon Huque

--001a1139b9c49141ed0529248604-- From nobody Tue Jan 12 12:07:25 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086481A882F for ; Tue, 12 Jan 2016 12:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljl5gAVlrxEd for ; Tue, 12 Jan 2016 12:07:21 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.22.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785B61A8823 for ; Tue, 12 Jan 2016 12:07:20 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id BD79E1E541; Tue, 12 Jan 2016 20:07:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1452629239; bh=LuLysf+7SEaB67SSYX2CFOVwOmLA6bhlrnx5vq1+gv0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=kxG7emiLACJWVrLqReYSkCoOSu3VmYAdizoOz+rNGWx8o+NUuZ3b7NvGv08YjaSAY qO+xa4DEkoXDDZSclV1EqQLLEOO2bPi3cp9UdBFzk8MPRmOeWnNWsxOJARndq1R024 qHPSAQjmc9D7cdWa4tY2so4u/8d+varpYlAe8nJM= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 90CAF1003CD26; Tue, 12 Jan 2016 20:05:51 +0000 (UTC) From: James Cloos To: Shumon Huque In-Reply-To: (Shumon Huque's message of "Tue, 12 Jan 2016 10:15:36 -0500") References: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 12 Jan 2016 15:05:51 -0500 Message-ID: Lines: 19 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:160112:shuque@gmail.com::gwg6n/TziGHVhhbB:CV1Rk X-Hashcash: 1:28:160112:dane\@ietf.org\::NreWfb2pXJNtZMif:0BtsFH X-Hashcash: 1:28:160112:dane@ietf.org::eIaEExIPu3Bp+QHF:0002eJPK Archived-At: Cc: "" Subject: Re: [dane] DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 20:07:24 -0000 For draft-huque-dane-client-cert I'd still prefer RR names like: _smtp._client.example for the cert provided by an smtp client which HELO/EHLOs as example. And similarly for other protocols. Rather than things like _smtp-client. Putting all of the client TLSAs under a single label allows (but obviously does not require) them to be in their own zone. Than can be useful. And in the case where the proposed tls extension is not used, it should be OK for the name to be in CN, too. So something like 'MUST be in either dnsName or CN, but SHOULD be in the dnsName'. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue Jan 12 14:21:48 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B9E1A8AC2 for ; Tue, 12 Jan 2016 14:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58N9cI7CGppS for ; Tue, 12 Jan 2016 14:21:45 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9414B1A8A3D for ; Tue, 12 Jan 2016 14:21:45 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id p186so181944205qke.0 for ; Tue, 12 Jan 2016 14:21:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=knHlwp00O+kRpc3PnKbIHtG1Yp9JrEL5tNjfYsFGkWU=; b=w4MkPqk4w/UiGaIhXttGv3bDiuC3PMiTCDNrXWD8E19tjjZ8QSe68msElpHJCKXMnW hMmnPeT8YS+mQoH93ufIHupwmS30ObN7UkKYq+dJ7xA52/p2xqLbXDdGq20FX2evfv/c FLA4+li+/eSy8i6ECMw9Hs9xdQUk8hli+FkkDxEIpZnj5hAionmbk0yeFXM1UAtlWwq6 gJ08n8ycF8msupLhvV4FBaWkuamAFYVjscJY7PKxTHRKv4LWDQhtEomOB5KkjUFhRVQn 44L6vRYR3ToLw1Si/GB2Uul41CnuXm9L1h3vos1rF+Mz+Wo8wHEbCrva41yJPaJb339l CXmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=knHlwp00O+kRpc3PnKbIHtG1Yp9JrEL5tNjfYsFGkWU=; b=QTNc9pjpqfB3di41Mdvn52Qu2oA772O5a1kFBEqs/RszEIe8YYGJ2Hg+Yon/yKKsLj E6qAyQerOfMsrerhha5j7GKjMus+dxSQP+kwagOU8kTQpobStIZTQpHK3QdCOAuh6oVF QAh4vf2UOBfsUjd6xiuUDkoxLlMM58jBZkxm40Wg6t1lFAG5Xa4NXpyjlo3VNebaMz2L ZYG6pLW+xFVON2m3UbhJ7Lv27R1bOP5KI6FRk/GatO6YoXVWGTsEnVgdatvVMnmo77V5 D+YR1CyzQZSkNXKyPR4/khRUagYP71Li5+99qwxRiPi/AEg3EkedFmpRrhxD+hRZ7IKa mcVQ== X-Gm-Message-State: ALoCoQmwbwuRjk3Hrd5NrYF1DRbDgITlUwDctB9not5iVs7pMZKYeyURgLDJoC/2M9Scnknvvqh3VknQQ59EgMeENVgIdmJtxw== MIME-Version: 1.0 X-Received: by 10.55.73.69 with SMTP id w66mr172430331qka.39.1452637304801; Tue, 12 Jan 2016 14:21:44 -0800 (PST) Received: by 10.140.102.9 with HTTP; Tue, 12 Jan 2016 14:21:44 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Jan 2016 17:21:44 -0500 Message-ID: From: Shumon Huque To: James Cloos Content-Type: multipart/alternative; boundary=001a114a8dc08a6eb105292a7ac4 Archived-At: Cc: "" Subject: Re: [dane] DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 22:21:47 -0000 --001a114a8dc08a6eb105292a7ac4 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 3:05 PM, James Cloos wrote: > For draft-huque-dane-client-cert I'd still prefer RR names like: > > _smtp._client.example > > for the cert provided by an smtp client which HELO/EHLOs as example. > And similarly for other protocols. Rather than things like _smtp-client. > > Putting all of the client TLSAs under a single label allows (but > obviously does not require) them to be in their own zone. > Thanks for the feedback. I had the _service._client form in an earlier version of this draft but Viktor talked me out of it, on the grounds of insufficient usefulness and unneeded complexity. I'd be interested in hearing other opinions on this point also. On the "_smtp-client" label choice, I had originally used just "_smtp", but a colleague more plugged into IANA service name registration procedures advised me that I should choose a different client specific label. The "_smtp" label is a server side label with an associated server side port, and that reusing that label for a client identifier would elicit objections. Than can be useful. > > And in the case where the proposed tls extension is not used, it should > be OK for the name to be in CN, too. So something like 'MUST be in > either dnsName or CN, but SHOULD be in the dnsName'. > Current IETF specs strongly discourage putting domain name identifiers in the subject CN (see RFC6125 for example), which I agree with, and whose lead I followed. I suspect that DANE client certificates is enough of a green field application, that there aren't backwards compatibility concerns that would prove to be impediment here. Even if you were using public CAs, practically all of them today can issue domain names in dNSName. SRVName unfortunately is a real world impediment for some parties, which is why that one isn't a MUST. What specific concerns did you have in mind with disallowing CN? -- Shumon Huque --001a114a8dc08a6eb105292a7ac4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 12, 2016 at 3:05 PM, James Cloos <cloos@jhcloos.com>= wrote:
For draft-huque-dane-client-cert = I'd still prefer RR names like:

=C2=A0_smtp._client.example

for the cert provided by an smtp client which HELO/EHLOs as example.
And similarly for other protocols.=C2=A0 Rather than things like _smtp-clie= nt.

Putting all of the client TLSAs under a single label allows (but
obviously does not require) them to be in their own zone.
<= div>
Thanks for the feedback. I had the _service._client form= in an earlier=C2=A0
version of this draft but Viktor talked me o= ut of it, on the grounds of=C2=A0
insufficient usefulness and unn= eeded complexity. I'd be interested in=C2=A0
hearing other op= inions on this point also.

On the "_smtp-clie= nt" label choice, I had originally used just "_smtp", but
a colleague more plugged into IANA service name registration proced= ures
advised me that I should choose a different client specific = label. The
"_smtp" label is a server side label with an= associated server side port,
and that reusing that label for a c= lient identifier would elicit objections.

Than can be useful.

And in the case where the proposed tls extension is not used, it should
be OK for the name to be in CN, too.=C2=A0 So something like 'MUST be i= n
either dnsName or CN, but SHOULD be in the dnsName'.

Current IETF specs strongly discourage putting domain nam= e identifiers
in the subject CN (see RFC6125 for example), which = I agree with, and
whose lead I followed. I suspect that DANE clie= nt certificates is enough=C2=A0
of a green field application, tha= t there aren't backwards compatibility=C2=A0
concerns that wo= uld prove to be impediment here. Even if you were using
public CA= s, practically all of them today can issue domain names in=C2=A0
= dNSName. SRVName unfortunately is a real world impediment for some
parties, which is why that one isn't a MUST.

What specific concerns did you have in mind with disallowing CN?

--=C2=A0
Shumon Huque

<= /div>
--001a114a8dc08a6eb105292a7ac4-- From nobody Tue Jan 12 15:32:40 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EAA1A9060 for ; Tue, 12 Jan 2016 15:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg1CtZYIXIbH for ; Tue, 12 Jan 2016 15:32:37 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA58B1A9067 for ; Tue, 12 Jan 2016 15:32:36 -0800 (PST) Received: from [172.31.24.203] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id CD57F284809 for ; Tue, 12 Jan 2016 23:32:35 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 12 Jan 2016 18:32:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: dane@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [dane] DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 23:32:38 -0000 > On Jan 12, 2016, at 5:21 PM, Shumon Huque wrote: >=20 > On the "_smtp-client" label choice, I had originally used just = "_smtp", but > a colleague more plugged into IANA service name registration = procedures > advised me that I should choose a different client specific label. The > "_smtp" label is a server side label with an associated server side = port, > and that reusing that label for a client identifier would elicit = objections. >=20 The reason I talked you out of it, is that I wanted the query-domain for client TLSA records to be the same as the SRV-ID. Injecting a = sub-domain makes it more difficult to use the names in question if SRV-ID is what's in the certificate. Using the SRV-ID as the query domains is not an absolute requirement, = but it is a simplification that should not be discard too lightly. = Trade-off judgement call... --=20 Viktor. From nobody Tue Jan 12 17:32:19 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3011B2AA8 for ; Tue, 12 Jan 2016 17:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KvCeQRp82xv for ; Tue, 12 Jan 2016 17:32:16 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237421B2B51 for ; Tue, 12 Jan 2016 17:32:16 -0800 (PST) Received: (qmail 36201 invoked from network); 13 Jan 2016 01:32:14 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 13 Jan 2016 01:32:14 -0000 Date: 13 Jan 2016 01:31:52 -0000 Message-ID: <20160113013152.54184.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 01:32:17 -0000 >On the "_smtp-client" label choice, I had originally used just "_smtp", but >a colleague more plugged into IANA service name registration procedures >advised me that I should choose a different client specific label. The >"_smtp" label is a server side label with an associated server side port, >and that reusing that label for a client identifier would elicit objections. Yes, no kidding. In the DNS, service names only appear as subnames of transport names. So one possibility would be to register smtp-client as a service name, so the DNS label would be _smtp-client._tcp.whatever.example. On the other hand, these certificates aren't identifying services, they're identifying clients, and unless I misunderstand, it should be equally useful to identify clients for POP, IMAP, submission, and anything else that can do TLS. The list of service names already has a fair number of client names, with the naming utterly inconsistent, some with a trailing c, some with trailing "client", trailing "-client", trailing "-cl", and a few just random acronyms. To minimize the chaos I'd suggest registering a psedudo-service name "client", always used with the actual service name as its subname. So for my SMTP, POP, IMAP, and SUBMIT clients, the names would be _smtp._client._tcp.whatever.example _pop3s._client._tcp.whatever.example _imaps._client._tcp.whatever.example _submission._client._tcp.whatever.example I suppose you could use the port number like RFC 6698 does but that seems wrong since the server picks the port number. If a SRV record says that the server is, say, running pop3s on port 1234, the client is still doing pop3s and can't rename its TLSA record on the fly. Registering the service name is easy, just a few paragraphs in the IANA considerations section. R's, John From nobody Tue Jan 12 17:47:26 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E871B2B8B for ; Tue, 12 Jan 2016 17:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jnpV_4fiL9E for ; Tue, 12 Jan 2016 17:47:22 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E281B2B89 for ; Tue, 12 Jan 2016 17:47:22 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id t64so30190170qke.1 for ; Tue, 12 Jan 2016 17:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zvTUkxacmZy0ghWZl3mU5cyPFOdA5ltQRD+UnCvO9IM=; b=t1ByhSMMiFONpaPviwLWqTwObIlUPCjviofIF499WtyzmzZ26LBA03Xbh8qocNibfG CyidZzFLU5zu582IuTfIXGx8h7Zofh1yZpV7kiGyKzNSG8gbMPqpAWHaEvQyKRf5tJeM 966lQmpAsI0CykBWA5XULEMLpLRXK9NsJgHIB6dzUpi5nQdsLVf7whY4y02/taYNqPlr FiwYU69MV+BsNEFjSm0a0cepYb8epxisWmYgN8cIc8dyE01L7BotHnlzJfTgqHAH1oiG QdvJSDOs6u2UZepjLPTpTtBu2JA+efHY4TkZnI56sWmzY284lYESGjnOjOPjZl0IRQtk Nlag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zvTUkxacmZy0ghWZl3mU5cyPFOdA5ltQRD+UnCvO9IM=; b=Nj9+q4MdpG+ZOZuUZmmMVZ7BFIHwsq818TkhDN5DFewfzVKrJG40I0LewPCs5BgwEZ 8AzRbLDObSthxeKSe6iuviLoOWhrXIIacxD3DHmttuILd36RQn5xszEDJg0gJKDQTvfr mzg7L8V1p1S8hPCRtK26zU4fREZeGiF1g4lbggQ57yIWb7p9nnfXlMmlYMhrwHbD9+ah dAw7WRfFzhYtDhoJebDBZsjqUM6gRkf4EFWnXTVdfze6JoKZusKZgKLMYyfBZAfPPcbn i+fuV0QPiHIVqErP7Q16Y/ofZSOYBzxUD0FrP13OBL8PEueXxrzRilGhA6YQXRmMOyXn llxw== X-Gm-Message-State: ALoCoQl6DydswVssvXuMcYOGpl1ccQQWN4dVxpQYIL890xSG3JyYbZzD9jJ72OQpfTdliIuS+X+ZAw7Kh+V3/IG//KTLGJjKuw== MIME-Version: 1.0 X-Received: by 10.55.31.228 with SMTP id n97mr27714101qkh.72.1452649641281; Tue, 12 Jan 2016 17:47:21 -0800 (PST) Received: by 10.140.102.9 with HTTP; Tue, 12 Jan 2016 17:47:21 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Jan 2016 20:47:21 -0500 Message-ID: From: Shumon Huque To: "" Content-Type: multipart/alternative; boundary=001a11478dacda1cf005292d5950 Archived-At: Subject: Re: [dane] DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 01:47:23 -0000 --001a11478dacda1cf005292d5950 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 6:32 PM, Viktor Dukhovni wrote: > > > On Jan 12, 2016, at 5:21 PM, Shumon Huque wrote: > > > > On the "_smtp-client" label choice, I had originally used just "_smtp", > but > > a colleague more plugged into IANA service name registration procedures > > advised me that I should choose a different client specific label. The > > "_smtp" label is a server side label with an associated server side port, > > and that reusing that label for a client identifier would elicit > objections. > > > > The reason I talked you out of it, is that I wanted the query-domain for > client TLSA records to be the same as the SRV-ID. Injecting a sub-domain > makes it more difficult to use the names in question if SRV-ID is > what's in the certificate. > > Using the SRV-ID as the query domains is not an absolute requirement, but > it is a simplification that should not be discard too lightly. Trade-off > judgement call... > Ah yes, thanks for reminding me. I agree this is a useful rationale for keeping the form the way that it is. -- Shumon Huque --001a11478dacda1cf005292d5950 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 12, 2016 at 6:32 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
<= br> > On Jan 12, 2016, at 5:21 PM, Shumon Huque <shuque@gmail.com> wrote:
>
> On the "_smtp-client" label choice, I had originally used ju= st "_smtp", but
> a colleague more plugged into IANA service name registration procedure= s
> advised me that I should choose a different client specific label. The=
> "_smtp" label is a server side label with an associated serv= er side port,
> and that reusing that label for a client identifier would elicit objec= tions.
>

The reason I talked you out of it, is that I wanted the query-domain= for
client TLSA records to be the same as the SRV-ID.=C2=A0 Injecting a sub-dom= ain
makes it more difficult to use the names in question if SRV-ID is
what's in the certificate.

Using the SRV-ID as the query domains is not an absolute requirement, but it is a simplification that should not be discard too lightly.=C2=A0 Trade-= off
judgement call...

Ah yes, thanks for re= minding me. I agree this is a useful rationale for keeping
the fo= rm the way that it is.

--=C2=A0
Shumon H= uque

--001a11478dacda1cf005292d5950-- From nobody Tue Jan 12 18:03:31 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE331B2BBA for ; Tue, 12 Jan 2016 18:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBjJu2HVSHAA for ; Tue, 12 Jan 2016 18:03:27 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9362A1B2BB9 for ; Tue, 12 Jan 2016 18:03:27 -0800 (PST) Received: by mail-qg0-x231.google.com with SMTP id 6so365887556qgy.1 for ; Tue, 12 Jan 2016 18:03:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aoMouB/NF2ne6GIdJL2u8WetTdQlt+29rnyN/Zl60nI=; b=Nd6rs2BXOTXyTaC1bVk4KSEZB71rORB2mnOb3C+9+gA22DvtpQFdY4HC8pSi82FVoB RKkWLvcWrpLEP9JHhveHX6y3dJNPE1ahUDdN8Nzrf6OyHKG3nMo6pxI5bnFLzug1KzWq pgrt87E33VUDar0/6X7gR2VceDqiXtwg4Kbu7fJtLaqBY4LOExMoPAkRZBgfA3PNk33d MdA9UB9gwORNQkFQb40nYM6zCYNcYKTVXXszGbNsjzwSYQY84fZ3iFgSEUj+rcPFTEpT WTlb7kEmjJqFpD2Jvjm0u4jxKjLFnSaO6SOIoOLhdQFDq7SwZLd9/paqF/DTOcGm9rP3 QGQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aoMouB/NF2ne6GIdJL2u8WetTdQlt+29rnyN/Zl60nI=; b=DN51Ihqz2qTn1k7IMHenKJBBKp8HuTcMyRK1jLo9V7fhu29qb/Pp2lRppJBgbmYlXN M7bYV26egxeuMIkutuKPpm3YIgMgdF1qztEsPWwgWWQKw69h5/h4UtUo0Vm1w2puxynS MNBv/Q8OTe4Lv2LaBw3QlGQT4ZjU9Bbed5h8SH5mEpIPmF0B4en4pq8CYRUDMYgx8AZO aaAp8RNGTvXBw3W1zWwrfv6BY8O28JdAi58JqNn19kdlH2s8CBcvXX3cpM5TOCsjCqOp c+oQlqitjw8RCPBRosh/VrxSfRMDLzDZUQWrNPCr/n3pn0l1HDVrqNTlK8dvoxBAKYz0 gPNg== X-Gm-Message-State: ALoCoQml5qzPBmrIQL/eupdwWu8LjaNWMZmIUMqPmSFW0f4IC75HXyPBgFqZMuX+XXk7L/Prx5cTEGndxnfT+Km2hniCOLWnzg== MIME-Version: 1.0 X-Received: by 10.140.237.74 with SMTP id i71mr122018691qhc.55.1452650606706; Tue, 12 Jan 2016 18:03:26 -0800 (PST) Received: by 10.140.102.9 with HTTP; Tue, 12 Jan 2016 18:03:26 -0800 (PST) In-Reply-To: <20160113013152.54184.qmail@ary.lan> References: <20160113013152.54184.qmail@ary.lan> Date: Tue, 12 Jan 2016 21:03:26 -0500 Message-ID: From: Shumon Huque To: John Levine Content-Type: multipart/alternative; boundary=001a1135914c6548b405292d934a Archived-At: Cc: "" Subject: Re: [dane] DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 02:03:30 -0000 --001a1135914c6548b405292d934a Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 8:31 PM, John Levine wrote: > >On the "_smtp-client" label choice, I had originally used just "_smtp", > but > >a colleague more plugged into IANA service name registration procedures > >advised me that I should choose a different client specific label. The > >"_smtp" label is a server side label with an associated server side port, > >and that reusing that label for a client identifier would elicit > objections. > > Yes, no kidding. > > In the DNS, service names only appear as subnames of transport names. > So one possibility would be to register smtp-client as a service name, > so the DNS label would be _smtp-client._tcp.whatever.example. > I would say "only appear *today* under transport names", but this isn't a hard and fast requirement. We should feel free to construct TLSA owner names in a form that makes sense for the specific application. For the purposes of this draft, including a transport label might make sense if we expected clients to have distinct transport protocol specific authentication credentials for the same application. This seems unlikely to me. On the other hand, these certificates aren't identifying services, > they're identifying clients, and unless I misunderstand, it should be > equally useful to identify clients for POP, IMAP, submission, and > anything else that can do TLS. The list of service names already has > a fair number of client names, with the naming utterly inconsistent, > some with a trailing c, some with trailing "client", trailing > "-client", trailing "-cl", and a few just random acronyms. > Yeah, I noticed the inconsistency too - a bit unfortunate! > To minimize the chaos I'd suggest registering a psedudo-service name > "client", always used with the actual service name as its subname. > So for my SMTP, POP, IMAP, and SUBMIT clients, the names would be > > _smtp._client._tcp.whatever.example > _pop3s._client._tcp.whatever.example > _imaps._client._tcp.whatever.example > _submission._client._tcp.whatever.example > See Viktor's previous note about why we excluded a _client label. I suppose you could use the port number like RFC 6698 does but that > seems wrong since the server picks the port number. If a SRV record > says that the server is, say, running pop3s on port 1234, the client > is still doing pop3s and can't rename its TLSA record on the fly. > Right, we arrived at the same conclusion, and hence excluded the port number from the client record name. -- Shumon Huque --001a1135914c6548b405292d934a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 12, 2016 at 8:31 PM, John Levine <johnl@taugh.com> wro= te:
>On the "_sm= tp-client" label choice, I had originally used just "_smtp",= but
>a colleague more plugged into IANA service name registration procedures=
>advised me that I should choose a different client specific label. The<= br> >"_smtp" label is a server side label with an associated serve= r side port,
>and that reusing that label for a client identifier would elicit object= ions.

Yes, no kidding.

In the DNS, service names only appear as subnames of transport names.
So one possibility would be to register smtp-client as a service name,
so the DNS label would be _smtp-client._tcp.whatever.example.

I would say "only appear *today* under transpor= t names", but this isn't a=C2=A0
hard and fast requireme= nt. We should feel free to construct TLSA owner=C2=A0
names in a = form that makes sense for the specific application. For the
purpo= ses of this draft, including a transport label might make sense if
we expected clients to have distinct transport protocol specific authenti= cation
credentials for the same application. This seems unlikely = to me.

On the other hand, these certificates aren't identifying services,
they're identifying clients, and unless I misunderstand, it should be equally useful to identify clients for POP, IMAP, submission, and
anything else that can do TLS.=C2=A0 The list of service names already has<= br> a fair number of client names, with the naming utterly inconsistent,
some with a trailing c, some with trailing "client", trailing
"-client", trailing "-cl", and a few just random acrony= ms.

Yeah, I noticed the inconsistency t= oo - a bit unfortunate!
=C2=A0
I suppose you could use the port number like RFC 6698 does but that
seems wrong since the server picks the port number.=C2=A0 If a SRV record says that the server is, say, running pop3s on port 1234, the client
is still doing pop3s and can't rename its TLSA record on the fly.

Right, we arrived at the same conclusion, an= d hence excluded the port
number from the client record name.

--=C2=A0
Shumon Huque

<= /div>
--001a1135914c6548b405292d934a-- From nobody Tue Jan 12 18:10:22 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646731B2BD4 for ; Tue, 12 Jan 2016 18:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6sXYTzA7yma for ; Tue, 12 Jan 2016 18:10:16 -0800 (PST) Received: from mail.zash.se (ip66.hethane.riksnet.nu [85.11.25.66]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75ECB1B2BD3 for ; Tue, 12 Jan 2016 18:10:16 -0800 (PST) Received: from localhost (localhost [::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.zash.se (Postfix) with ESMTPSA id 7B19061E46 for ; Wed, 13 Jan 2016 03:10:13 +0100 (CET) To: dane@ietf.org References: From: Kim Alvefur Openpgp: id=3E52119EF853C59678DBBF6BADED9A77B67AD329; url=http://zash.se/~zash/pubkey.asc X-Enigmail-Draft-Status: N1110 Message-ID: <5695B204.2000507@zash.se> Date: Wed, 13 Jan 2016 03:10:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="paVNrxrETVGsMUUct5R8fcBfpn4IwbnR0" Archived-At: Subject: Re: [dane] DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 02:10:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --paVNrxrETVGsMUUct5R8fcBfpn4IwbnR0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/12/2016 11:21 PM, Shumon Huque wrote: > On the "_smtp-client" label choice, That seems like it will cause confusion considering _xmpp-client is used in the XMPP world to refer to where the end-users connect their user agents to, so basically equivalent to _submission in email. And then there's _xmpp-server for communication between servers. FWIW, I would suggest _smtp-out as a less confusing label. The word "client" is a bit ambiguous whether it refers to a user agent or a server in the process of connecting to another server. It would help to be more explicit about which one of these are being referred to, or if it applies to both. Client-DANE in the later context, enabling mutual authentication between SMTP servers could be a nice improvement / complement to SPF & co. --=20 Kim "Zash" Alvefur --paVNrxrETVGsMUUct5R8fcBfpn4IwbnR0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWlbIEAAoJEK3tmne2etMp2/sQAI59WzdthbaHHAshtLwd7pvp zHtFpAwPaxqzclVFNn961Ck8kUb1LcU1PGt+oGdIL84S51U/c/Fhin5VkonxAcSx 38N45K1RCsBcD3ukUlb0zLQ7sS5hdT0exGXO7ko9Mv7KbzFjKeAUdXEICHeGcwb9 PX3t0qxlTfwuX7qQoNcXHlYYA44OScH8fTdw95Dzb85aPHyY73HyJtNzV6mbxuqh 4wIojS4IBLreXixesQJA7o0IN59PZqK1YO1ERHroiLGAxkvSVKda/RCjz9wz7go2 cv+kA1Km4tkUwFW75smy+F+PvKBahERn329oJm+NpXKJCGkGuEC/sKXDBWRHbQqL gl7gDLOLdaFASkvRDMa7RatXG0B38UHZxxcKpikNnawxzAzcIIviyWPGkidkrQKh MovoQtOf3XDfoJjSP0b+AWQBn5e5x7mdK++erxf/NSNUXL0mjfOkf9ttvpBVpZqp I+lV8o75kIwbk6/ry2bV3TBtiDIY4NTZIBCpjSt34z1/sMJFuj7S00ZWSNh6vrve rUkOxnMU4axs6wiEbk6KERN+kfm72J1eoVcRqAH6WzDXECb1fV4QiOJSx7bO+zfL MXH35QJqvbzsdAi8EjPSWE3K9lWX+/JKG1HvvbdWIm8D2oivhSlvgyDpLd3p/WR4 pO/1x+eamVpuncZ2pc+o =vKCM -----END PGP SIGNATURE----- --paVNrxrETVGsMUUct5R8fcBfpn4IwbnR0-- From nobody Tue Jan 12 18:27:36 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93301B2C06 for ; Tue, 12 Jan 2016 18:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdGzKudMSThX for ; Tue, 12 Jan 2016 18:27:28 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0E91B2C07 for ; Tue, 12 Jan 2016 18:27:25 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id p186so183910354qke.0 for ; Tue, 12 Jan 2016 18:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Eh6yF+W2xlGhieKUHsRX+bweGYMmCzMytFMCBZH2pyU=; b=RHOSFv7+l3MmOWt7Cktz/G0VjB8rPJvOb0CGj/i9lwhHpJebTNA0QoCeRoWJAa1lQV IVhJshdA+8t3m12w2dBw2nrST4nB4OJmUQyDSFvRntH6yeEzgQfgVIxxVX1TWd9dKm1S neLTdLgBmKk2qB4NgL6BHgO4+luxhA1KQIpCEd9kIhOugm+ux+4IGXvw+kAPB2cgIJ6J xwEHF6JkIJRMyMjXweGaDcsrS719eGpKCiAs0nJ6KQfjZApIKET5uP229H1vpANPUows qCV82zfpO7QAAuiDVbnSoefPVIcGyHTtTxw9H6wjrbBJEUnQ+cl7M68d8DgDzI2mdayg p6iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Eh6yF+W2xlGhieKUHsRX+bweGYMmCzMytFMCBZH2pyU=; b=ASa0JoV/7nLWMUVyQq2RmU/Eo9OQUUJoWCY65d0Ji75ZHYnE05x9y4zAA/6m5CFnNx BL6uGi39RhDi+KAzF2wxGjzuSxD/GB32AJF0wiivRPSPFc7q1wgjugFeespXZS9uE5E3 5DTTNHJW0G//Tn+/U06WqFI381Erc+1kG0Al9z27reyJsNemuspa2OCj1icvruFFFFIj lT8g9qDBeuagcWzC2QAM7mJJdOpaJU/bnI9H91VBUnWHf9sMTOlGI2HpVNjWKmU/tRMr fHRimgbsv9cwXO9LvGDHwB9CPe1eFnYz9LHKS5hWGPRzlUsNcQCro+01Ftuc09YE+eJA tuJg== X-Gm-Message-State: ALoCoQlgPcMZZmtBSX7o04nrXCOCDJLCRBq+mYkldsaLXkG0sZwooTzr/waJvCr/DqA1jA8dH1oboK7vCYqs+Qc/gyJkbB1wdQ== MIME-Version: 1.0 X-Received: by 10.55.27.164 with SMTP id m36mr32586668qkh.84.1452652045093; Tue, 12 Jan 2016 18:27:25 -0800 (PST) Received: by 10.140.102.9 with HTTP; Tue, 12 Jan 2016 18:27:25 -0800 (PST) In-Reply-To: <5695B204.2000507@zash.se> References: <5695B204.2000507@zash.se> Date: Tue, 12 Jan 2016 21:27:25 -0500 Message-ID: From: Shumon Huque To: Kim Alvefur Content-Type: multipart/alternative; boundary=001a114411e02150b005292de911 Archived-At: Cc: "" Subject: Re: [dane] DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 02:27:33 -0000 --001a114411e02150b005292de911 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 9:10 PM, Kim Alvefur wrote: > On 01/12/2016 11:21 PM, Shumon Huque wrote: > > On the "_smtp-client" label choice, > > That seems like it will cause confusion considering _xmpp-client is used > in the XMPP world to refer to where the end-users connect their user > agents to, so basically equivalent to _submission in email. And then > there's _xmpp-server for communication between servers. > Yeah, I'm aware of that. I think the XMPP community made an unfortunate choice in those names - I might have suggested "_xmpp-c2s" and "_xmpp-s2s" instead. As John Levine points out, the client service name choices are already all over the map in the current IANA service registry, so ... FWIW, I would suggest _smtp-out as a less confusing label. > The _smtp-client record was just an example we used in the draft. We weren't trying to impose a uniform convention for IANA client application labels here (probably not the right place to do so), but perhaps we can consider making a recommendation in the IANA Considerations section of the draft. The word "client" is a bit ambiguous whether it refers to a user agent > or a server in the process of connecting to another server. It would > help to be more explicit about which one of these are being referred to, > or if it applies to both. > In my opinion, it covers any entity acting as a client, so it covers both the cases you outline. I'm not sure we need to make a distinction in the draft. Client-DANE in the later context, enabling mutual authentication between > SMTP servers could be a nice improvement / complement to SPF & co. > Glad to hear it. That's one of the use cases that this draft had in mind. -- Shumon Huque --001a114411e02150b005292de911 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 12, 2016 at 9:10 PM, Kim Alvefur <zash@zash.se> wrote:
On 01/12/2016 11:21 PM, Sh= umon Huque wrote:
> On the "_smtp-client" label choice,

That seems like it will cause confusion considering _xmpp-client is = used
in the XMPP world to refer to where the end-users connect their user
agents to, so basically equivalent to _submission in email.=C2=A0 And then<= br> there's _xmpp-server for communication between servers.

Yeah, I'm aware of that. I think the XMPP communit= y made an=C2=A0
unfortunate choice in those names =C2=A0- I might= have suggested=C2=A0
"_xmpp-c2s" and "_xmpp-s2s&q= uot; instead.

As John Levine points out, the clien= t service name choices are already
all over the map in the curren= t IANA service registry, so ...

FWIW, I would suggest _smtp-out as a less confusing label.
=

The _smtp-client record was just an example we used in = the draft.
We weren't trying to impose a uniform convention f= or IANA client
application labels here (probably not the right pl= ace to do so), but=C2=A0
perhaps we can consider making a recomme= ndation in the IANA
Considerations section of the draft.

The word "client" is a bit ambiguous whether it refers to a user = agent
or a server in the process of connecting to another server. It would
help to be more explicit about which one of these are being referred to, or if it applies to both.

In my opinion= , it covers any entity acting as a client, so it covers both
the = cases you outline. I'm not sure we need to make a distinction in
<= div>the draft.

Client-DANE in the later context, enabling mutual authentication between SMTP servers could be a nice improvement / complement to SPF & co.
<= /blockquote>

Glad to hear it. That's one of the use = cases that this draft had in mind.

--=C2=A0
<= div>Shumon Huque

--001a114411e02150b005292de911-- From nobody Tue Jan 12 18:32:23 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAEA1B2C11 for ; Tue, 12 Jan 2016 18:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSu9yKalJGI4 for ; Tue, 12 Jan 2016 18:32:21 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F9D1B2C0F for ; Tue, 12 Jan 2016 18:32:20 -0800 (PST) Received: (qmail 45502 invoked from network); 13 Jan 2016 02:32:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=b1bd.5695b733.k1601; bh=wn/bgj5uu2p5n8wONh7Lxn5aPvhhk0NF5HxKzTuj/Yw=; b=ms9uyx9TCUv9IFqcCjCgdgVHKcJE86XbJaOSimMID9sw07gt1gxbyng1jnWRUdWNQrqyrHLkQjuXC7hKXlc3/2DmiKozfp+mIxRztKtyIC9NVyjpyw+FnVhN89zoZU8K8PoWeIniSCwdZESulW2g7MELDwCnLriXS5fNerGVBpEe4LWoNvNLoIc3Gh9fH5u4+mVrCzMqQRGYUKbzQpJUoJ22P8x14b9jjxAjftZfuo9Un/0EcXrorgfhgIeteEhZ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=b1bd.5695b733.k1601; bh=wn/bgj5uu2p5n8wONh7Lxn5aPvhhk0NF5HxKzTuj/Yw=; b=Nq1lHnUNL75YhcWJjaD8WDMMhw/ulbuPEmGO05cLS0cB4qXXKnkl0oU5Gn0GDKFUfck8abJgfhGupuZzGLQE1dJMyFpm22vbLmXEdpELaAH8hvDstzXUW8MRmjpSUjX4RM3jyHVaSYSfySMy79HwDcNdwZ0G6bfVapEmVcbbHdGn7s5Ys9YmJ/iz37DiMvD0xusZOcOjJdNu0xLz3VhKrXkPwNwBS9w+Zd+93z0NJUGFwOP++t8Rs4TxKbfP4VdN Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 13 Jan 2016 02:32:19 -0000 Date: 12 Jan 2016 21:32:19 -0500 Message-ID: From: "John R Levine" To: "Shumon Huque" In-Reply-To: References: <20160113013152.54184.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "" Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 02:32:22 -0000 >> In the DNS, service names only appear as subnames of transport names. >> So one possibility would be to register smtp-client as a service name, >> so the DNS label would be _smtp-client._tcp.whatever.example. > > I would say "only appear *today* under transport names", but this isn't a > hard and fast requirement. ... > We should feel free to construct TLSA owner names in a form that makes > sense for the specific application. They've appeared under transport names for the past 15 years, which means that people have expectations about how they're used which I would not casually ignore. There are a lot of other prefixed names floating around the DNS. If someone attempted to use a client name like _spf or _sip or _domainkey or _dmarc or _adsp or _vouch they and their users would experience an eternity of pain from name collisions. > For the purposes of this draft, including a transport label might make > sense if we expected clients to have distinct transport protocol > specific authentication credentials for the same application. This seems > unlikely to me. It has very little to do with distinct transport protocols, and everything to do with avoiding name collisions. Nobody runs POP or IMAP over UDP, but the SRV names are still _pop3._tcp and _imap._tcp. If your names are subnames of _tcp or another transport, you know that the only names you can collide with are ones in the IANA services list, and you can easily register yours to tell people about them. If they aren't, they could collide with anything. Dave Crocker has been working on a registry for general prefixed names, but it's not likely to exist any time soon. > See Viktor's previous note about why we excluded a _client label. I saw it, and I have to say it strikes me as penny wise and pound foolish. You're getting a tiny simplification in code that for the most part hasn't even been written yet, at the cost of having to deal with potential collisions with every future use of prefixed names. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue Jan 12 18:45:01 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057171B2C21 for ; Tue, 12 Jan 2016 18:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6tglCFiZEmY for ; Tue, 12 Jan 2016 18:44:59 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BCF01B2C1E for ; Tue, 12 Jan 2016 18:44:59 -0800 (PST) Received: from [10.2.190.13] (unknown [38.86.167.115]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 3EC33284809 for ; Wed, 13 Jan 2016 02:44:58 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 12 Jan 2016 21:44:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160113013152.54184.qmail@ary.lan> To: dane@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 02:45:01 -0000 >=20 > On Jan 12, 2016, at 9:32 PM, John R Levine wrote: >=20 > They've appeared under transport names for the past 15 years, which = means that people have expectations about how they're used which I would = not casually ignore. And yet client identities are not really transport-specific. >=20 > There are a lot of other prefixed names floating around the DNS. If = someone attempted to use a client name like _spf or _sip or _domainkey = or _dmarc or _adsp or _vouch they and their users would experience an = eternity of pain from name collisions. Only if there are TLSA records for those names. --=20 Viktor. From nobody Tue Jan 12 18:52:40 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260FD1B2C48 for ; Tue, 12 Jan 2016 18:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiqYtfEpl7Hc for ; Tue, 12 Jan 2016 18:52:37 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD201B2C47 for ; Tue, 12 Jan 2016 18:52:37 -0800 (PST) Received: by mail-qg0-x22c.google.com with SMTP id 6so366570344qgy.1 for ; Tue, 12 Jan 2016 18:52:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=DdXv5fqJVEL2rgyC+XOjXIk8QUwtNuZECIebLOjNkBk=; b=cLHH06o0BpOIBFDfrckDNvlSlxJgWU6N+huQodK4ik/q5cXHlFj/ew52hO5+BQNP24 EgJJPU3e8vJtSUUxfrOK9Rlf27TthssemmCTTgBhCxFw3n7NbF+PT+rztGS/tbSxhorU QdOIGUYJCWr6+PvU4X7k2qpsCJbI2R3qsxdepDXUkhzdeDdRA64/5ZxU5kwjjgSr2SLx X9eESCo0YbZAvdUW7G7AU34f6NY8qDs2KbU2awOn4oqOn3j6gI+QAh9zwWSGQsulMFEJ SMUeLuTQ3X2kH2Yj+IsslS82H1AmncmHnQk5GiIcELk/vovXMJD1q9+9SPDY04x0k4uF zAGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=DdXv5fqJVEL2rgyC+XOjXIk8QUwtNuZECIebLOjNkBk=; b=UmLjDTGKAVgLosx4AFatQL/hfsP9NCNvfK1VJGKFEz8i8kAfkDz/SD831chZGEsV3m guKPrVjEq1/c0mWwfhH+DwAoa8VaJq80EEUVitbw2zO5RKWdTuvKhQlYn0suvmoebqRp RIthqohPzrw8Mje4R/ZB/k6nF7POZmVkRU+Sk/MfpfW7Z0gNRbNOrxB41TuB5PN9IJ7z Iqpdmy9oxMQRH/3U1PVPsuF561FE285uXVVlEIsOjFS+9pgm8/zR3upwzVniJBpQ4NWh qMo/BnvN0oQPhm6RsZwDWQ/3Tj7HIUXODnoJPQpWf8NkVU2VdLL4sXR1ueQmB6e9V/ut jJQg== X-Gm-Message-State: ALoCoQlIILWzu0R62QyaCZpcsbtjGxRlkEVD0O5a/68lJ+X4oikKtkFVWRl/tL11RjICEOli8Z28O36fZGjL8oqPJO35qPgQaQ== MIME-Version: 1.0 X-Received: by 10.140.175.7 with SMTP id v7mr7821123qhv.103.1452653556478; Tue, 12 Jan 2016 18:52:36 -0800 (PST) Received: by 10.140.102.9 with HTTP; Tue, 12 Jan 2016 18:52:36 -0800 (PST) In-Reply-To: References: <20160113013152.54184.qmail@ary.lan> Date: Tue, 12 Jan 2016 21:52:36 -0500 Message-ID: From: Shumon Huque To: "" Content-Type: multipart/alternative; boundary=001a113a29ea37395805292e4315 Archived-At: Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 02:52:39 -0000 --001a113a29ea37395805292e4315 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 9:44 PM, Viktor Dukhovni wrote: > > > > On Jan 12, 2016, at 9:32 PM, John R Levine wrote: > > > > They've appeared under transport names for the past 15 years, which > means that people have expectations about how they're used which I would > not casually ignore. > > And yet client identities are not really transport-specific. > > > > > There are a lot of other prefixed names floating around the DNS. If > someone attempted to use a client name like _spf or _sip or _domainkey or > _dmarc or _adsp or _vouch they and their users would experience an eternity > of pain from name collisions. > > Only if there are TLSA records for those names. > Right. Also recall that the proposed owner name is: _service.[client-domain-name]. So a zone operator can define client domain name structures in a way that can address any namespace collision issues they wish to avoid. Presumably, an "_spf.device1.dept.example.com" TXT record would be about SPF rules pertaining to device1.dept.example.com, so there is likely not an issue with it co-existing with a client TLSA record at that same name. -- Shumon Huque --001a113a29ea37395805292e4315 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 12, 2016 at 9:44 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
&= gt;
> On Jan 12, 2016, at 9:32 PM, John R Levine <johnl@taugh.com> wrote:
>
> They've appeared under transport names for the past 15 years, whic= h means that people have expectations about how they're used which I wo= uld not casually ignore.

And yet client identities are not really transport-specific.

>
> There are a lot of other prefixed names floating around the DNS.=C2=A0= If someone attempted to use a client name like _spf or _sip or _domainkey = or _dmarc or _adsp or _vouch they and their users would experience an etern= ity of pain from name collisions.

Only if there are TLSA records for those names.

Right.=C2=A0

Also recall that the = proposed owner name is: _service.[client-domain-name].
So a zone = operator can define client domain name structures in a way that
c= an address any namespace collision issues they wish to avoid. Presumably,
an "_spf.devi= ce1.dept.example.com" TXT record would be about SPF rules
pertaining to device1.dept.ex= ample.com, so there is likely not an issue with
it co-existin= g with a client TLSA record at that same name.

--= =C2=A0
Shumon Huque

--001a113a29ea37395805292e4315-- From nobody Tue Jan 12 21:30:13 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507321B2D8E for ; Tue, 12 Jan 2016 21:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04_54hAqRz0m for ; Tue, 12 Jan 2016 21:30:11 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0453E1B2D8D for ; Tue, 12 Jan 2016 21:30:10 -0800 (PST) Received: (qmail 69636 invoked from network); 13 Jan 2016 05:30:09 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 13 Jan 2016 05:30:09 -0000 Date: 13 Jan 2016 05:29:47 -0000 Message-ID: <20160113052947.54721.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 05:30:12 -0000 In article you write: >> >> On Jan 12, 2016, at 9:32 PM, John R Levine wrote: >> >> They've appeared under transport names for the past 15 years, which means that people have expectations >about how they're used which I would not casually ignore. > >And yet client identities are not really transport-specific. Hi, Viktor. As I said in the message to which you just responded, two paragraphs below the one you quoted: It has very little to do with distinct transport protocols, and everything to do with avoiding name collisions. Nobody runs POP or IMAP over UDP, but the SRV names are still _pop3._tcp and _imap._tcp. >> There are a lot of other prefixed names floating around the DNS. If someone attempted to use a client >name like _spf or _sip or _domainkey or _dmarc or _adsp or _vouch they and their users would experience >an eternity of pain from name collisions. > >Only if there are TLSA records for those names. Well, OK. How much do you want to bet that there won't be, ever, for those names and for anything else for which someone uses a prefixed name? We can easily avoid this problem now, or painfully sort of work around it in the future. I don't see that as a hard choice. R's, John From nobody Tue Jan 12 21:41:34 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56771B2DA9 for ; Tue, 12 Jan 2016 21:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FldTGd_Q_Wev for ; Tue, 12 Jan 2016 21:41:33 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBCEC1B2DA8 for ; Tue, 12 Jan 2016 21:41:32 -0800 (PST) Received: (qmail 71266 invoked from network); 13 Jan 2016 05:41:31 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 13 Jan 2016 05:41:31 -0000 Date: 13 Jan 2016 05:41:09 -0000 Message-ID: <20160113054109.54762.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 05:41:33 -0000 >Also recall that the proposed owner name is: _service.[client-domain-name]. >So a zone operator can define client domain name structures in a way that >can address any namespace collision issues they wish to avoid. Presumably, >an "_spf.device1.dept.example.com" TXT record would be about SPF rules >pertaining to device1.dept.example.com, so there is likely not an issue with >it co-existing with a client TLSA record at that same name. I admire the faith you have in DNS operators, but find it baffling. For a lot of the ones I know, their heads would explode at having to mix TXT SPF records for the incoming mail and TLSA for the outgoing mail at the same names in the same zone files. They'd probably try to kludge it with CNAME and break everything. We already have a managed service namespace, which you can use with trivial ease as _._client._tcp.. But I'm hearing no, to save 12 characters in the domain name, and 12 lines of code in the clients, we'll tell people to make up random prefixed names and when the collisions inevitably happen, it won't be our problem. R's, John From nobody Tue Jan 12 21:53:26 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662B61A0390 for ; Tue, 12 Jan 2016 21:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pk7ltCMsRjVp for ; Tue, 12 Jan 2016 21:53:23 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C19C1A0389 for ; Tue, 12 Jan 2016 21:53:23 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9919E284AED; Wed, 13 Jan 2016 05:53:22 +0000 (UTC) Date: Wed, 13 Jan 2016 05:53:22 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160113055322.GJ18704@mournblade.imrryr.org> References: <20160113052947.54721.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160113052947.54721.qmail@ary.lan> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 05:53:25 -0000 On Wed, Jan 13, 2016 at 05:29:47AM -0000, John Levine wrote: > It has very little to do with distinct transport protocols, and > everything to do with avoiding name collisions. Nobody runs POP or > IMAP over UDP, but the SRV names are still _pop3._tcp and _imap._tcp. That's because SRV records are a generic (somewhat over-engineered) construction, and we're stuck with separate: _kerberos._udp.realm.example. IN SRV 100 0 88 kdc1.example. _kerberos._tcp.realm.example. IN SRV 100 0 88 kdc1.example. with the only benefit of this separation being the ability to discover that a given realm has no UDP-based or has no TCP-based KDCs. None of this is especially relevant for clients. So we can keep the client TLSA record query name simple with: ; TLSA RRtype sufficient to distinguish this from all ; other uses of the name, and any collisions with server ; names with look like _port._proto.server.example. ; _application.box.example. IN TLSA 3 1 1 ... or we inject additional labels, making the name further removed from identifying a DANE application at a given DNS node: _application._tcp._client._dane.box.example. IN TLSA 3 1 1 ... because _client might be used in non-dane contexts, and we want to distinguish TCP from UDP, ... But what's the real benefit to all this? We're publishing TLSA records for "application" on "box.example", is any of the other baggage really helpful? With enough such labels, we don't need a TLSA RRtype, just use TXT, and encode the data in JSON. _application._tcp._client._tlsa._dane.box.example. IN TXT "{usage=3, selector=1, mtype=1, data=...}" The point I'm trying to make is that given the base domain, an application-specific initial _label, an the TLSA RRtype, we have all the essential distinguishing identifiers and anything else is baggage that needs justification. James makes a plausible point about _client as a way to carve out a zone for clients, but because unlike SMIME/A or OPENPGPKEY the base domain is here typically not a zone apex, but rather a specific host, carving out a new zone under each host scales poorly. And this takes away the simplicity of an identity mapping between the query domain and the corresponding SRV-ID. So I while I am sympathetic to his argument, I don't think it holds up in the end. If we start injecting _proto, and various additional labels, I am pretty we'd be overdoing the design. There has be a good reason for these, beyond superficial similarity to server use-cases that are not actually analogous. -- Viktor. From nobody Tue Jan 12 21:57:10 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC7A1A079D for ; Tue, 12 Jan 2016 21:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSeOts7hs3pp for ; Tue, 12 Jan 2016 21:57:07 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57AEA1A03A5 for ; Tue, 12 Jan 2016 21:57:07 -0800 (PST) Received: (qmail 73238 invoked from network); 13 Jan 2016 05:57:06 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 13 Jan 2016 05:57:06 -0000 Date: 13 Jan 2016 05:56:44 -0000 Message-ID: <20160113055644.54843.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <5695B204.2000507@zash.se> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 05:57:08 -0000 >The word "client" is a bit ambiguous whether it refers to a user agent >or a server in the process of connecting to another server. It would >help to be more explicit about which one of these are being referred to, >or if it applies to both. That part shouldn't be hard -- in any TCP session, one end is listening and the other connects to it. By definition the listening end is the server and the connecting end is the client. R's, John From nobody Tue Jan 12 22:01:07 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4640F1A1A56 for ; Tue, 12 Jan 2016 22:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cdHF6nN5Wwz for ; Tue, 12 Jan 2016 22:01:03 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ABC41A1A52 for ; Tue, 12 Jan 2016 22:01:03 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8ADC0284AED; Wed, 13 Jan 2016 06:01:02 +0000 (UTC) Date: Wed, 13 Jan 2016 06:01:02 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160113060102.GK18704@mournblade.imrryr.org> References: <20160113054109.54762.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160113054109.54762.qmail@ary.lan> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 06:01:05 -0000 On Wed, Jan 13, 2016 at 05:41:09AM -0000, John Levine wrote: > I admire the faith you have in DNS operators, but find it baffling. > For a lot of the ones I know, their heads would explode at having to > mix TXT SPF records for the incoming mail and TLSA for the outgoing > mail at the same names in the same zone files. They'd probably try > to kludge it with CNAME and break everything. The TXT SPF records will be a the zone apex. The _smtp-client (or just _smtp) prefix will be for each client MTA! There's little opportunity for collisions, except at domains with just a single node at the zone apex holding all the records and not even using a hostname under the domain for outgoing connections as a mail client. If that domain operator needs CNAMES for the client TLSA record (to where???) they can create a suitable sub-domain for the client name. ; zone apex MX record example.com. IN MX 0 smtp.example.com. ; zone apex SPF record _spf.example.com. IN TXT ... ; MX host A record smtp.example.com. IN A 192.0.2.1[ ; SMTP client _smtp.smtp.example.com. IN TLSA 3 1 1 ... ; SMTP server _25._tcp.smtp.example.com. IN CNAME _smtp.smtp.eample.com. > We already have a managed service namespace, which you can use with > trivial ease as _._client._tcp.. But I'm hearing no, > to save 12 characters in the domain name, and 12 lines of code in the > clients, we'll tell people to make up random prefixed names and when > the collisions inevitably happen, it won't be our problem. It is zero extra lines of code, but what do these extra bytes buy us? -- Viktor. From nobody Tue Jan 12 22:42:47 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48221A21B2 for ; Tue, 12 Jan 2016 22:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNMABJKLzWEx for ; Tue, 12 Jan 2016 22:42:44 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD771A1E0F for ; Tue, 12 Jan 2016 22:42:44 -0800 (PST) Received: (qmail 78347 invoked from network); 13 Jan 2016 06:42:43 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 13 Jan 2016 06:42:43 -0000 Date: 13 Jan 2016 06:42:21 -0000 Message-ID: <20160113064221.54965.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20160113055322.GJ18704@mournblade.imrryr.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 06:42:45 -0000 >> It has very little to do with distinct transport protocols, and >> everything to do with avoiding name collisions. Nobody runs POP or >> IMAP over UDP, but the SRV names are still _pop3._tcp and _imap._tcp. >with the only benefit of this separation ... The benefit of putting the service name behind a transport name is to put the service names in a separate namespace where they don't collide with anything else and they're already managed by IANA. >or we inject additional labels, making the name further removed >from identifying a DANE application at a given DNS node: > > _application._tcp._client._dane.box.example. IN TLSA 3 1 1 ... > >because _client might be used in non-dane contexts, No, it's _application._client._tcp.box.example, and it's because someone might use _application in other contexts. > and we want to distinguish TCP from UDP, Not really. > ... But what's the real benefit to all this? You're avoiding name collisions down the road. >James makes a plausible point about _client as a way to carve out >a zone for clients, but because unlike SMIME/A or OPENPGPKEY the >base domain is here typically not a zone apex, but rather a specific >host, carving out a new zone under each host scales poorly. Surely we don't have to review the difference between name components and zone cuts. Nobody has proposed putting a new zone under each host name. R's, John From nobody Tue Jan 12 23:04:45 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D88C1A8A8F for ; Tue, 12 Jan 2016 23:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7k8M7WqhbaA for ; Tue, 12 Jan 2016 23:04:41 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEBC91A894E for ; Tue, 12 Jan 2016 23:04:41 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A7523284AED; Wed, 13 Jan 2016 07:04:40 +0000 (UTC) Date: Wed, 13 Jan 2016 07:04:40 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160113070440.GL18704@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160113064221.54965.qmail@ary.lan> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 07:04:43 -0000 On Wed, Jan 13, 2016 at 06:42:21AM -0000, John Levine wrote: > > ... But what's the real benefit to all this? > > You're avoiding name collisions down the road. Please don't get me wrong, I'm not zealous about this, just don't yet see any value in the additional labels, and surely we should add them for a good reason. I would expect the RRtype to provide all the collision avoidance that's required. Plus the fact that these are intended to be host-specific records, while, the various proposed example collisions are generally published at the parent domain of the various hosts. If we have to insert "_client" and that's the WG consensus, fine, just extra bits on the wire. As for "_tcp", that is really just excess baggage. Once we move move away from port numbers to application names the transport protocol to disambiguate numeric ports really does not seem at all helpful. Anyone voting for application OIDs to avoid collisions? The OID space is plausibly in better shape than the flat IANA service name registry... > >James makes a plausible point about _client as a way to carve out > >a zone for clients, but because unlike SMIME/A or OPENPGPKEY the > >base domain is here typically not a zone apex, but rather a specific > >host, carving out a new zone under each host scales poorly. > > Surely we don't have to review the difference between name components > and zone cuts. Nobody has proposed putting a new zone under each host > name. I guess James is "nobody". :-) On Tue, Jan 12, 2016 at 03:05:51PM -0500, James Cloos wrote: > > For draft-huque-dane-client-cert I'd still prefer RR names like: > > _smtp._client.example > > for the cert provided by an smtp client which HELO/EHLOs as example. > And similarly for other protocols. Rather than things like _smtp-client. > > Putting all of the client TLSAs under a single label allows (but > obviously does not require) them to be in their own zone. -- Viktor. From nobody Wed Jan 13 06:41:20 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8641B2E5F for ; Wed, 13 Jan 2016 06:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B79yOYCSxeMV for ; Wed, 13 Jan 2016 06:41:17 -0800 (PST) Received: from mail-oi0-x263.google.com (mail-oi0-x263.google.com [IPv6:2607:f8b0:4003:c06::263]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E021B2E40 for ; Wed, 13 Jan 2016 06:41:17 -0800 (PST) Received: by mail-oi0-x263.google.com with SMTP id w75so6591143oie.0 for ; Wed, 13 Jan 2016 06:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language:user-agent :content-type:content-id:content-transfer-encoding:mime-version; bh=GwlHJ17hb423REhnjl54KvV022xfRyu2fM1JljSdbVE=; b=m3fbmbozS3TLKnxTL3FB3qU7hmVRF4sW1xgNCZqC4H/TnY9dzC5kJsxRSViRJt8XFN yJb35x8qjWj1AwueV2EItmKC3+bvIkpZ+5rRhj8UTOXVJaDQes2BpD5totOfmsgtLWeg hkJVDNnOutrqkfnBcI+erC+HDLQCkgqijcRc3uICdp4EmfTNwifo5/NrNBqT14K42l+F LnYBVZXvj0JLTLDYHgdaKLxQA0VI2qBIGn+0uMWfj1LrAbb9YJyko2CTqOs5i2o53UaC ragCT7BMZn/YonOuSDHyWC6f42iWbZIKaFVi28ayp1NUAXGFiktnWik8YmiaKGPvTiaJ WJOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :user-agent:content-type:content-id:content-transfer-encoding :mime-version; bh=GwlHJ17hb423REhnjl54KvV022xfRyu2fM1JljSdbVE=; b=OgE1ZBSKtFudlHDRQPzjwppa6flqIaFLftqT8lrss+Bli3Gc2DOkAgWsozcN4RYs4s mM+lV6Q4GrMRMgeWf/lz/L3x8uSPtnJ/pNT1UQY5kndXHAqJ6uOyl8Ioi0Tusnib6krI ChXicgCmIANKcGq7QNV7K85EpbcQeglPzYt256DFWLtHt2uicfIWXIYg64IHTmIXrSOs AyqW2/4F858ey0dUC5+lKpnUtBzSqIm7IqGdREtdDQeYObk5J9VGTmd5B8vH0GPGwst+ i6kcT9FkwxVaYalCmNTRZFDWcXY63myhhb129Hqx8pSa2RiyjiUibisxnm+5o0hoW7Jm k1Hw== X-Gm-Message-State: ALoCoQn94vjWL0MoIrIZEoTe90D2xFEjt+jdqTDHnkYenyKla+LlbtsT6nFM0HpMm/6wWZ7S6Pdm/DbUNbB6rmqWL6NNawRTv9FNW8yTuUKjxwhUzdrET5I= X-Received: by 10.140.29.131 with SMTP id b3mr175558961qgb.50.1452696076986; Wed, 13 Jan 2016 06:41:16 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id y16sm202946qka.6.2016.01.13.06.41.16 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 13 Jan 2016 06:41:16 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u0DEfGEV026498 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Jan 2016 09:41:16 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 13 Jan 2016 09:41:16 -0500 From: "Wiley, Glen" To: "dane@ietf.org" Thread-Topic: [dane] namespace management, DANE Client Authentication draft updated Thread-Index: AQHRTdCr+mcGMuDZKEymf+VKPliTA575hVyA Date: Wed, 13 Jan 2016 14:41:15 +0000 Message-ID: References: <20160113064221.54965.qmail@ary.lan> <20160113070440.GL18704@mournblade.imrryr.org> In-Reply-To: <20160113070440.GL18704@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <17FA6F2298621C409B1023BD49B41417@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 14:41:19 -0000 On 1/13/16, 2:04 AM, "Viktor Dukhovni" wrote: >On Wed, Jan 13, 2016 at 06:42:21AM -0000, John Levine wrote: > >> > ... But what's the real benefit to all this? >>=20 >> You're avoiding name collisions down the road. > >Please don't get me wrong, I'm not zealous about this, just don't >yet see any value in the additional labels, and surely we should >add them for a good reason. I would expect the RRtype to provide >all the collision avoidance that's required. Plus the fact that >these are intended to be host-specific records, while, the various >proposed example collisions are generally published at the parent >domain of the various hosts. RRtype is sufficient for collision avoidance, I don=B9t think we gain any practical benefit by adding the other labels. From nobody Wed Jan 13 06:51:07 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580C71B2E71 for ; Wed, 13 Jan 2016 06:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFiujF1mZkDi for ; Wed, 13 Jan 2016 06:51:04 -0800 (PST) Received: from mail-oi0-x263.google.com (mail-oi0-x263.google.com [IPv6:2607:f8b0:4003:c06::263]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF961B2E66 for ; Wed, 13 Jan 2016 06:51:04 -0800 (PST) Received: by mail-oi0-x263.google.com with SMTP id j3so9618575oig.2 for ; Wed, 13 Jan 2016 06:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language:user-agent :content-type:content-id:content-transfer-encoding:mime-version; bh=0jY6aTg4RWm7fBiWseLCM8lhmLzCeMCYPfZN2oCiG8I=; b=ffos6B5jgQ9t//uX6b1AS+oQA95T+H5PR1sMYP1bfTRmichm2N+hWNlBu4LLKup4OL aKmirVz3Vs+dI05iZ2DXu+zRoZm2peqv7TxqldAMV0JOre53HHylkem5mpsFHt5Dvga6 hZqsMqGIdYC4SJXOWcP/2rK/UWJbs7NBo0imWpbQmQ/ZzaLmpbB1EIXogAeRsSL5e+H2 G+kXAc+3JHqhEVptOMC9WsNwojdK+GjLCx2l0Ddi/BJC3r4idbecuO8HY97BZRYMOuee Pr2besehv+JWomf4caQ32F1D+ak6y5DvxfQ0/0fcqdCiXAApDQ/+5CodCuUfcCb0/s71 1dRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :user-agent:content-type:content-id:content-transfer-encoding :mime-version; bh=0jY6aTg4RWm7fBiWseLCM8lhmLzCeMCYPfZN2oCiG8I=; b=GYlLPoiPhwb7jJXwDdydp6nV6B1T5FgmqhvdZzFcop65dEDtiHsz5BeFalTNZpi3Z8 ZP+WbkaOL+la4FLAkWruKQVhN/si3WPO08Hm+UdGMO96HxHD+Ia3Y2wJVTur/bOvOyaJ 4Huort2R3BclVcnlZnXvN4Pcxcdlc13nckINlHJ9NyAcuyH4F41DM4vcfK1Z1VKYMOb1 LMTBfDjiP25iYDdwrXeOCpSPJJi5SOPnBduMfZRKYaQnD38VN9dbL7HAmFzdamFuqPgV 0IJntrf6AddIvkCYCSwCjKwQspbK1vByBryceCSRFnryVaxMYJ70dO3oe8PT63n+jPSd TgLA== X-Gm-Message-State: ALoCoQmP8MvYfAfkYB4+FygcT4NVAKYYfwVPIXvYPLqR+GKSU6/Th6tJEQfd+0MKFX4fVmjKtHT9WkRN1hnuUMdEDbYeSegXueQUWNgUc/H2oR/RXgMgXyk= X-Received: by 10.140.249.2 with SMTP id u2mr187075380qhc.53.1452696663926; Wed, 13 Jan 2016 06:51:03 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id y135sm222802qky.9.2016.01.13.06.51.03 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 13 Jan 2016 06:51:03 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u0DEp3tU027686 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Jan 2016 09:51:03 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 13 Jan 2016 09:51:03 -0500 From: "Wiley, Glen" To: "dane@ietf.org" Thread-Topic: [dane] any statistics of deployment available? Thread-Index: AdFIeslBxynRdYetRzmHZNYubTMahgAMtMUAAAyqfgABTGYggA== Date: Wed, 13 Jan 2016 14:51:01 +0000 Message-ID: References: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> <20160106131105.GC14398@sys4.de> <20160106191346.GF18704@mournblade.imrryr.org> In-Reply-To: <20160106191346.GF18704@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <2CA6877A5995774EA92F48B722224569@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dane] any statistics of deployment available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 14:51:06 -0000 Comparable stats from SecSpider for a survey of 1056097 zones at http://secspider.verisignlabs.com/stats.html DANE Summary 16065 DANE enabled zones with TLSA records 65 PKIX based Trust Anchor TLSA records (Cert Usage 0) 541 PKIX based End Entity TLSA records (Cert Usage 1) 266 DANE based Trust Anchor TLSA records (Cert Usage 2) 5791 DANE based End Entity TLSA records (Cert Usage 3) 425 Zones have deployed TLSA for Secure SMTP (Port 465) 124 Zones have deployed TLSA for Secure POP3 (Port 995) 503 Zones have deployed TLSA for SMTP with STARTTLS (Port 587) 24 Zones have deployed TLSA for Alternate SMTP (Port 2525) 3024 Zones have deployed TLSA for HTTPS (Port 443) 1996 Zones have deployed TLSA for SMTP (Port 25) 72 Zones have deployed TLSA for POP3 (Port 110) 294 Zones have deployed TLSA for Secure IMAP (Port 993) 201 Zones have deployed TLSA for IMAP (Port 143) On 1/6/16, 2:13 PM, "Viktor Dukhovni" wrote: >On Wed, Jan 06, 2016 at 02:11:06PM +0100, Patrick Ben Koetter wrote: > >> > Is there any statistics or a site that I can find regarding the >>deployment of DANE over the internet? >>=20 >> We did a complete IPv4 scan two weeks ago. AFAIK Viktor is about to >>analyse >> the data. But I don't know when he will be able to present results. > >I don't have the scan data yet, but I will look. At present my >survey has found just over 10400 domains with working DANE TLSA >records for SMTP, a majority of these are from a three hosting >providers: > > 5146 udmedia.de > 1199 mx.transip.email > 933 mx.nederhost.net > >Based on email discussion with the top two, it seems I've captured >around 10% of their actual deployed numbers, so the number of SMTP >domains is around 100k, with over 95% of these hosted by the above >providers. > >The number of SMTP DANE domains that are "large enough" by whatever >criteria Gmail uses to list a domain in its email transparency >report stands at 30 (was 24 in early October). > >We're still early in the deployment process, but DANE support in >OpenSSL will be available soon, which I think will help. Hard to >adopt a standard with no "running code". > >Two of the six DANE patches scheduled for review have been reviewed >and are now part of OpenSSL 1.1.0-dev, the rest will join them soon >I hope. > >--=20 > Viktor. > >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From nobody Wed Jan 13 08:33:00 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2581B2C88 for ; Wed, 13 Jan 2016 08:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUFzZ5g_0COn for ; Wed, 13 Jan 2016 08:32:58 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928A71B2C87 for ; Wed, 13 Jan 2016 08:32:58 -0800 (PST) Received: (qmail 2981 invoked from network); 13 Jan 2016 16:32:57 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 13 Jan 2016 16:32:57 -0000 Date: 13 Jan 2016 16:32:35 -0000 Message-ID: <20160113163235.65470.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 16:32:59 -0000 >RRtype is sufficient for collision avoidance, I don¹t think we gain >any practical benefit by adding the other labels. Oh, OK. How about inventing a TLSACLIENT RRtype and use no prefix labels at all? I don't think that's a very good idea, but I'd be interested to hear if other people agree, and if so, why. R's, John From nobody Wed Jan 13 10:14:32 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAE31B3061 for ; Wed, 13 Jan 2016 10:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adadLZBYeYt2 for ; Wed, 13 Jan 2016 10:14:29 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743CF1B3065 for ; Wed, 13 Jan 2016 10:14:29 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 57C82284E5C; Wed, 13 Jan 2016 18:14:28 +0000 (UTC) Date: Wed, 13 Jan 2016 18:14:28 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160113181428.GN18704@mournblade.imrryr.org> References: <20160113163235.65470.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160113163235.65470.qmail@ary.lan> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 18:14:30 -0000 On Wed, Jan 13, 2016 at 04:32:35PM -0000, John Levine wrote: > >RRtype is sufficient for collision avoidance, I don?t think we gain > >any practical benefit by adding the other labels. > > Oh, OK. How about inventing a TLSACLIENT RRtype and use no prefix > labels at all? > > I don't think that's a very good idea, but I'd be interested to hear > if other people agree, and if so, why. Well, we still a service-specific prefix, because we're signalling the public keys for clients of a particular service on a particular network node. Clients for different services may well have different certs/keys. The main argument that supports more than just a single service prefix (if those are actually prone to collisions with various other common prefixes like _spf, _dkim, ...) is that CNAMES are quite useful with TLSA RRs when the payload is a trust-anchor digest that should just be and managed in one place. Thus if we really believe that there's a collision problem on just the prefixed names, so that potential application client prefixes (of the form suggested in the draft) already have existing non-TLSA records, then it would be better to have just one additional label: _service._client.node.example. IN TLSA ... So that one can create CNAME records: _service._client.node.example. IN CNAME _dane.example. I still don't see any use for _tcp/_udp in there. -- Viktor. From nobody Wed Jan 13 10:23:46 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817B81B307D for ; Wed, 13 Jan 2016 10:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQiA0M8Flmc7 for ; Wed, 13 Jan 2016 10:23:43 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015651B307B for ; Wed, 13 Jan 2016 10:23:42 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 12155284E5C; Wed, 13 Jan 2016 18:23:42 +0000 (UTC) Date: Wed, 13 Jan 2016 18:23:42 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160113182341.GO18704@mournblade.imrryr.org> References: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> <20160106131105.GC14398@sys4.de> <20160106191346.GF18704@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.24 (2015-08-30) Archived-At: Subject: Re: [dane] any statistics of deployment available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 18:23:44 -0000 On Wed, Jan 13, 2016 at 02:51:01PM +0000, Wiley, Glen wrote: > Comparable stats from SecSpider for a survey of 1056097 zones at > http://secspider.verisignlabs.com/stats.html > > DANE Summary > 16065 DANE enabled zones with TLSA records > > 65 PKIX based Trust Anchor TLSA records (Cert Usage 0) > 541 PKIX based End Entity TLSA records (Cert Usage 1) > 266 DANE based Trust Anchor TLSA records (Cert Usage 2) > 5791 DANE based End Entity TLSA records (Cert Usage 3) 6663 These numbers don't add up to 16065 (their sum is 6663). Surely there are not many zones (a majority?) with TLSA records with usage other than 0/1/2/3? > 425 Zones have deployed TLSA for Secure SMTP (Port 465) > 124 Zones have deployed TLSA for Secure POP3 (Port 995) > 503 Zones have deployed TLSA for SMTP with STARTTLS (Port 587) > 24 Zones have deployed TLSA for Alternate SMTP (Port 2525) > 3024 Zones have deployed TLSA for HTTPS (Port 443) > 1996 Zones have deployed TLSA for SMTP (Port 25) > 72 Zones have deployed TLSA for POP3 (Port 110) > 294 Zones have deployed TLSA for Secure IMAP (Port 993) > 201 Zones have deployed TLSA for IMAP (Port 143) These numbers also add to 6663. Where did the 16k number come from? I have found 10.7k domains for DANE SMTP (port 25) in a sample of 4.8M domains of which 120k have DNSSEC for both the domain MX RRset and for at least one best preference MX host and so can start publishing TLSA records. -- Viktor. From nobody Wed Jan 13 12:06:43 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02021B31B8 for ; Wed, 13 Jan 2016 12:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP4RPVlRmZ2w for ; Wed, 13 Jan 2016 12:06:41 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9411B1B31B7 for ; Wed, 13 Jan 2016 12:06:40 -0800 (PST) Received: (qmail 34966 invoked from network); 13 Jan 2016 20:06:39 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 13 Jan 2016 20:06:39 -0000 Date: 13 Jan 2016 20:06:17 -0000 Message-ID: <20160113200617.65983.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20160113181428.GN18704@mournblade.imrryr.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 20:06:42 -0000 > _service._client.node.example. IN TLSA ... Ah, we're getting closer. >I still don't see any use for _tcp/_udp in there. RFC 6698 has _tcp _udp and _sctp protocols as part of the names for TLSA. It seems rather odd to have the protocol name for the server certificate but not for the client. R's, John PS: In case it's not clear, I'm not proposing that client certs use port numbers, for reasons that I hope are obvious. From nobody Wed Jan 13 14:37:03 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5356A1A8797 for ; Wed, 13 Jan 2016 14:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl9in_xZ-3jW for ; Wed, 13 Jan 2016 14:37:01 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A311A877C for ; Wed, 13 Jan 2016 14:37:00 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 178FA284E5C; Wed, 13 Jan 2016 22:37:00 +0000 (UTC) Date: Wed, 13 Jan 2016 22:37:00 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160113223659.GB28324@mournblade.imrryr.org> References: <20160113181428.GN18704@mournblade.imrryr.org> <20160113200617.65983.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160113200617.65983.qmail@ary.lan> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 22:37:02 -0000 On Wed, Jan 13, 2016 at 08:06:17PM -0000, John Levine wrote: > > _service._client.node.example. IN TLSA ... > > Ah, we're getting closer. Well, I can live with the above, *if* there's a good reason to expect conflicts that block use of CNAMEs. > >I still don't see any use for _tcp/_udp in there. > > RFC 6698 has _tcp _udp and _sctp protocols as part of the names for > TLSA. For a good reason, because the full prefix is "_._". Without "_proto", we get TLSA records applied to the wrong service endpoint, because UDP ports with the same number don't reach have the same service as the TCP ports. > It seems rather odd to have the protocol name for the server > certificate but not for the client. Because the client prefix-label a service *name*, so so the port collision issue goes away. We should not cargo-cult designs, the rationale has to carry over logically, and false analogies need to be avoided. -- Viktor. From nobody Wed Jan 13 17:02:04 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42B31A875E for ; Wed, 13 Jan 2016 17:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4IWlW0ENGwj for ; Wed, 13 Jan 2016 17:02:02 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEC01A874F for ; Wed, 13 Jan 2016 17:02:01 -0800 (PST) Received: (qmail 71196 invoked from network); 14 Jan 2016 01:02:00 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 14 Jan 2016 01:02:00 -0000 Date: 14 Jan 2016 01:01:38 -0000 Message-ID: <20160114010138.66774.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <20160113223659.GB28324@mournblade.imrryr.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 01:02:03 -0000 >Because the client prefix-label a service *name*, so so the port >collision issue goes away. We should not cargo-cult designs, >the rationale has to carry over logically, and false analogies >need to be avoided. One man's cargo cult is another man's namespace management. Every existing use of _ names is behind a _ name, and there seems to me considerable merit to keep it that way, at the trivial cost of a possibly uninteresting _tcp or _udp in the name. If the extra five bytes is an issue, I suppose we could use _c rather than _client for the client tag. While saving five characters was a big deal when I was programming PDP-8's almost 50 years ago, I don't get it now. R's, John From nobody Wed Jan 13 17:19:17 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43111AD0C5 for ; Wed, 13 Jan 2016 17:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id py1_GCp7bgRq for ; Wed, 13 Jan 2016 17:19:14 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F241AD0C3 for ; Wed, 13 Jan 2016 17:19:14 -0800 (PST) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 4F4A2284809 for ; Thu, 14 Jan 2016 01:19:13 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Viktor Dukhovni In-Reply-To: <20160114010138.66774.qmail@ary.lan> Date: Wed, 13 Jan 2016 20:19:12 -0500 Content-Transfer-Encoding: 7bit Message-Id: <9C1F4A0C-0E08-4F6E-BDB1-74E55CB4EF2A@dukhovni.org> References: <20160114010138.66774.qmail@ary.lan> To: dane@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 01:19:15 -0000 > On Jan 13, 2016, at 8:01 PM, John Levine wrote: > >> Because the client prefix-label a service *name*, so so the port >> collision issue goes away. We should not cargo-cult designs, >> the rationale has to carry over logically, and false analogies >> need to be avoided. > > One man's cargo cult is another man's namespace management. Every > existing use of _ names is behind a _ name, and there > seems to me considerable merit to keep it that way, at the trivial > cost of a possibly uninteresting _tcp or _udp in the name. If the > extra five bytes is an issue, I suppose we could use _c rather than > _client for the client tag. > > While saving five characters was a big deal when I was programming > PDP-8's almost 50 years ago, I don't get it now. This forces clients that use both TCP and UDP to publish their TLSA records twice (or better publish one as a CNAME for the other, or make both CNAMEs to a third thing). Is this really worth it? Folks are having a hard enough time publishing correct TLSA records, and remembering to change all the copies. -- Viktor. From nobody Wed Jan 13 18:49:34 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4C71B2AE5 for ; Wed, 13 Jan 2016 18:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzdvDbOa2L5F for ; Wed, 13 Jan 2016 18:49:33 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C4C1B2ADE for ; Wed, 13 Jan 2016 18:49:33 -0800 (PST) Received: (qmail 85429 invoked from network); 14 Jan 2016 02:49:32 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 14 Jan 2016 02:49:32 -0000 Date: 14 Jan 2016 02:49:10 -0000 Message-ID: <20160114024910.67019.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: <9C1F4A0C-0E08-4F6E-BDB1-74E55CB4EF2A@dukhovni.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] namespace management, DANE Client Authentication draft updated X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 02:49:34 -0000 >This forces clients that use both TCP and UDP to publish their TLSA >records twice (or better publish one as a CNAME for the other, or >make both CNAMEs to a third thing). Is this really worth it? How much of a problem has it been for TLSA server records? I honestly don't know but I'd be surprised if the answer were other than "not much". Creating the certificate and turning that into the right hex for the TLSA master record seems vastly harder than adding a CNAME which, if you are right that nobody ever does anything different on TCP and UDP, could be added mechanically. R's, John From nobody Thu Jan 14 07:10:43 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B481B2E33 for ; Thu, 14 Jan 2016 07:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCjWnoH1IYlA for ; Thu, 14 Jan 2016 07:10:38 -0800 (PST) Received: from mail-oi0-x261.google.com (mail-oi0-x261.google.com [IPv6:2607:f8b0:4003:c06::261]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B7981B354B for ; Thu, 14 Jan 2016 07:10:36 -0800 (PST) Received: by mail-oi0-x261.google.com with SMTP id y145so10845332oif.1 for ; Thu, 14 Jan 2016 07:10:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:content-id:content-transfer-encoding:mime-version; bh=pZRlCUxxGytn1ldjac78A18GMsrPrfZprITYDEyZQeU=; b=XwDfPsnKN2Vf1shb9wyVec32n+IfFnXnGjdP5ISGkVdFcMi7pvLnDuS5VswWlqCcmb ZkfH0oXVM3f9gOlBM6YKK83gCxCRw+q087FGuY3LFTneVPt8uQiu29dvFvbzesmWPrCL KQwjN72J/CoKVBXrJvZZUl1OWeODrZ64KeuAvy9eR4aGdgdCw4asYLqro9mNHyXtczUS t2iJRBr+BPjsiWpIva7Exhctsvum6tMr9olMGQn1kuXbcryfCJyET1SgtXS9hv0GwZqT 4bsat9CtN66Zvi17NWezHjxpK5e8Rb7fZMF6W1UmMC3gq9C6KhltUHaidrejEafB57Up uhaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:content-id:content-transfer-encoding:mime-version; bh=pZRlCUxxGytn1ldjac78A18GMsrPrfZprITYDEyZQeU=; b=gnb9DRKm94UHAGZ/Ld7CTD8IYiCGuAjkcvCqsen+Md/8Z1ScPpruxWqzFEGMM5NqnX K2ujxWZzDdmt2mp2XKjtmaaikxmTY0CiaGAWo+VYuNLYPSxLKeUmtFE/fXrmnM6zT302 DE3OGynKKi59DJk2gpXudm7U539gLa0tUURLIPQH0KLvwnWcJ/WewPgFKqLGKASiaQom Y78ZuqAHGGSxqeqDSI9Rn188At2qmgQOok325gw6vlyMP1iL+uCWtVbBz5NOk9FDeupx SEYBGyHGecktF+dy+REO6Nn57508VSgqLnNqYhW6/JR93aJMmj5vXpo4k/DC1Z8mHQ4j i5rg== X-Gm-Message-State: ALoCoQm6ZaZ4YjACWvXwjCcfHISyKo5utKyuIo/SobPDSF/QVY+v+2xc3bEOHJtOT4tz/+je2/2CKtkvc4yLUSWE5M/gIrcS0z3m/7P38bb2l7kFsnzTEBk= X-Received: by 10.140.222.18 with SMTP id s18mr6338044qhb.21.1452784235939; Thu, 14 Jan 2016 07:10:35 -0800 (PST) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id y16sm927729qka.6.2016.01.14.07.10.35 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 14 Jan 2016 07:10:35 -0800 (PST) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u0EFAZ1D021375 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 14 Jan 2016 10:10:35 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 14 Jan 2016 10:10:35 -0500 From: "Osterweil, Eric" To: "dane@ietf.org" Thread-Topic: [dane] any statistics of deployment available? Thread-Index: AdFIeslBxynRdYetRzmHZNYubTMahgAMtMUAAAyqfgABTGYggAAR5HgAACuL2wA= Date: Thu, 14 Jan 2016 15:10:34 +0000 Message-ID: References: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> <20160106131105.GC14398@sys4.de> <20160106191346.GF18704@mournblade.imrryr.org> <20160113182341.GO18704@mournblade.imrryr.org> In-Reply-To: <20160113182341.GO18704@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dane] any statistics of deployment available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 15:10:41 -0000 DQo+IE9uIEphbiAxMywgMjAxNiwgYXQgMToyMyBQTSwgVmlrdG9yIER1a2hvdm5pIDxpZXRmLWRh bmVAZHVraG92bmkub3JnPiB3cm90ZToNCj4gDQo+IE9uIFdlZCwgSmFuIDEzLCAyMDE2IGF0IDAy OjUxOjAxUE0gKzAwMDAsIFdpbGV5LCBHbGVuIHdyb3RlOg0KPiANCj4+IENvbXBhcmFibGUgc3Rh dHMgZnJvbSBTZWNTcGlkZXIgZm9yIGEgc3VydmV5IG9mIDEwNTYwOTcgem9uZXMgYXQNCj4+IGh0 dHA6Ly9zZWNzcGlkZXIudmVyaXNpZ25sYWJzLmNvbS9zdGF0cy5odG1sDQo+PiANCj4+IERBTkUg U3VtbWFyeQ0KPj4gMTYwNjUgREFORSBlbmFibGVkIHpvbmVzIHdpdGggVExTQSByZWNvcmRzDQo+ PiANCj4+IDY1IFBLSVggYmFzZWQgVHJ1c3QgQW5jaG9yIFRMU0EgcmVjb3JkcyAoQ2VydCBVc2Fn ZSAwKQ0KPj4gNTQxICAgUEtJWCBiYXNlZCBFbmQgRW50aXR5IFRMU0EgcmVjb3JkcyAoQ2VydCBV c2FnZSAxKQ0KPj4gMjY2ICAgREFORSBiYXNlZCBUcnVzdCBBbmNob3IgVExTQSByZWNvcmRzIChD ZXJ0IFVzYWdlIDIpDQo+PiA1NzkxICBEQU5FIGJhc2VkIEVuZCBFbnRpdHkgVExTQSByZWNvcmRz IChDZXJ0IFVzYWdlIDMpDQo+IA0KPiA2NjYzDQo+IA0KPiBUaGVzZSBudW1iZXJzIGRvbid0IGFk ZCB1cCB0byAxNjA2NSAodGhlaXIgc3VtIGlzIDY2NjMpLiAgU3VyZWx5DQo+IHRoZXJlIGFyZSBu b3QgbWFueSB6b25lcyAoYSBtYWpvcml0eT8pIHdpdGggVExTQSByZWNvcmRzIHdpdGggdXNhZ2UN Cj4gb3RoZXIgdGhhbiAwLzEvMi8zPw0KPiANCj4+IDQyNSAgIFpvbmVzIGhhdmUgZGVwbG95ZWQg VExTQSBmb3IgU2VjdXJlIFNNVFAgKFBvcnQgNDY1KQ0KPj4gMTI0ICAgWm9uZXMgaGF2ZSBkZXBs b3llZCBUTFNBIGZvciBTZWN1cmUgUE9QMyAoUG9ydCA5OTUpDQo+PiA1MDMgICBab25lcyBoYXZl IGRlcGxveWVkIFRMU0EgZm9yIFNNVFAgd2l0aCBTVEFSVFRMUyAoUG9ydCA1ODcpDQo+PiAyNCBa b25lcyBoYXZlIGRlcGxveWVkIFRMU0EgZm9yIEFsdGVybmF0ZSBTTVRQIChQb3J0IDI1MjUpDQo+ PiAzMDI0ICBab25lcyBoYXZlIGRlcGxveWVkIFRMU0EgZm9yIEhUVFBTIChQb3J0IDQ0MykNCj4+ IDE5OTYgIFpvbmVzIGhhdmUgZGVwbG95ZWQgVExTQSBmb3IgU01UUCAoUG9ydCAyNSkNCj4+IDcy IFpvbmVzIGhhdmUgZGVwbG95ZWQgVExTQSBmb3IgUE9QMyAoUG9ydCAxMTApDQo+PiAyOTQgICBa b25lcyBoYXZlIGRlcGxveWVkIFRMU0EgZm9yIFNlY3VyZSBJTUFQIChQb3J0IDk5MykNCj4+IDIw MSAgIFpvbmVzIGhhdmUgZGVwbG95ZWQgVExTQSBmb3IgSU1BUCAoUG9ydCAxNDMpDQo+IA0KPiBU aGVzZSBudW1iZXJzIGFsc28gYWRkIHRvIDY2NjMuICBXaGVyZSBkaWQgdGhlIDE2ayBudW1iZXIg Y29tZQ0KPiBmcm9tPyAgDQoNCkEgdmVyeSBnb29kIHF1ZXN0aW9uLiAgVGhlIHpvbmUgY291bnQg aXMgdHJ5aW5nIHRvIHNob3cgaG93IG1hbnkgem9uZXMgYXJlIHByb3RlY3RlZCBieSBEQU5FLiAg U28sIGlmIGEgem9uZSBoYXMgaXRzIE1YIHJlY29yZCAod2hpY2ggaXMgcHJvdGVjdGVkIGJ5IERB TkUpIGluIGFub3RoZXIgem9uZSwgd2UgY291bnQgdGhlIHJlZmVycmluZyB6b25lIGFzIERBTkUg ZW5hYmxlZC4gIFRoZSByYXRpb25hbGUgd2FzIHRoYXQgREFORSBpcyBhbiBhcHBsaWNhdGlvbi1s ZXZlbCBwcm90ZWN0aW9uIHNvIGlmIHlvdSBzZW5kIGVtYWlsIHRvIHNvbWVvbmUgYXQgIGdpdmVu IGVtYWlsIGFkZHJlc3MsIGFuZCB0aGUgU01UUCBzZXJ2ZXIgaXMgdW5kZXIgYW5vdGhlciB6b25l LCB0aGUgdXNlcnMgb2YgdGhlIGVtYWlsIGRvbWFpbiBhcmUgc3RpbGwgcHJvdGVjdGVkLiAgVGhh dOKAmXMgd2h5IGl04oCZcyBub3QgYSBkaXJlY3Qgc3VtLCBidXQgeW91IGNhbiBzZWUgd2UgZG9u 4oCZdCBtdWx0aS1jb3VudCB0aGUgYWN0dWFsIERBTkUgcmVjb3Jkcy4gIEnigJltIG9wZW4gdG8g aWRlYXMgYWJvdXQgb3RoZXIgd2F5cyB0byBleHByZXNzIHRoaXMsIGJ1dCB0aGUgaW50dWl0aW9u IHdhcyB0byBjYXB0dXJlIGhvdyBtYW55IHpvbmVz4oCZIHVzZXJzIGFyZSBwcm90ZWN0ZWQuICBN YWtlIHNlbnNlPw0KDQo+IEkgaGF2ZSBmb3VuZCAxMC43ayBkb21haW5zIGZvciBEQU5FIFNNVFAg KHBvcnQgMjUpIGluIGEgc2FtcGxlIG9mDQo+IDQuOE0gZG9tYWlucyBvZiB3aGljaCAxMjBrIGhh dmUgRE5TU0VDIGZvciBib3RoIHRoZSBkb21haW4gTVggUlJzZXQNCj4gYW5kIGZvciBhdCBsZWFz dCBvbmUgYmVzdCBwcmVmZXJlbmNlIE1YIGhvc3QgYW5kIHNvIGNhbiBzdGFydA0KPiBwdWJsaXNo aW5nIFRMU0EgcmVjb3Jkcy4NCg0KVGhpcyBzb3VuZHMgcmVhbGx5IGdyZWF0LiAgU2VjU3BpZGVy IGhhcyBiZWVuIG1vbml0b3JpbmcgYXMgbWFueSBETlNTRUMtc2lnbmVkIHpvbmVzIGFzIEnigJl2 ZSBiZWVuIGFibGUgdG8gZmluZCBmb3Igb3ZlciAxMCB5ZWFycy4gIFdl4oCZdmUgdGFrZW4gdXNl ciBzdWJtaXNzaW9ucywgY3Jhd2xlZCBzZWFyY2ggZW5naW5lcywgZXRjLiBpbiBvcmRlciB0byBz dHVkeSB0aGUgbG9uZyB0ZXJtIGV2b2x1dGlvbiBvZiBETlNTRUMgYW5kIGhvdyBwZW9wbGUgaGF2 ZSBtYW5hZ2VkIHRoZWlyIHpvbmVzIHNpbmNlIHByZXR0eSBtdWNoIHRoZSBiZWdpbm5pbmcgKHdl IHN0YXJ0ZWQgbW9uaXRvcmluZyBldmVyeSB6b25lIHdlIGNvdWxkIGZpbmQgcmlnaHQgYWZ0ZXIg dGhlIEROU1NFQyBSRkNzIHdlcmUgcHVibGlzaGVkKS4gIFdl4oCZdmUgZm91bmQgc29tZSByZWFs bHkgaW50ZXJlc3RpbmcgdGhpbmdzLCBidXQga2VlcGluZyBhYnJlYXN0IG9mIHRoZSBnbG9iYWwg ZGVwbG95bWVudCBoYXMgYmVjb21lIGluY3JlYXNpbmdseSBkaWZmaWN1bHQuICBXb3VsZCB5b3Ug YmUgYW1lbmRhYmxlIHRvIHNoYXJpbmcgdGhvc2Ugem9uZXMgd2l0aCBTZWNTcGlkZXI/ICBJ4oCZ ZCBsb3ZlIHRvIGFkZCB0aGVtIHRvIGl0cyBsb25naXR1ZGluYWwgc3R1ZHkuDQoNClRoYW5rcyEN Cg0KRXJpYw0KDQoNCg== From nobody Thu Jan 14 08:01:35 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337AD1A03A0 for ; Thu, 14 Jan 2016 08:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LAvrbzs9fio for ; Thu, 14 Jan 2016 08:01:32 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA761A0398 for ; Thu, 14 Jan 2016 08:01:32 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4ED55282FB3; Thu, 14 Jan 2016 16:01:31 +0000 (UTC) Date: Thu, 14 Jan 2016 16:01:31 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20160114160131.GA646@mournblade.imrryr.org> References: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> <20160106131105.GC14398@sys4.de> <20160106191346.GF18704@mournblade.imrryr.org> <20160113182341.GO18704@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.24 (2015-08-30) Archived-At: Subject: Re: [dane] any statistics of deployment available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 16:01:34 -0000 On Thu, Jan 14, 2016 at 03:10:34PM +0000, Osterweil, Eric wrote: > >> DANE Summary > >> 16065 DANE enabled zones with TLSA records > >> > >> 65 PKIX based Trust Anchor TLSA records (Cert Usage 0) > >> 541 PKIX based End Entity TLSA records (Cert Usage 1) > >> 266 DANE based Trust Anchor TLSA records (Cert Usage 2) > >> 5791 DANE based End Entity TLSA records (Cert Usage 3) > > > > 6663 Ok, so that's 6663 TLSA RRsets, but a much larger number of protected zones due to MX indirection. So I would clearly separate the RRset count from the "protected domain" count. >> 1996 Zones have deployed TLSA for SMTP (Port 25) So the missing ~10k "zones" (protected domains) are here, because the other ports are rarely (RFC6186 notwithstanding) subject to indirection. That is you've found 1996 MX hosts with TLSA RRsets? Or 1996 zones with 1 or more MX hosts with TLSA RRsets, or a total of 1996 TLSA records for port 25? I am guessing the latter, because that's what makes the "certificate usage" total equal to the "by port" total. In that case our numbers are similar, I have 10.7k email SMTP domains covered by TLSA records of 1564 MX hosts with 2212 TLSA RRs (at least, because there are cases where I don't look for any TLSA RRs on worse priority MX hosts if a better priority MX hosts have no TLSA records). Of the 10.7k domains 200 have incomplete TLSA record coverage in that some MX hosts are not protected, so the "domain" is not secured against MITM by attackers who block access to the protected MX hosts. -- Viktor. From nobody Thu Jan 14 09:41:07 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354851A6F9D for ; Thu, 14 Jan 2016 09:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqL6i44o4vBZ for ; Thu, 14 Jan 2016 09:41:04 -0800 (PST) Received: from mail-qg0-x262.google.com (mail-qg0-x262.google.com [IPv6:2607:f8b0:400d:c04::262]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DC71A6F59 for ; Thu, 14 Jan 2016 09:41:04 -0800 (PST) Received: by mail-qg0-x262.google.com with SMTP id o11so51269900qge.3 for ; Thu, 14 Jan 2016 09:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:content-id:content-transfer-encoding:mime-version; bh=DdVfb75KPENl7oBaqW3s4Kkj7J8UaRb0bU4VcPRnpoM=; b=kfKhKSnGN9uLp5M6KkU2RIeSVPlYAspMdqpnk5gNLP/2B0ZlrbF61hap5mYIrUm44I mmkcUAxQzTFrIowHr4QZsWA93SR+CI76DdYCdiL+E1POkSy/hhnQbpQQNbtGGuRA27nB 8BvYZO6ghbMtcNDqLlbP7SZCzN13Ij0FXj567xqBqjBkInZnAo5ksV+MvhI1oQpvsQ1J pYQG3e0svAJTuVX/+7W/jm+hErGR+OPxHulhsmTM9I2tsuVYoNrmMw7l7aZWb2ZwyWL0 53pA/ISf6jh6xu7BgK8fCV/VbvTE/HsWcxB40o8994ub29WVPbswM8saYypuIc5HRQNc vn1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:content-id:content-transfer-encoding:mime-version; bh=DdVfb75KPENl7oBaqW3s4Kkj7J8UaRb0bU4VcPRnpoM=; b=PVj1lY9RENIzZpxUt+I9DRbHGrglHzakk24mv/M190tqmcmGAHMap0IRp6wTMtELfj 6U+6bTnQurenD48KiLJziKnnQOlyhg2oJyJwelSj8D71i8vN1fGdQUEF6Lz3KUZSXEHC A07KKwyuOz94MJjd3Ts3C7vv6/i058/FO5r0qix/x3WPhOk4j/cESWJhJn5xHTIMFvGe rEMe+Hwcwjm/PgrTjJ2dwLV3kSkTE2fbK1PUj23y5ttNqeAS6gX16p1omFFy6yCSHPQq 1bQfzdZUrtCHkeHZLoUbh+VH2VYHjOVIQWJf0yxQKKqkAltjKwWHgnPcscT9cozyq3z6 WzWQ== X-Gm-Message-State: ALoCoQmJmiIq0In/hr7PfC8fMFZJFDuD5oSbdDZEAay3x79eCci9Pff1qDBMvL5LktboA6Yrx3IIqAHv7wdYQW56J+Zd/MJ9Dguvd9ZpP3jdX6+2d3D9LNQ= X-Received: by 10.141.6.131 with SMTP id i125mr8067661qhd.68.1452793263599; Thu, 14 Jan 2016 09:41:03 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id d3sm1015951qkb.3.2016.01.14.09.41.03 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 14 Jan 2016 09:41:03 -0800 (PST) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u0EHf35H013693 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 14 Jan 2016 12:41:03 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 14 Jan 2016 12:41:01 -0500 From: "Osterweil, Eric" To: "dane@ietf.org" Thread-Topic: [dane] any statistics of deployment available? Thread-Index: AdFIeslBxynRdYetRzmHZNYubTMahgAMtMUAAAyqfgABTGYggAAR5HgAACuL2wAAAceIgAADdlKA Date: Thu, 14 Jan 2016 17:41:00 +0000 Message-ID: References: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> <20160106131105.GC14398@sys4.de> <20160106191346.GF18704@mournblade.imrryr.org> <20160113182341.GO18704@mournblade.imrryr.org> <20160114160131.GA646@mournblade.imrryr.org> In-Reply-To: <20160114160131.GA646@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-ID: <4CE0871D0A1404468F2002C9095B639C@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dane] any statistics of deployment available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 17:41:06 -0000 DQo+IE9uIEphbiAxNCwgMjAxNiwgYXQgMTE6MDEgQU0sIFZpa3RvciBEdWtob3ZuaSA8aWV0Zi1k YW5lQGR1a2hvdm5pLm9yZz4gd3JvdGU6DQo+IA0KPiBPbiBUaHUsIEphbiAxNCwgMjAxNiBhdCAw MzoxMDozNFBNICswMDAwLCBPc3RlcndlaWwsIEVyaWMgd3JvdGU6DQo+IA0KPj4+PiBEQU5FIFN1 bW1hcnkNCj4+Pj4gMTYwNjUgREFORSBlbmFibGVkIHpvbmVzIHdpdGggVExTQSByZWNvcmRzDQo+ Pj4+IA0KPj4+PiA2NSBQS0lYIGJhc2VkIFRydXN0IEFuY2hvciBUTFNBIHJlY29yZHMgKENlcnQg VXNhZ2UgMCkNCj4+Pj4gNTQxICAgUEtJWCBiYXNlZCBFbmQgRW50aXR5IFRMU0EgcmVjb3JkcyAo Q2VydCBVc2FnZSAxKQ0KPj4+PiAyNjYgICBEQU5FIGJhc2VkIFRydXN0IEFuY2hvciBUTFNBIHJl Y29yZHMgKENlcnQgVXNhZ2UgMikNCj4+Pj4gNTc5MSAgREFORSBiYXNlZCBFbmQgRW50aXR5IFRM U0EgcmVjb3JkcyAoQ2VydCBVc2FnZSAzKQ0KPj4+IA0KPj4+IDY2NjMNCj4gDQo+IE9rLCBzbyB0 aGF0J3MgNjY2MyBUTFNBIFJSc2V0cywgYnV0IGEgbXVjaCBsYXJnZXIgbnVtYmVyIG9mIHByb3Rl Y3RlZA0KPiB6b25lcyBkdWUgdG8gTVggaW5kaXJlY3Rpb24uICBTbyBJIHdvdWxkIGNsZWFybHkg c2VwYXJhdGUgdGhlIFJSc2V0DQo+IGNvdW50IGZyb20gdGhlICJwcm90ZWN0ZWQgZG9tYWluIiBj b3VudC4NCg0KWWVwLiAgVGhlIFJSIGNvdW50cyBhcmUgbGlzdGVkIGJlbG93IHRoZSB6b25lIGNv dW50LiAgSSB0aGluayB0aGlzIGlzIHByZWNpc2VseSB3aGF0IGxlZCB5b3UgdG8gbm90aWNlLiAg VGhhdCBpcywgYWxsIG9mIHRoZSBjb3VudHMgYmVsb3cgdGhlIHpvbmUgY291bnQgYXJlIFJSIGNv dW50cy4NCg0KPiANCj4+PiAxOTk2ICBab25lcyBoYXZlIGRlcGxveWVkIFRMU0EgZm9yIFNNVFAg KFBvcnQgMjUpDQo+IA0KPiBTbyB0aGUgbWlzc2luZyB+MTBrICJ6b25lcyIgKHByb3RlY3RlZCBk b21haW5zKSBhcmUgaGVyZSwgYmVjYXVzZQ0KPiB0aGUgb3RoZXIgcG9ydHMgYXJlIHJhcmVseSAo UkZDNjE4NiBub3R3aXRoc3RhbmRpbmcpIHN1YmplY3QgdG8NCj4gaW5kaXJlY3Rpb24uICANCg0K QW55IG9mIHRoZSBtYWlsIHByb3RvY29scyBpcyBzdWJqZWN0IHRvIHRoaXMgaW5kaXJlY3Rpb24s IGFzIHRob3NlIERBTkUgcmVjb3JkcyBhcmUgYmFzZWQgb2ZmIHRoZSBNWCByZWNvcmQuDQoNCj4g VGhhdCBpcyB5b3UndmUgZm91bmQgMTk5NiBNWCBob3N0cyB3aXRoIFRMU0EgUlJzZXRzPyAgT3Ig MTk5NiB6b25lcw0KPiB3aXRoIDEgb3IgbW9yZSBNWCBob3N0cyB3aXRoIFRMU0EgUlJzZXRzLCBv ciBhIHRvdGFsIG9mIDE5OTYgVExTQQ0KPiByZWNvcmRzIGZvciBwb3J0IDI1PyAgSSBhbSBndWVz c2luZyB0aGUgbGF0dGVyLCBiZWNhdXNlIHRoYXQncyB3aGF0DQo+IG1ha2VzIHRoZSAiY2VydGlm aWNhdGUgdXNhZ2UiIHRvdGFsIGVxdWFsIHRvIHRoZSAiYnkgcG9ydCIgdG90YWwuDQoNClRoZXJl IGFyZSAxOTk2IFRMU0EgUmVzb3VyY2UgUmVjb3JkcyB0aGF0IGhhdmUgdGhlIGRvbWFpbiBuYW1l IF8yNS5fdGNwLjxkb21haW4gbmFtZT4uICBFYWNoIFJSIGF0IGV2ZXJ5IGRvbWFpbiBuYW1lIGdl dHMgY291bnRlZCBzZXBhcmF0ZWx5LiAgU28sIGlmIHNvbWVvbmUgaGFzIHR3byBSUnMgYXQgdGhl IHNhbWUgZG9tYWluIG5hbWUsIFNlY1NwaWRlciBjb3VudHMgdHdvLCBub3Qgb25lLg0KDQo+IElu IHRoYXQgY2FzZSBvdXIgbnVtYmVycyBhcmUgc2ltaWxhciwgSSBoYXZlIDEwLjdrIGVtYWlsIFNN VFANCj4gZG9tYWlucyBjb3ZlcmVkIGJ5IFRMU0EgcmVjb3JkcyBvZiAxNTY0IE1YIGhvc3RzIHdp dGggMjIxMiBUTFNBDQo+IFJScyAoYXQgbGVhc3QsIGJlY2F1c2UgdGhlcmUgYXJlIGNhc2VzIHdo ZXJlIEkgZG9uJ3QgbG9vayBmb3IgYW55DQo+IFRMU0EgUlJzIG9uIHdvcnNlIHByaW9yaXR5IE1Y IGhvc3RzIGlmIGEgYmV0dGVyIHByaW9yaXR5IE1YIGhvc3RzDQo+IGhhdmUgbm8gVExTQSByZWNv cmRzKS4gIE9mIHRoZSAxMC43ayBkb21haW5zIDIwMCBoYXZlIGluY29tcGxldGUNCj4gVExTQSBy ZWNvcmQgY292ZXJhZ2UgaW4gdGhhdCBzb21lIE1YIGhvc3RzIGFyZSBub3QgcHJvdGVjdGVkLCBz bw0KPiB0aGUgImRvbWFpbiIgaXMgbm90IHNlY3VyZWQgYWdhaW5zdCBNSVRNIGJ5IGF0dGFja2Vy cyB3aG8gYmxvY2sNCj4gYWNjZXNzIHRvIHRoZSBwcm90ZWN0ZWQgTVggaG9zdHMuDQoNClRoYXTi gJlzIHZlcnkgaW50ZXJlc3RpbmchDQoNCkVyaWM= From nobody Wed Jan 20 06:45:53 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1211A8A4E for ; Wed, 20 Jan 2016 06:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSQFqbCeGLzb for ; Wed, 20 Jan 2016 06:45:49 -0800 (PST) Received: from mail-qg0-x263.google.com (mail-qg0-x263.google.com [IPv6:2607:f8b0:400d:c04::263]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9981A8A4F for ; Wed, 20 Jan 2016 06:45:47 -0800 (PST) Received: by mail-qg0-x263.google.com with SMTP id i20so463667qgd.2 for ; Wed, 20 Jan 2016 06:45:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :accept-language:content-language:content-type:mime-version; bh=Ie4fCd54r9dpAlyIjtPIp7aK19ED/ITN+mgbQcRMPdg=; b=yqR5sMWAVgBAurV+pzxo3LkZq28hGlpe54gxAkaHwIfsXqCkwPkCJ2IJnx5J7hcLrZ eCn1ZCq0ADeZpyhFeTUFZdK2d06q1Gkrkr4+Ep/5/Q6AnqKue0TfBSEn0tn6bZvCJqzg 8KXxX6wIwbmyD/6YKIv8A2fD65fA79NVw9Di0++/r6GcZWx8LjxFu6NhpPoW2qcfPGKF pKYAj1ZvCSn/sfX1DaWMkvDujhM/IhqDNUBu5rUlLuM06mApZKotLOzFmhhxvx5sa7KN zFTjaEFHvW3lM7x2Z495mc0EnbZBM3S3CnPrU6oJ4GePAO5Q0UrmiaDmRNlo3PWv75jG uT1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:accept-language:content-language:content-type :mime-version; bh=Ie4fCd54r9dpAlyIjtPIp7aK19ED/ITN+mgbQcRMPdg=; b=U/EwiYr09x966nBGJjapC+zkCvksPSoaq1dHPU1dbkt8tzazIIO1hT+kaAfzMogAu9 1MsBw4Mh2wVQcpqTZgQ8DbmZ0Gdt82XWCil+HzIdmZzJV0StDYYJMFSJZkNqUeb6zJVZ ECtWHTzRs5EZf7RM4h5HMvBvOPE9umXbV1q3r/n2T/khlRLaD7sivScX71iBB14rlmcU NYhT9ZOo5mSDGP+qM5TlL/lSIOQbRCqoXuU9UFHd74Cw2XneFYTSVVjkwl+tvqRjyG4H y32qhDwWCU8PapBcTuiWuFOY+UeoZ8VWfHKXPlTdRoTCFLRH91thqtnqBFvPqqtY1akI pE/g== X-Gm-Message-State: ALoCoQnKVe8QKryn7gmta4JZeyTWse3jeLPKfm6PdfcE2c9VbSaJl1+OooBPDS5c0EyHK8vOJ0Mm8xuy0vIExEmBMshfv0uVdrFe+6GKXeoXOE3xkuR/VyA= X-Received: by 10.55.80.86 with SMTP id e83mr44917220qkb.91.1453301146188; Wed, 20 Jan 2016 06:45:46 -0800 (PST) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id x75sm1988889qkx.7.2016.01.20.06.45.45 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 20 Jan 2016 06:45:46 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u0KEjj9n012570 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2016 09:45:45 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 20 Jan 2016 09:45:45 -0500 From: "Mankin, Allison" To: "dane-chairs@ietf.org" Thread-Topic: Meeting plans for Buenos Aires? Thread-Index: AQHRU5E+IYqeUCUWr0ma1uZZ+hMJAw== Date: Wed, 20 Jan 2016 14:45:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_D2C507B4637B4amankinverisigncom_" MIME-Version: 1.0 Archived-At: Cc: "dane@ietf.org" Subject: [dane] Meeting plans for Buenos Aires? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 14:45:51 -0000 --_000_D2C507B4637B4amankinverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I may have missed it, but what=92s the plan for a DANE meeting at IETF95? --_000_D2C507B4637B4amankinverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I may have missed it, but what=92s the plan for a DANE meeting at IETF= 95?  



--_000_D2C507B4637B4amankinverisigncom_-- From nobody Wed Jan 20 07:21:35 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE111A8ACA for ; Wed, 20 Jan 2016 07:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbW_IaFiSYcg for ; Wed, 20 Jan 2016 07:21:31 -0800 (PST) Received: from smtp76.iad3a.emailsrvr.com (smtp76.iad3a.emailsrvr.com [173.203.187.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22931A8AC8 for ; Wed, 20 Jan 2016 07:21:31 -0800 (PST) Received: from smtp26.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B96A5805D9; Wed, 20 Jan 2016 10:21:30 -0500 (EST) X-Auth-ID: ogud@ogud.com Received: by smtp26.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 9C3BB80339; Wed, 20 Jan 2016 10:21:30 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-173-66-187-177.washdc.fios.verizon.net [173.66.187.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Wed, 20 Jan 2016 10:21:30 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_23D40362-E389-4594-B50B-421C41FDAF99" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Olafur Gudmundsson In-Reply-To: Date: Wed, 20 Jan 2016 10:21:30 -0500 Message-Id: References: To: "Mankin, Allison" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "dane-chairs@ietf.org" , "dane@ietf.org" Subject: Re: [dane] Meeting plans for Buenos Aires? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 15:21:33 -0000 --Apple-Mail=_23D40362-E389-4594-B50B-421C41FDAF99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We have no plans to meet as we are trying to shut the WG down.=20 Olafur > On Jan 20, 2016, at 9:45 AM, Mankin, Allison = wrote: >=20 > I may have missed it, but what=92s the plan for a DANE meeting at = IETF95? =20 >=20 >=20 >=20 --Apple-Mail=_23D40362-E389-4594-B50B-421C41FDAF99 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 We have no plans to meet as we are trying to shut the WG = down. 
Olafur

On = Jan 20, 2016, at 9:45 AM, Mankin, Allison <amankin@verisign.com> wrote:

I may have missed it, but what=92s the plan for a DANE = meeting at IETF95?  




= --Apple-Mail=_23D40362-E389-4594-B50B-421C41FDAF99-- From nobody Wed Jan 20 07:29:42 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB171A8AFB for ; Wed, 20 Jan 2016 07:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQM8mSDtw5kC for ; Wed, 20 Jan 2016 07:29:40 -0800 (PST) Received: from mail-oi0-x263.google.com (mail-oi0-x263.google.com [IPv6:2607:f8b0:4003:c06::263]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206B11A8BB4 for ; Wed, 20 Jan 2016 07:29:38 -0800 (PST) Received: by mail-oi0-x263.google.com with SMTP id x140so560531oif.3 for ; Wed, 20 Jan 2016 07:29:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=8GW1nL+TB6bGZKJpVTOPTg7OXP+eVdHZ3MgzIYZf2Kk=; b=T+ufFsZbcymS4YGi7MjZU3nTBdt53aQnVZIkrCJLVquihA3Wy1EpPszjhIw2930y1X g9d9vaNAuxh8skVEssSgPb21AO57QVy0D8Bv2cyOsQoGmDSnxRqRV7c+LtigndAt1KKB JQ8Ds5p/icUheDwtAVj0QYXwONm3Mklo2SQCWhceX5VWvl7k/xtw3OuI/HYdTRJQHoIO 87DhiqYshyHSFUnIdP41hufi5ekkYOPOdHBFlafjG+DNqGnDkewnDaESlCuCuSrQn2C/ F/5Jx5RXCPp611ytg/MLHsKmmRlSHBeaIUlun6R2fIbuxOFO6nLn7OSzq5X65RmFFkGk Trbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=8GW1nL+TB6bGZKJpVTOPTg7OXP+eVdHZ3MgzIYZf2Kk=; b=XQ7BC+1FXXrZaiuuAfAomAgdYFXnCUd3Vv8cJNxVyUBvDo5ApCvQhBe1V3DQsuTJXd E4K21HvK78NpdmmPhP6kvlX4CWxKP4h+I6j9xz5mbAfrS3644cZ/BO6HSzxmWIb6fKlC MRVKjjYMdPl1Q9pS5rHFV8MwCc4RQR9tIhTsl/Qkj5kxg4SyyCylUCHOix/WKaeQebZa +9kIVyTA1yOk/zmWgtpIC/Lx7zO/bfMQs5wCBlgdKD/jZPXjsH8bbg88yXf70n/tEu2a 1ATUX9RW1EXN8h64cgsqHpV3m1dFXt839XjrXfvS0gNeJzPLE8ftylyBCuO6whbwAnUS +0Ww== X-Gm-Message-State: ALoCoQn6FL8er9gukniPm5gcpcNkCF8bTyqokzkuoj1UgscaXn3O0MM6E9/R7ALD3FVjLt/jQDmvbDDz4qJUVQf+/br6pX7IYkyw9DQ3JBcrMdx3qmUJOxE= X-Received: by 10.140.151.198 with SMTP id 189mr48489322qhx.75.1453303778240; Wed, 20 Jan 2016 07:29:38 -0800 (PST) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id x206sm4770351qka.10.2016.01.20.07.29.38 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 20 Jan 2016 07:29:38 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u0KFTap0018021 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2016 10:29:37 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 20 Jan 2016 10:29:37 -0500 From: "Mankin, Allison" To: Olafur Gudmundsson Thread-Topic: Meeting plans for Buenos Aires? Thread-Index: AQHRU5E+IYqeUCUWr0ma1uZZ+hMJA58E2SgA//+uXoA= Date: Wed, 20 Jan 2016 15:29:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_D2C511DC63945amankinverisigncom_" MIME-Version: 1.0 Archived-At: Cc: "dane-chairs@ietf.org" , "dane@ietf.org" Subject: Re: [dane] Meeting plans for Buenos Aires? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 15:29:41 -0000 --_000_D2C511DC63945amankinverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable What is the future path for DANE-related efforts, if the WG is done? From: Olafur Gudmundsson > Date: Wednesday, January 20, 2016 at 10:21 AM To: Allison Mankin > Cc: "dane-chairs@ietf.org" >, "dane@ietf.org" > Subject: Re: Meeting plans for Buenos Aires? We have no plans to meet as we are trying to shut the WG down. Olafur On Jan 20, 2016, at 9:45 AM, Mankin, Allison > wrote: I may have missed it, but what=92s the plan for a DANE meeting at IETF95? --_000_D2C511DC63945amankinverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3E6418DEE53BFA489BBFE67BBB935289@verisign.com> Content-Transfer-Encoding: quoted-printable
What is the future path for DANE-related efforts, if the WG is done?

From: Olafur Gudmundsson <ogud@ogud.com>
Date: Wednesday, January 20, 2016 a= t 10:21 AM
To: Allison Mankin <amankin@verisign.com>
Cc: "dane-chairs@ietf.org" <dane-chairs@ietf.org>, "dane@ietf.org" <dane@= ietf.org>
Subject: Re: Meeting plans for Buen= os Aires?

We have no plans to meet as we are trying to shut the WG down. 
Olafur

On Jan 20, 2016, at 9:45 AM, Mankin, Allison <amankin@verisign.com> wrote= :

I may have missed it, but what=92s the plan for a DANE meet= ing at IETF95?  




 --_000_D2C511DC63945amankinverisigncom_-- From nobody Wed Jan 20 09:50:48 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4241AC3AC for ; Wed, 20 Jan 2016 09:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4cROsFPZs81 for ; Wed, 20 Jan 2016 09:50:46 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC23E1AC3AF for ; Wed, 20 Jan 2016 09:50:40 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id e65so8237020pfe.0 for ; Wed, 20 Jan 2016 09:50:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=kckexKKdn8+VkaE9AQ68mjzDDUiUemfAC+oK5I509A4=; b=t8VrUaIF/ia+KUnJoFlRxGEcoF00ep2R4E1INBcmTAc5Kt3kWE+JcXSNm/zCuwDq+/ IIE0ICMeTyl001Sp5o+8qj9IJoyPikpzGcP6ZPSQeJxyz+kvUGlDHA+fWrrLTRUE/Axw yNQ6R71OX9upsp6dRXgmJwdD0GPuRKyCfMtFiR8qJeKnyA94kxkzeEYoUwrVN73k1NPT 9y1w0K060Qcke+tPzPKVygRqD7GyVR4xSP9+kpcaELGmquUjzdKxCF+fjNSrZuflP5r0 VUaXm72lrv8WqHiF9avhnnO8SEi9/ApdwWdrFsazpJftbA5zO5rv03zzWSuUUYDipsxs qV5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=kckexKKdn8+VkaE9AQ68mjzDDUiUemfAC+oK5I509A4=; b=NeNxekYsbQuL35kkM9xSVR5j8O0Ps9gkFIYyGiePWKPWwe4JCbE9oeUb3TNGR1+Xvl JjLnJkC2S0lLRjyPzr5EIAYIYgFB1oUjXahULJBj9B51Z7nXcgd7RzGXbuzqiX2za6mj T4Zwy6VhZcFX5/2mwSQuHsOVZpJyEefc91izvYsxY/v44SYCZWauIDtafJCh8ndx9PQT c3AQ9EzHJQih6Su4V1wVsuAHYGBo/ip+nuok8MnE9M8+VUynH0CcGqYm/XPDfrDjUJvS NdFncUktzITRNvPVLlfEUqraEWbFrUMIoGW+ksytNQ5qhk1iikONxzdZf1zxa+oksVGb wU1g== X-Gm-Message-State: ALoCoQm/dlBFEHXn+S3oHrYx30WvSNkMr+pV0TZJk8ygNyf4efhFqnozORsBuA+FkwFplNQwwbc0i79lO585SB8f25UvXfjnQw== X-Received: by 10.98.80.79 with SMTP id e76mr54286164pfb.126.1453312240336; Wed, 20 Jan 2016 09:50:40 -0800 (PST) Received: from Melindas-MacBook-Pro.local (63-140-101-230-radius.dynamic.acsalaska.net. [63.140.101.230]) by smtp.googlemail.com with ESMTPSA id oj9sm50653792pab.8.2016.01.20.09.50.30 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jan 2016 09:50:39 -0800 (PST) To: dane@ietf.org References: From: Melinda Shore Message-ID: <569FC8C7.40303@gmail.com> Date: Wed, 20 Jan 2016 08:49:59 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dane] Meeting plans for Buenos Aires? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 17:50:48 -0000 On 1/20/16 6:21 AM, Olafur Gudmundsson wrote: > We have no plans to meet as we are trying to shut the WG down. I am not at all a fan of extending working groups beyond their natural lives (and in a few cases extending them to their natural lives) but this surprises me quite a bit, as there's quite a bit of useful work in the queue, particularly around end user credential for various applications. If dane isn't going to stick around I think there's a fairly compelling case for a maintenance and extension working group. I think many of these documents (and I can't believe I'm about to say this) are more appropriate as working group products rather than as individual contributions. Melinda From nobody Wed Jan 20 12:33:01 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100E51ACE03 for ; Wed, 20 Jan 2016 12:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm9DUe-PjFuc for ; Wed, 20 Jan 2016 12:32:59 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374111ACE09 for ; Wed, 20 Jan 2016 12:32:59 -0800 (PST) Received: from [10.59.3.103] (unknown [206.214.36.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2AB1A509BE; Wed, 20 Jan 2016 15:32:55 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_75443920-8E4D-415E-8CDF-2E70707C096C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <569FC8C7.40303@gmail.com> Date: Wed, 20 Jan 2016 12:32:05 -0800 Message-Id: <24CCFA62-4794-44F8-9A04-D32EE88683D8@seantek.com> References: <569FC8C7.40303@gmail.com> To: Melinda Shore X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Meeting plans for Buenos Aires? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 20:33:01 -0000 --Apple-Mail=_75443920-8E4D-415E-8CDF-2E70707C096C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 20, 2016, at 9:49 AM, Melinda Shore = wrote: > On 1/20/16 6:21 AM, Olafur Gudmundsson wrote: >> We have no plans to meet as we are trying to shut the WG down. >=20 > I am not at all a fan of extending working groups beyond their > natural lives (and in a few cases extending them to their > natural lives) but this surprises me quite a bit, as there's > quite a bit of useful work in the queue, particularly around > end user credential for various applications. If dane isn't > going to stick around I think there's a fairly compelling case > for a maintenance and extension working group. I think many > of these documents (and I can't believe I'm about to say this) > are more appropriate as working group products rather than > as individual contributions. +1 I believe that there is more work to do around DANE (particularly = non-TLS applications, i.e., e-mail, plus implementation = interoperability), and there should be a place in the IETF for this work = to be done. Sean --Apple-Mail=_75443920-8E4D-415E-8CDF-2E70707C096C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwMTIwMjAzMjU1WjAjBgkqhkiG9w0BCQQxFgQU7sfko9CE/W2/Q6VUhPm82mc0NmAwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAEoKZemxGOjjNr9iIH1uWphOoMC2vKPbCzbV+K58tyx+zbgE9V9bbpqTKVreRGv11S4Y Fq1+w89rSM7rgTOpSMJFw0J5Q928Lk54hjfOnyJilNqjo2KVLB0COt3CeAx4cpP+AwouXj74W0W0 2jOUUpru/YGIQ9BI5n7mKV9VkekCJmpzsF1pkmfD8WCxqxlPORgy75s8/zkIXY3KUESvnL9vXNV3 xbtdE2U6m0HJQesJJo7KAfRFuPiHdN08Xrkvq3NspwuXqSafdCZmJYLTdlzTajA/8mnMJ8NSZ11I fPIXY7XPPTDVvDlkRgrXTujbrlOoKl8mJSKVdBdX74y1ayAAAAAAAAA= --Apple-Mail=_75443920-8E4D-415E-8CDF-2E70707C096C-- From nobody Thu Jan 21 10:26:41 2016 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E981A8977; Thu, 21 Jan 2016 10:26:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160121182639.7138.69046.idtracker@ietfa.amsl.com> Date: Thu, 21 Jan 2016 10:26:39 -0800 Archived-At: Cc: dane-chairs@ietf.org, dane@ietf.org Subject: [dane] dane - New Meeting Session Request for IETF 95 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 18:26:39 -0000 A new meeting session request has just been submitted by Warren Kumari, a Chair of the dane working group. --------------------------------------------------------- Working Group Name: DNS-based Authentication of Named Entities Area Name: Security Area Session Requester: Warren Kumari Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 80 Conflicts to Avoid: First Priority: curdle dprive capport dots opsawg Second Priority: dnsop dbound saag dnssd Special Requests: --------------------------------------------------------- From nobody Thu Jan 21 10:32:21 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6461A899E for ; Thu, 21 Jan 2016 10:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HRGmGXzMbbl for ; Thu, 21 Jan 2016 10:32:13 -0800 (PST) Received: from smtp124.iad3a.emailsrvr.com (smtp124.iad3a.emailsrvr.com [173.203.187.124]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1B31A8993 for ; Thu, 21 Jan 2016 10:32:13 -0800 (PST) Received: from smtp8.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp8.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 2EE8E3803F6; Thu, 21 Jan 2016 13:32:12 -0500 (EST) X-Auth-ID: ogud@ogud.com Received: by smtp8.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 1A191380489; Thu, 21 Jan 2016 13:32:12 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-173-66-187-177.washdc.fios.verizon.net [173.66.187.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Thu, 21 Jan 2016 13:32:12 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Olafur Gudmundsson In-Reply-To: <569FC8C7.40303@gmail.com> Date: Thu, 21 Jan 2016 13:32:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <569FC8C7.40303@gmail.com> To: Melinda Shore X-Mailer: Apple Mail (2.2104) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Meeting plans for Buenos Aires? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 18:32:14 -0000 > On Jan 20, 2016, at 12:49 PM, Melinda Shore = wrote: >=20 > On 1/20/16 6:21 AM, Olafur Gudmundsson wrote: >> We have no plans to meet as we are trying to shut the WG down. >=20 > I am not at all a fan of extending working groups beyond their > natural lives (and in a few cases extending them to their > natural lives) but this surprises me quite a bit, as there's > quite a bit of useful work in the queue, particularly around > end user credential for various applications. If dane isn't > going to stick around I think there's a fairly compelling case > for a maintenance and extension working group. I think many > of these documents (and I can't believe I'm about to say this) > are more appropriate as working group products rather than > as individual contributions. >=20 > Melinda >=20 Melinda,=20 I hear you but the question is do we need a general DANE group for that = or if a new more=20 focused group(s) take over ?=20 The issue as Warren and I see is that the =E2=80=9Cenergy=E2=80=9D of = the group has decreased a lot indicating to us there is limited=20 interest in the work. We are happy to see more energy in the group and = to take on new work.=20 Everyone,=20 The chairs and AD want to see discussion on the future of the working = group.=20 Please bring to the table what you see the group can/should do.=20 It is up to the participants to set the direction for the group.=20 If the group continues we will recharter to reflect the direction.=20 To facilitate f2f discussion on this topic, the chairs have requested a = 1 hour slot in BA, BUT PLEASE start the conversation here.=20 Olafur & Warren=20= From nobody Thu Jan 21 11:19:00 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2AC1A8AF4 for ; Thu, 21 Jan 2016 11:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-WtGtFBhPxp for ; Thu, 21 Jan 2016 11:18:55 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CECBA1A8AF7 for ; Thu, 21 Jan 2016 11:18:52 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id e32so40207905qgf.3 for ; Thu, 21 Jan 2016 11:18:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nfwaK6tysIR24epfuOI/sHol3jOFXi51+DWTGL0cxz0=; b=wMJoGaVURFkbazwz6vzqolWyyGBuwg5ni4syelNr9Cg3EQi+0QAk63OtwoVzqukAiP Lx6les84/JCZPgMIqkCSYkHT341rFhZGXTlMcWtb8m0m954aKoK7vd3DqHGgL0YboaMt mQFq2nmhlhPdyOBtBpxccEpi23qGQZVCx6ANumyLDWCHlW3xnHKZpNc29DHvdUa3jq+W OyxPkKxvboABc/0WcPILQhVIU96MAM7eUUxmENX3UrJf9QcGQGY7XCvgWfkKTs34SMji teKgC5de6jxDBi3S2QQ0tVYyxVtmlMTeXjE4leJ7GTwLG7NgdGkiSroCGr2Rmo/tH+nJ seXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nfwaK6tysIR24epfuOI/sHol3jOFXi51+DWTGL0cxz0=; b=HFU7YO2SaZmM3JhzND/b9rW0HFeOWTmZgemjPCrV8ECTbZdtS4vh07TxeIvQhw+c/Z Y2Ytc1/FIK38dbuorYYX/fr12BlrirP2unnsXibeuUmfo0JqXSgxplOimJxfq4exXnRE kpgSuH91z8UV7xy+cKP1tskOpRKn+bzfOgi6j40EWhTlZ8EToVK89jb32iOgusa1caBT 0cNelRLbz0NSpPq+VxWhhlX0XTG4MvoJjm023POGK4nwCITmZx/ox0Ki2g3x7sgf5hgH gJR/PEgp13wkjWjMgV2hSsOA/83WLZHaTATWAgIKLntOlvPTUCoK9MwuF/FgOLSTeoFp Gw3w== X-Gm-Message-State: ALoCoQnMhKhTH2kRfThSkIlXwtnzNPxMsrqCkbvRgPRepnuH+7gjA8feJBhRe8NLwnDwIkXjspX7TGi+DGfRztkZWLdczryE/A== MIME-Version: 1.0 X-Received: by 10.140.100.141 with SMTP id s13mr52648771qge.25.1453403931856; Thu, 21 Jan 2016 11:18:51 -0800 (PST) Received: by 10.140.102.9 with HTTP; Thu, 21 Jan 2016 11:18:51 -0800 (PST) In-Reply-To: References: <569FC8C7.40303@gmail.com> Date: Thu, 21 Jan 2016 14:18:51 -0500 Message-ID: From: Shumon Huque To: Olafur Gudmundsson Content-Type: multipart/alternative; boundary=001a11c1752a12d4630529dcf9ac Archived-At: Cc: "" Subject: Re: [dane] Meeting plans for Buenos Aires? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 19:18:58 -0000 --001a11c1752a12d4630529dcf9ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 21, 2016 at 1:32 PM, Olafur Gudmundsson wrote: > > > Melinda, > I hear you but the question is do we need a general DANE group for that o= r > if a new more > focused group(s) take over ? > The issue as Warren and I see is that the =E2=80=9Cenergy=E2=80=9D of the= group has > decreased a lot indicating to us there is limited > interest in the work. We are happy to see more energy in the group and t= o > take on new work. > > Everyone, > > The chairs and AD want to see discussion on the future of the working > group. > Please bring to the table what you see the group can/should do. > It is up to the participants to set the direction for the group. > If the group continues we will recharter to reflect the direction. > > To facilitate f2f discussion on this topic, the chairs have requested a = 1 > hour slot in BA, BUT PLEASE start the conversation here. > Here's an overview of work that I'm aware of, that would benefit from a continued working group: * TLS Client Authentication with DANE TLSA records, which has generated recent discussion on this list. Viktor Dukhovni and I were planning to ask for working group adoption of that draft once we'd got it into decent shape (which is close). But beyond IETF participants, there are some active communities of folks that are planning to implement and deploy this protocol. Too often the IETF develops protocol specifications that don't get deployed much, so if there is evidence of real interest in the work outside of the core IETF participants, that should be given additional weight. * New application uses of the existing server TLSA spec. There is a proposal to do DANE authentication in SIP, which hasn't received much traction in the IETF to date. The author of that work has lamented to me that there is interest in that work in several sections of the SIP operator community, but he has been unable to generate any interest in doing that work in the IETF (specifically SIPCORE). I've suggested to him that he approach the DANE working group. There is also a proposal to do cross realm authentication in Kerberos with DANE. That work could happen in KITTEN, but if they don't have energy to take it on, again DANE could offer a venue. * TLS extension for DANE/DNSSEC Authentication Chain. That is targeted for adoption in the TLS working group once TLS1.3 work winds down there, but the substantive details of the spec are very largely about DNSSEC and DANE, so having a DANE focussed venue where we can discuss the design and topic generally is important. * The SMIMEA and OPENPGPKEY specs seem to be on track for publication as experimental RFCs. It would good to continue to have a venue to discuss deployment experiences with them, and also to discuss plans to recharter the group to revise them as standards track docs in the future if we come to that point. Relatedly, there are two proposals to specify email address local-part canonicalization rules in the DNS. Those might end up being important for the success of SMIMEA and OPENPGPKEY and deserve a venue. Lastly, new protocols take a long time to get deployed. Look at IPv6 - I'm speaking from experience, having first deployed it in production in 2002. And it's still largely undeployed. Shutting down the DANE working group while the protocol is still in its infancy, and while there is still potential work in the queue, sends the wrong message in my opinion. --=20 Shumon Huque --001a11c1752a12d4630529dcf9ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 21, 2016 at 1:32 PM, Olafur Gudmundsson <ogud@ogud.com> = wrote:

Melinda,
I hear you but the question is do we need a general DANE group for that or = if a new more
focused group(s) take over ?
The issue as Warren and I see is that the =E2=80=9Cenergy=E2=80=9D of the g= roup has decreased a lot indicating to us there is limited
interest in the work.=C2=A0 We are happy to see more energy in the group an= d to take on new work.

Everyone,

The chairs and AD want to see discussion on the future of the working group= .
Please bring to the table what you see the group can/should do.
It=C2=A0 is up to the participants to set the direction for the group.
If the group continues we will recharter to reflect the direction.

To facilitate f2f discussion on this topic, the chairs have requested=C2=A0= a 1 hour slot in BA, BUT PLEASE start the conversation here.

Here's an overview of work that I'm aware of= , that would benefit from a=C2=A0
continued working group:
<= div>
* TLS Client Authentication with DANE TLSA records, whic= h has generated recent=C2=A0
discussion on this list. Viktor Dukh= ovni and I were planning to ask for working group=C2=A0
adoption = of that draft once we'd got it into decent shape (which is close). But = beyond
IETF participants, there are some active communities of fo= lks that are planning to=C2=A0
implement and deploy this protocol= . Too often the IETF develops protocol=C2=A0
specifications that = don't get deployed much, so if there is evidence of real=C2=A0
interest in the work outside of the core IETF participants, that should b= e given=C2=A0
additional weight.

* New a= pplication uses of the existing server TLSA spec. There is a proposal=C2=A0=
to do DANE authentication in SIP, which hasn't received much= traction in the IETF=C2=A0
to date. The author of that work has = lamented to me that there is interest in that=C2=A0
work in sever= al sections of the SIP operator community, but he has been unable=C2=A0
to generate any interest in doing that work in the IETF (specificall= y SIPCORE).=C2=A0
I've suggested to him that he approach the = DANE working group. There is also=C2=A0
a proposal to do cross re= alm authentication in Kerberos with DANE. That work=C2=A0
could h= appen in KITTEN, but if they don't have energy to take it on, again DAN= E=C2=A0
could offer a venue.

* TLS exten= sion for DANE/DNSSEC Authentication Chain. That is targeted for=C2=A0
=
adoption in the TLS working group once TLS1.3 work winds down there, b= ut the=C2=A0
substantive details of the spec are very largely abo= ut DNSSEC and DANE, so=C2=A0
having a DANE focussed venue where w= e can discuss the design and topic=C2=A0
generally is important.<= /div>

* The SMIMEA and OPENPGPKEY specs seem to be on tr= ack for publication=C2=A0
as experimental RFCs. It would good to = continue to have a venue to discuss=C2=A0
deployment experiences = with them, and also to discuss plans to recharter the=C2=A0
group= to revise them as standards track docs in the future if we come to that=C2= =A0
point. Relatedly, there are two proposals to specify email ad= dress local-part=C2=A0
canonicalization rules in the DNS. Those m= ight end up being important for the=C2=A0
success of SMIMEA and O= PENPGPKEY and deserve a venue.

Lastly, new protoco= ls take a long time to get deployed. Look at IPv6 - I'm=C2=A0
speaking from experience, having first deployed it in production in 2002. = And
it's still largely undeployed. Shutting down the DANE wor= king group while
the protocol is still in its infancy, and while = there is still potential work in the
queue, sends the wrong messa= ge in my opinion.

--=C2=A0
Shumon Huque<= /div>

--001a11c1752a12d4630529dcf9ac-- From nobody Wed Jan 27 03:02:06 2016 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 092D71A6F2F; Wed, 27 Jan 2016 03:02:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160127110205.30700.83216.idtracker@ietfa.amsl.com> Date: Wed, 27 Jan 2016 03:02:05 -0800 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-openpgpkey-07.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 11:02:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using DANE to Associate OpenPGP public keys with email addresses Author : Paul Wouters Filename : draft-ietf-dane-openpgpkey-07.txt Pages : 18 Date : 2016-01-27 Abstract: OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities ("DANE") is a method for publishing public keys in DNS. This document specifies a DANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS Resource Record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the "Web of Trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be send unencrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 27 03:07:13 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582471A6F6B; Wed, 27 Jan 2016 03:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wunD4rfxxNI; Wed, 27 Jan 2016 03:07:04 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294AC1A6F61; Wed, 27 Jan 2016 03:07:04 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pr2FJ4DR9z3cY; Wed, 27 Jan 2016 12:07:00 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id QV-71y5CL0Yn; Wed, 27 Jan 2016 12:06:54 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 27 Jan 2016 12:06:54 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D2068600B884; Wed, 27 Jan 2016 06:06:52 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca D2068600B884 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CD4C22608E; Wed, 27 Jan 2016 06:06:52 -0500 (EST) Date: Wed, 27 Jan 2016 06:06:52 -0500 (EST) From: Paul Wouters To: Donald Eastlake In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: draft-ietf-dane-openpgpkey.all@tools.ietf.org, dane WG list , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [dane] [secdir] draft-ietf-dane-openpgpkey-06 SECDIR Review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 11:07:08 -0000 Hi Donald, Thanks for the secdir review. I've incorporated your suggestions and hopefully resolved your issues in the -07 draft I just posted at https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-07 Comments inline below. > I think this draft is not ready for publication. It probably minimal > technical changes but there are significant wording problems with it. > > Security: > ------------ > > This document is "DANE for OpenPGP ..." but never says how what it > documents is a use of DANE or what DANE is. While there is a reference > to RFC 6698, at a minimum the DANE acronym should be expanded at first > use and/or in Section 1.2. Preferably two or three sentences should be > added to fix this gap. I added a sentence to the introduction: DNSSEC Authentication of Networked Entities ("DANE") is a method for publishing public keys and certificates in DNS. > I am concerned about the use of the words "validate" and "verify" in > this document in a wide variety of different ways, and in particular > their use in connection with OPENPGPKEY RRs. The ordinary and usual > meaning of these words, when they are not qualified in some way, is > that something is completely valid/verified for use and can be used > without further checking. But that isn't what seems to be meant in > this document. Here it just seems to sometimes mean that it has > validated under DNSSEC. It might also mean that it is of valid syntax > and a bit more -- the document is unclear on whether that is included. > But the use of these words for OPENPGPKEY RRs seems to exclude the > validation under the web of trust or human judgement even though that > step is mandated at a couple of places in the document. The term "verify" is in common use with OpenPPGP, for instance using the gnupg command where the command is "gpg --verify". I have made some changes to avoid possible confusion. I have changed the usage of validation or verification in the context of DNSSEC to consitently be "DNSSEC validation". I've also changed the word "verification" when used in a context that is not related to OpenPGP. (for instance by changing "source ip verification" to "source ip confirmation"). > Looking at Section 5, the "obtain or verify" in the first sentence > seems odd. Shouldn't it use "and" and be more like "obtain and DNSSEC > verify"? And in the following sentence, I would say "... ; if DNSSEC > validation reaches ..." Also, if you are going to start talking about > a specific DNSSEC state name as is done here, there should be a > reference to the specific DNSSEC RFC where that state name is defined. Changed to: The OPENPGPKEY record allows an application or service to obtain an OpenPGP public key and use it for verifying a digital signature or encrypting a message to the public key. The DNS answer MUST pass DNSSEC validation; if DNSSEC validation reaches any state other than "Secure" (as specified in RFC-4035), the DNSSEC validation MUST be treated as a failure. RFF-4035 has been added as a normative reference. > In Section 5.1, in the first sentence, I would say "to seek" rather > than "to discover". "discover" makes it sound like it will always > un-cover/find something; also I think it would be a bit better to say > "corresponding to" rather than "belongs to". Changed as suggested. > The last sentence in 5.1 > has too many confusing "this"s. Suggest, assuming I have correctly > understood what you want to say, replacing the current last sentence > with "An application whose attempt fails to retrieve a DNSSEC verified > OPENPGPKEY RR from the DNS should remember that failure for some time > to avoid sending out a DNS request for each email message the > application is sending out; such DNS requests constitute a privacy > leak". Changed. > I suggest changing the title of Section 5.2 to "Confirming that an > OpenPGP key is current" since that is what it is about, not about > general validity. Changed. > The third sentence of Section 5.2 ("If verifying ... > a failure") is unclear and not grammatical. Trying to re-write this > third sentence I come up with "If a locally stored OpenPGP public key > is found to be different from an OpenPGP retrieved from the DNS and > DNSSEC verified as described herein, then ...." But I don't understand > this and don't understand what the "..." should be. I have changed it to: If the locally stored OpenPGP public key is different from the DNSSEC validated OpenPGP public key currently published in DNS, the verification MUST be treated as a failure unless if the locally stored OpenPGP key signed the newly published OpenPGP public key found in DNS. > Can't there can be > multiple good OpenPGP keys for the same email address? Yes, there can be. But a locally stored OpenPGP public key must be considered more secure than a new one observed in DNS, until a human has confirmed the new key. Unless the old key has confirmed the new key. > What if one key > is stored locally and you retrieve two keys, one of which is equal to > the local key and one of which is different? Presumably it depends on > the local/user's policy what to do in such a case of different keys. What I tried to accomplish is that if you have a local key, any key update must be confirmed by the old key or the user. Switching keys without further confirmation is just too dangerous. > How is it helpful to say "the verification MUST be treated as a > failure"? (This certainly further confuses what "verification" means > in this document.) The presence of a new key might mean the old (locally stored) key was compromised. But the new key cannot just be trusted even if it passed DNSSEC validation. Unless the old key signed the new key, human intervention should be used to resolve the conflict. By saying "verification failure" it blocks the application from sending the data encrypted to either key - and require a user to resolve the situation. > It is not clear exactly what that means but if it > says that a DNSSEC verified OpenPGP key retrieved from the DNS should > be dropped/ignored, why is that always the right thing? I did not mean say drop or ignored. A conflict of keys should be resolved by the user. > In the second sentence of the first paragraph of Section 7, what does > the initial "It" stand for? Changed to: DANE for OpenPGP as specified in this document is a solution aimed to ease obtaining someone's public key. Without manual verification of the OpenPGP key obtained via DANE, this retrieved key should only be used for encryption if the only other alternative is sending the message in plaintext. > If you were faked-out and believed a false key so email was encrypted > to the bad guy and could not be read by the intended recipient, I > would say that was worse than plaintext. That really depends on the situation. If an attacker can replace OPENPGPKEY records, they can most likely also change MX records to just get everything. > This paragraph goes on to > talk about active attacks, which usually. in the email context, refers > to active attacks on the email on the wire, but I would guess this > text is actually talking about active attacks in the form of storing a > wrong key in the DNS... The active attacks refer to everything that can cause a third party to gain access to the unencrypted email content. > In re Section 7.5, why isn't the domain name included in the hash? It > seems to improve security a little and the effort is small. As stated in that section 7.5: The domain name part of the email address is not used as part of the hash so that hashes can be used in multiple zones deployed using DNAME [RFC6672] > Other: > -------- > > Section 1: > > The references for Secure DNS should be given when Secure DNS is first > mentioned on page 3. Done. > Section 1.1: > > I do not think there is such a thing as an "Experimental RRtype". It > would be better to say something like "This document specifies an > RRtype whose use is Experimental." Done. > I don't quite grok the use of "generality of" on page 4. Perhaps it > should be replaced with "diffuse support of" or something. Changed to "general application" > Section 2: > > As long as you are bothering to say that the OPENPGPKEY RR has no > special TTL requirements, you might as well say it has no special > Additional section retrieval requirements, since I think that is the > most common type of RR special processing. But I think the lack of > such special requirements is the default so you could probably just > leave these negative statements out. Done. > Section 2.3: > > "textual zone files" -> "master files [RFC1035]" and add [RFC1035] to > the normative references. Done. > Section 3: > > The following statement seems at least a little misleading: > The DNS does not allow the use of all characters that are supported > in the "local-part" of email addresses as defined in [RFC5322] and > [RFC6530]. > DNS is binary clean. What left hand side characters allowed in > [RFC5322] are now allowed in DNS? Seems to me that only international > text as such [RFC6530] is a problem for DNS. And the "." or a NULL. There is also the case sensitivity argument raised by some. > Probably the first bullet should be split in two. The first time I > read it, it seemed that the first sentence was talking about some > encodings. Then the second sentence talks about other encodings and > says they are hashed. So, of course, I thought that the encodings > talked about in the first sentence were not hashed. But the example > appears to show that the current text had conveyed the wrong thing to > me and that it is always hashes. I suggest that after "If it is > written in another encoding it should be converted to UTF-8" be > followed by a period and then there should be a new bullet item > talking about hashing, etc., to make it clear that the hashing, etc., Done. > apply to all encodings in the first bullet. Furthermore, I don't > understand why the text fragment I quote says "should" rather than > "must" or perhaps just replace "should be" with "is". Done (with "is") > Then we get to the truncation. "Truncation comes from the right-most > octets." is completely ambiguous. At a minimum, a word needs to be > added so it says "Truncation comes from using the right-most octets." > or "Truncation comes from dropping the right-most octets." > Alternatively some other non-ambiguous wording is needed. Actually I think the whole two sentence that start from this can be dropped. These add no new information. > Presumably it is believed that the probability of a hash collision is > small enough that it can be ignored. If so, it wouldn't hurt to say > so. Added to the security section: In theory, two different local-parts could hash to the same value. This document assumes that such a hash collision has a negliable chance of happening. > Section 7: > > The last paragraph of Section 7 seems to equate "Organizations" and > "mail servers". Suggest recasting the second sentence as "Mail servers > of such organizations MAY optionally re-encrypt a received message to > an individual's OpenPGP key.". Done. > Section 7.1: > > Again, I assume "indeterminate" and "bogus" are used in their DNSSEC > meaning. So there needs to be a reference here to the DNSSEC RFC that > explains those words. Done, Added pointer to RFC-4035 > Author's Address: > > I understand that many do not agree with me but I believe that first > page authors should normally list a postal address and a telephone > number to which a message could be sent or at which a message could be > left for them in addition to an email address. This section looks like > schlock corner cutting to me. I do not agree. Any address and phone number listed would be too ephemeral or too generic to be of value to anyone. > Trivia: > -------- > > "twart" -> "thwart" and "twarts" -> "thwarts" Fixed. > Section 6: "properties are not exported" -> "properties not be > exported" and in the following sentence "have" -> "has" Fixed. > Section 7: "direct" -> "ask" (a mail client has no power to order the > user to do anything) Fixed. Also changed "human" to "user" everywhere. > Section 7.1: 5th paragraph, "sent" -> "send" Fixed. Paul From nobody Wed Jan 27 14:09:01 2016 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890911B2C06 for ; Wed, 27 Jan 2016 14:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RpYqFhOg2hn for ; Wed, 27 Jan 2016 14:08:58 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0643.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:643]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A8C1B2C04 for ; Wed, 27 Jan 2016 14:08:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cDFKYE+HkyRM2R9YOOG9wzDCb97EtHhdg1oY1l8lCOU=; b=kXXFKKZ/cQ+kbsgDKzZ3lANxUl71MkliZDTxydgKjt4FDOWAsOsBNK57lwOiM3ayEH3mUtyVNeA/tEruVgjNetuEvb+d/Zw/TDUAxdDMcXIkSEQk5q+3XPa/PK+2Zq0FHDqQZKpK+B2ZMxMUTXGBLbfJvurt8lMfbuFeUY0N18c= Received: from CY1PR0601MB1657.namprd06.prod.outlook.com (10.163.232.19) by CY1PR0601MB1659.namprd06.prod.outlook.com (10.163.232.21) with Microsoft SMTP Server (TLS) id 15.1.390.13; Wed, 27 Jan 2016 22:08:35 +0000 Received: from CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) by CY1PR0601MB1657.namprd06.prod.outlook.com ([10.163.232.19]) with mapi id 15.01.0390.013; Wed, 27 Jan 2016 22:08:35 +0000 From: Dan York To: IETF DANE Mailinglist Thread-Topic: Added DANE stats to Deploy360 page - Re: [dane] any statistics of deployment available? Thread-Index: AdFIeslBxynRdYetRzmHZNYubTMahgACOpAAAAyqfgABVt0OgAAHbYkAACuL3AAAAceHgAADeXMAApciEwA= Date: Wed, 27 Jan 2016 22:08:34 +0000 Message-ID: <9D7D41B5-DD7F-48D3-9A4D-CF8AB56A00B5@isoc.org> References: <814D0BFB77D95844A01CA29B44CBF8A715B0AEC4@lhreml504-mbs> <20160106131105.GC14398@sys4.de> <20160106191346.GF18704@mournblade.imrryr.org> <20160113182341.GO18704@mournblade.imrryr.org> <20160114160131.GA646@mournblade.imrryr.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=york@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [74.69.229.215] x-microsoft-exchange-diagnostics: 1; CY1PR0601MB1659; 5:LJh55+y8iSHtiRqZkIE+qK6GhuPkIVDkkKYHAj8zrkb4R03w0eKYyHNCzdn+yoBEeTS3iT3MZ+n02wmX6LP4ykMDQc2ssfeckuYg1pkS0J6AwWEdylP/DnLGVjWDY8gjg9FrIIsChN4QvmS0cWVFHQ==; 24:W88ln3/7u4Wfd9MtQe9ln9SVH38beYG3AduzIhtgxI0TvNsHDLIa2fFXU57oyM+VX5+GCZovlNtQ+0A8AWRq1RMPjEir7j1hJNJh/Bx2ZoM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1659; x-ms-office365-filtering-correlation-id: 1c1a188a-5602-4761-e852-08d327666698 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(51492898944892); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:CY1PR0601MB1659; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1659; x-forefront-prvs: 0834BAF534 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(164054003)(199003)(77096005)(10400500002)(19580405001)(2906002)(87936001)(122556002)(86362001)(5004730100002)(40100003)(36756003)(92566002)(3660700001)(15395725005)(93886004)(3470700001)(3280700002)(1096002)(1220700001)(11100500001)(15975445007)(450100001)(102836003)(110136002)(229853001)(19580395003)(107886002)(99286002)(54356999)(2950100001)(82746002)(5001960100002)(83716003)(3846002)(81156007)(50986999)(33656002)(76176999)(6116002)(16236675004)(5008740100001)(5002640100001)(189998001)(66066001)(101416001)(106356001)(97736004)(105586002)(586003)(19617315012)(2900100001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1659; H:CY1PR0601MB1657.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_9D7D41B5DD7F48D39A4DCF8AB56A00B5isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2016 22:08:34.5034 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1659 Archived-At: Subject: [dane] Added DANE stats to Deploy360 page - Re: any statistics of deployment available? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 22:09:00 -0000 --_000_9D7D41B5DD7F48D39A4DCF8AB56A00B5isocorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just to close the loop on the listing of DANE statistics, I've now added th= e sites and presentation shared on this list to the DNSSEC Statistics page = on Deploy360: http://www.internetsociety.org/deploy360/dnssec/statistics/#dane If anyone has additional DANE-related statistics that I should enter there,= please let me know. Thanks, Dan -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/ --_000_9D7D41B5DD7F48D39A4DCF8AB56A00B5isocorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <32E4C0884CFF9145AB141ACF70514BDD@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Just to close the loop on the listing of DANE statistics, I= 've now added the sites and presentation shared on this list to the DNSSEC = Statistics page on Deploy360:

http://www.internetsociety.org/deploy360/dnsse= c/statistics/#dane

If anyone has additional DANE-related statistics that I sho= uld enter there, please let me know.

Thanks,
Dan

--
Dan York
Senior Content Strategist, Int= ernet Society
york@isoc.org   +1-802-735-1624
Jabber: york@jabber.isoc.org 
Skype: danyork   http://twitter.com/danyork

http://www.internets= ociety.org/




--_000_9D7D41B5DD7F48D39A4DCF8AB56A00B5isocorg_--