From Antoin.Verschuren@sidn.nl Thu Dec 1 01:55:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3402921F8C41 for ; Thu, 1 Dec 2011 01:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYAVOAPG3z3W for ; Thu, 1 Dec 2011 01:55:51 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 17AA321F8BC5 for ; Thu, 1 Dec 2011 01:55:50 -0800 (PST) Received: from kahubcas1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id pB19tn1F001229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 1 Dec 2011 10:55:49 +0100 Received: from [192.168.129.215] (192.168.129.215) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 1 Dec 2011 10:55:49 +0100 Message-ID: <4ED74F32.3020302@sidn.nl> Date: Thu, 1 Dec 2011 10:56:02 +0100 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> In-Reply-To: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [192.168.129.215] Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 09:55:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30-11-11 22:07, OndÅ™ej Surý wrote: > > --new text-- > An application that complies with this document first requests TLSA > records in order to make certificate associations. > > Determining whether a TLSA RRset can be used depends > on the DNSSEC validation state (as defined in [RFC4033]). > > o A TLSA RRset whose DNSSEC validation state is secure MAY be used > as a certificate association for TLS. > > o If the DNSSEC validation state on the response to the request > for the TLSA RRset is bogus, this MUST cause TLS not to be started > or, if the TLS negotiation is already in progress, to cause > the connection to be aborted. > > o A TLSA RRset whose DNSSEC validation state is indeterminate or > insecure cannot be used for TLS and MUST be marked as unusable. > --new text-- +1 I hope though that implementers will warn me when the indeterminate or insecure case causes other TLS validation to occur and I'm not doing DANE, so I can be extra carefull. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJO108yAAoJEDqHrM883AgniN4H/iFCisW9IGI/1bfKrFRukIrX 53470G3YqcjiIBbIaM1g9u3mE/q/q5/ko5T07ekL6BEDFOmHi8i01kPETgdxoyr7 +YE/ALIJIdQTalwDvOJuaMd7jIshlJWKBXBxz6BQa6AeXWPnGwL+eBVHHEUzygSI VgHMnb8Y9GFSP+7bwzVdkjytY53AFn+GarDwvigJrfm76NghznJ1MCNhhOiBm9bn 74A7MwCE7rbx3Sqf8iVjqHOwUKDB3lY2o+hIuVhe9xA/ZdtAjiJ+EvCohH/ICHx1 8PspN78d9nAWHxpOUyUjMtYAeRVgWJEknVyibOvmkGzK0N9JyUorNuJz94U3f0M= =gUqG -----END PGP SIGNATURE----- From trevorf@exchange.microsoft.com Thu Dec 1 02:10:42 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779BD21F8C47 for ; Thu, 1 Dec 2011 02:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWOXHs8Z9oiC for ; Thu, 1 Dec 2011 02:10:38 -0800 (PST) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by ietfa.amsl.com (Postfix) with ESMTP id E4E7721F8BA4 for ; Thu, 1 Dec 2011 02:10:37 -0800 (PST) Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.3.5.0; Thu, 1 Dec 2011 02:10:26 -0800 Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.2.247.5; Thu, 1 Dec 2011 02:10:26 -0800 Received: from DF-M14-11.exchange.corp.microsoft.com ([fe80::cc46:3da5:bed6:8dfc]) by PIO-MLT-06.exchange.corp.microsoft.com ([fe80::d57f:521a:3ae6:c130%10]) with mapi id 14.03.0005.000; Thu, 1 Dec 2011 02:10:26 -0800 From: Trevor Freeman To: Antoin Verschuren , "dane@ietf.org" Thread-Topic: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) Thread-Index: AQHMr4F4WMy/naAnPE6fgynnfAgMTpXGbz8AgADWuAD//3xtwA== Date: Thu, 1 Dec 2011 10:10:25 +0000 Message-ID: References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <4ED74F32.3020302@sidn.nl> In-Reply-To: <4ED74F32.3020302@sidn.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 10:10:42 -0000 SWYgdGhlIHZhbGlkYXRpb24gc3RhdGUgaXMgbm90IHNlY3VyZSAtIGl0IE1VU1QgYmUgYSBtYXR0 ZXIgb2YgbG9jYWwgcG9saWN5IHdoYXQgdG8gZG8uIFlvdSBjYW5ub3QgZGljdGF0ZSBob3cgdG8g aGFuZGxlIHRoYXQgZmFpbHVyZSBvbmx5IHRoYXQgaXQgaXMgYW4gaW5zZWN1cmUgY29ubmVjdGlv bi4gVGhlIGFwcGxpY2F0aW9uIGJlaGF2aW9yIG1heSBiZSB0byBmYWxsIGJhY2sgdXNlIGFuIGlu c2VjdXJlIGNvbm5lY3Rpb24gaW4gd2hpY2ggY2FzZSB5b3UgbWF5IGFzIHdlbGwgZ28gYWhlYWQg YW5kIHVzZSB0aGUgaW5zZWN1cmUgVExTIHByb3RlY3RlZCBjb25uZWN0aW9uDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkYW5lLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpk YW5lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbnRvaW4gVmVyc2NodXJlbg0KU2Vu dDogVGh1cnNkYXksIERlY2VtYmVyIDAxLCAyMDExIDM6MjYgUE0NClRvOiBkYW5lQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW2RhbmVdIENhbGwgZm9yIGNvbnNlbnN1cyBvbiBsZXZlbCBvZiBETlNT RUMgc3VwcG9ydCAoU2VjdXJpdHktYXdhcmUgU3R1YiBSZXNvbHZlciBpbiBEQU5FLWF3YXJlIGFw cGxpY2F0aW9uKQ0KDQotLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tDQpIYXNoOiBT SEExDQoNCk9uIDMwLTExLTExIDIyOjA3LCBPbmTFmWVqIFN1csO9IHdyb3RlOg0KDQo+IA0KPiAt LW5ldyB0ZXh0LS0NCj4gICAgQW4gYXBwbGljYXRpb24gdGhhdCBjb21wbGllcyB3aXRoIHRoaXMg ZG9jdW1lbnQgZmlyc3QgcmVxdWVzdHMgVExTQQ0KPiAgICByZWNvcmRzIGluIG9yZGVyIHRvIG1h a2UgY2VydGlmaWNhdGUgYXNzb2NpYXRpb25zLg0KPiANCj4gICAgRGV0ZXJtaW5pbmcgd2hldGhl ciBhIFRMU0EgUlJzZXQgY2FuIGJlIHVzZWQgZGVwZW5kcw0KPiAgICBvbiB0aGUgRE5TU0VDIHZh bGlkYXRpb24gc3RhdGUgKGFzIGRlZmluZWQgaW4gW1JGQzQwMzNdKS4NCj4gDQo+ICAgIG8gQSBU TFNBIFJSc2V0IHdob3NlIEROU1NFQyB2YWxpZGF0aW9uIHN0YXRlIGlzIHNlY3VyZSBNQVkgYmUg dXNlZA0KPiAgICAgIGFzIGEgY2VydGlmaWNhdGUgYXNzb2NpYXRpb24gZm9yIFRMUy4NCj4gDQo+ ICAgIG8gSWYgdGhlIEROU1NFQyB2YWxpZGF0aW9uIHN0YXRlIG9uIHRoZSByZXNwb25zZSB0byB0 aGUgcmVxdWVzdA0KPiAgICAgIGZvciB0aGUgVExTQSBSUnNldCBpcyBib2d1cywgdGhpcyBNVVNU IGNhdXNlIFRMUyBub3QgdG8gYmUgc3RhcnRlZA0KPiAgICAgIG9yLCBpZiB0aGUgVExTIG5lZ290 aWF0aW9uIGlzIGFscmVhZHkgaW4gcHJvZ3Jlc3MsIHRvIGNhdXNlDQo+ICAgICAgdGhlIGNvbm5l Y3Rpb24gdG8gYmUgYWJvcnRlZC4NCj4gDQo+ICAgIG8gQSBUTFNBIFJSc2V0IHdob3NlIEROU1NF QyB2YWxpZGF0aW9uIHN0YXRlIGlzIGluZGV0ZXJtaW5hdGUgb3INCj4gICAgICBpbnNlY3VyZSBj YW5ub3QgYmUgdXNlZCBmb3IgVExTIGFuZCBNVVNUIGJlIG1hcmtlZCBhcyB1bnVzYWJsZS4NCj4g LS1uZXcgdGV4dC0tDQoNCisxDQoNCkkgaG9wZSB0aG91Z2ggdGhhdCBpbXBsZW1lbnRlcnMgd2ls bCB3YXJuIG1lIHdoZW4gdGhlIGluZGV0ZXJtaW5hdGUgb3IgaW5zZWN1cmUgY2FzZSBjYXVzZXMg b3RoZXIgVExTIHZhbGlkYXRpb24gdG8gb2NjdXIgYW5kIEknbSBub3QgZG9pbmcgREFORSwgc28g SSBjYW4gYmUgZXh0cmEgY2FyZWZ1bGwuDQoNCi0gLS0NCkFudG9pbiBWZXJzY2h1cmVuDQoNClRl Y2huaWNhbCBQb2xpY3kgQWR2aXNvciBTSURODQpNZWFuZGVyIDUwMSwgUE8gQm94IDUwMjIsIDY4 MDIgRUEgQXJuaGVtLCBUaGUgTmV0aGVybGFuZHMNCg0KUDogKzMxIDI2IDM1MjU1MDAgIEY6ICsz MSAyNiAzNTI1NTA1ICBNOiArMzEgNiAyMzM2ODk3MCBtYWlsdG86YW50b2luLnZlcnNjaHVyZW5A c2lkbi5ubCAgeG1wcDphbnRvaW5AamFiYmVyLnNpZG4ubmwgaHR0cDovL3d3dy5zaWRuLm5sLyAt LS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KVmVyc2lvbjogR251UEcgdjEuNC4xMSAoR05V L0xpbnV4KQ0KDQppUUVjQkFFQkFnQUdCUUpPMTA4eUFBb0pFRHFIck04ODNBZ25pTjRIL2lGQ2lz VzlJR0kvMWJmS3JGUnVrSXJYDQo1MzQ3MEczWXFjamlJQmJJYU0xZzl1M21FL3EvcTUva281VDA3 ZWtMNkJFREZPbUhpOGkwMWtQRVRnZHhveXI3DQorWUUvQUxJSklkUVRhbHdEdk9KdWFNZDdqSXNo bEpXS0JYQnh6NkJRYTZBZVhXUG5Hd0wrZUJWSEhFVXp5Z1NJDQpWZ0hNbmI4WTlHRlNQKzdid3pW ZGtqeXRZNTNBRm4rR2FyRHd2aWdKcmZtNzZOZ2h6bkoxTUNOaGhPaUJtOWJuDQo3NEE3TXdDRTdy YngzU3FmOGlWanFIT3dVS0RCM2xZMm8raEl1VmhlOXhBL1pkdEFqaUorRXZDb2hIL0lDSHgxDQo4 UHNwTjc4ZDluQVdIeHBPVXlVak10WUFlUlZnV0pFa25WeWliT3Zta0d6SzBOOUp5VW9yTnVKejk0 VTNmME09DQo9Z1VxRw0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZGFuZSBtYWlsaW5nIGxpc3QNCmRh bmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGFuZQ0K From fanf2@hermes.cam.ac.uk Thu Dec 1 03:41:54 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7611621F8ABB for ; Thu, 1 Dec 2011 03:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-ZW-JSUGvr5 for ; Thu, 1 Dec 2011 03:41:53 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8D121F8A7A for ; Thu, 1 Dec 2011 03:41:53 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:36358) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1RW51M-0000by-qY (Exim 4.72) (return-path ); Thu, 01 Dec 2011 11:41:44 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RW51M-0002un-8L (Exim 4.67) (return-path ); Thu, 01 Dec 2011 11:41:44 +0000 Date: Thu, 1 Dec 2011 11:41:44 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Martin Rex In-Reply-To: <201111302312.pAUNC5d1006389@fs4113.wdf.sap.corp> Message-ID: References: <201111302312.pAUNC5d1006389@fs4113.wdf.sap.corp> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 11:41:54 -0000 Martin Rex wrote: > > If you have a roaming device with a secure resolver (i.e. the root > zone key locally configured) and you are either a static host and > behind a middle box that impairs DNS lookups but lets DS records pass, > or a mobile host that is caching DNS records (including DS records > for a zone) and you roam to an area where a middlebox prevents you > from further receiving some of the zones records for whatever reason > so that you can not perform a signature verification, > then both 4033 and 4035 say that all lookups for that zone > are to be flagged as "bogus". > > I believe DANE should avoid creating new interop problems. These are DNSSEC problems not DANE problems, so should be dealt with in the dnsext and dnsop working groups. Tony. -- f.anthony.n.finch http://dotat.at/ Sole, Lundy, Fastnet: Westerly veering northerly 4 or 5, occasionally 6, increasing 7 in west Sole. Rough or very rough, occasionally high in west Sole. Squally showers. Mainly good. From ajs@anvilwalrusden.com Thu Dec 1 04:58:41 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F34A21F8B51 for ; Thu, 1 Dec 2011 04:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARKfMeGRw7Cm for ; Thu, 1 Dec 2011 04:58:40 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id AE75921F8B00 for ; Thu, 1 Dec 2011 04:58:40 -0800 (PST) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E90DF1ECB420 for ; Thu, 1 Dec 2011 12:58:23 +0000 (UTC) Date: Thu, 1 Dec 2011 07:58:40 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111201124746.GA61329@shinkuro.com> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 12:58:41 -0000 On Wed, Nov 30, 2011 at 07:55:22PM -0800, Zack Weinberg wrote: > I don't think DANE should override a local determination that some > certificate is never to be trusted (explicit blacklist, that is, not > just default-untrusted). Can we make sure we allow local policy to do > that? Isn't that exactly the sort of thing the MAY (that people seem uneasy about) permits? A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Thu Dec 1 05:09:12 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3488B21F8B02 for ; Thu, 1 Dec 2011 05:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDinMr0tu3Gf for ; Thu, 1 Dec 2011 05:09:11 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id A805921F8DBC for ; Thu, 1 Dec 2011 05:09:11 -0800 (PST) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 609F21ECB420 for ; Thu, 1 Dec 2011 13:08:55 +0000 (UTC) Date: Thu, 1 Dec 2011 08:09:11 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111201130911.GB61329@shinkuro.com> References: <201111302312.pAUNC5d1006389@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111302312.pAUNC5d1006389@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 13:09:12 -0000 On Thu, Dec 01, 2011 at 12:12:05AM +2500, Martin Rex wrote: > If you have a roaming device with a secure resolver (i.e. the root > zone key locally configured) and you are either a static host and > behind a middle box that impairs DNS lookups but lets DS records pass, > or a mobile host that is caching DNS records (including DS records > for a zone) and you roam to an area where a middlebox prevents you > from further receiving some of the zones records for whatever reason > so that you can not perform a signature verification, > then both 4033 and 4035 say that all lookups for that zone > are to be flagged as "bogus". > > > I believe DANE should avoid creating new interop problems. Of course they're flagged as bogus. They _are_ bogus. Something is standing in the way and removing DNS data. That's a MITM, and it's exactly what DNSSEC is supposed to detect. What's the problem? This is like claiming that there's some special interop problem created by IMAP because a lot of hotel networks only permit connections on port 80. It's the network that's broken in that case, and DANE isn't creating a new interop problem. If, however, you don't like this feature of DANE, don't use it. Surely nobody is forcing you to do so. A -- Andrew Sullivan ajs@anvilwalrusden.com From peter@denic.de Thu Dec 1 05:17:22 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB8E21F8B6E for ; Thu, 1 Dec 2011 05:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvrWaNM3emGG for ; Thu, 1 Dec 2011 05:17:22 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB1B21F8D21 for ; Thu, 1 Dec 2011 05:17:22 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1RW6Vs-0005p3-Ff; Thu, 01 Dec 2011 14:17:20 +0100 Received: from localhost by x27.adm.denic.de with local id 1RW6Vs-0001ZV-Bt; Thu, 01 Dec 2011 14:17:20 +0100 Date: Thu, 1 Dec 2011 14:17:20 +0100 From: Peter Koch To: dane@ietf.org Message-ID: <20111201131720.GG17317@x27.adm.denic.de> Mail-Followup-To: dane@ietf.org References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111201124746.GA61329@shinkuro.com> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 13:17:22 -0000 On Thu, Dec 01, 2011 at 07:58:40AM -0500, Andrew Sullivan wrote: > > just default-untrusted). Can we make sure we allow local policy to do > > that? > > Isn't that exactly the sort of thing the MAY (that people seem uneasy > about) permits? if all else fails, ..., RFC 2119, section 5: 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) The use of the normative language has 'evolved' over time, though, but it doesn't seem like MAY was invented to permit "local policy". -Peter From ajs@crankycanuck.ca Thu Dec 1 07:09:20 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E99921F9114 for ; Thu, 1 Dec 2011 07:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVzP6JWyCsUl for ; Thu, 1 Dec 2011 07:09:20 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id ECDA621F903D for ; Thu, 1 Dec 2011 07:09:19 -0800 (PST) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7E1531ECB420 for ; Thu, 1 Dec 2011 15:09:03 +0000 (UTC) Date: Thu, 1 Dec 2011 10:09:17 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111201150917.GC61329@shinkuro.com> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> <20111201131720.GG17317@x27.adm.denic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111201131720.GG17317@x27.adm.denic.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 15:09:20 -0000 On Thu, Dec 01, 2011 at 02:17:20PM +0100, Peter Koch wrote: > On Thu, Dec 01, 2011 at 07:58:40AM -0500, Andrew Sullivan wrote: > > > > just default-untrusted). Can we make sure we allow local policy to do > > > that? > > > > Isn't that exactly the sort of thing the MAY (that people seem uneasy > > about) permits? > > if all else fails, ..., RFC 2119, section 5: > > 5. MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the same item. > An implementation which does not include a particular option MUST be > prepared to interoperate with another implementation which does > include the option, though perhaps with reduced functionality. In the > same vein an implementation which does include a particular option > MUST be prepared to interoperate with another implementation which > does not include the option (except, of course, for the feature the > option provides.) > > The use of the normative language has 'evolved' over time, though, but > it doesn't seem like MAY was invented to permit "local policy". I always read that text as _exactly_ permitting local policy, among other things, particularly when one is specifying how one is to do something locally. That is, the MAY in question tells others (from an interoperability perspective) that you might do something with the DNSSEC-signed TLSA record, and you might not. If I'm the site providing the TLSA record with its DNSSEC signature, you'd be a fool not to do something with that record, but that's your decision and it doesn't affect me at all. From the POV of _inter_operation, the only things I can rely on are that you might use the TLSA record if it's valid, you won't do TLS if you can't validate it, and if you get a bogus record you will nto connect at all. So for the purposes of this case, I would say that MAY does so permit the local policy. A -- Andrew Sullivan ajs@crankycanuck.ca From ogud@ogud.com Thu Dec 1 08:00:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A650911E80E0 for ; Thu, 1 Dec 2011 08:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPosDVc9D3i0 for ; Thu, 1 Dec 2011 08:00:19 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id EFEA911E822D for ; Thu, 1 Dec 2011 08:00:18 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id pB1G0GBV087240 for ; Thu, 1 Dec 2011 11:00:17 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4ED7A491.2020305@ogud.com> Date: Thu, 01 Dec 2011 11:00:17 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dane@ietf.org References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> In-Reply-To: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 16:00:19 -0000 +1 This captures quite well what I proposed. Olafur Ps: I agree with the change in wording proposed by Peter Koch On 30/11/2011 16:07, OndÅ™ej Surý wrote: > In a hope to clear at least some of the confusion, here's the > text which replaces last paragraph in 4.4, which is NOW: > > --old text from -12-- > An application that complies with this document first requests TLSA > records in order to make certificate associations. If that > application receives zero usable certificate associations, it > processes TLS in the normal fashion; otherwise, that application > attempts to match each certificate association with the TLS server's > end entity certificate. If such a match is found, that application > continues the TLS handshake and ignores any remaining certificate > associations; otherwise, that application MUST abort the TLS > handshake with an "access_denied" error. > --old text from -12-- > > which becomes: > > --new text-- > An application that complies with this document first requests TLSA > records in order to make certificate associations. > > Determining whether a TLSA RRset can be used depends > on the DNSSEC validation state (as defined in [RFC4033]). > > o A TLSA RRset whose DNSSEC validation state is secure MAY be used > as a certificate association for TLS. > > o If the DNSSEC validation state on the response to the request > for the TLSA RRset is bogus, this MUST cause TLS not to be started > or, if the TLS negotiation is already in progress, to cause > the connection to be aborted. > > o A TLSA RRset whose DNSSEC validation state is indeterminate or > insecure cannot be used for TLS and MUST be marked as unusable. > --new text-- > > Note: Please read whole text and not just bullets. E.g. in all other > possible (undefined here) cases the TLSA RRset cannot be used. > > From paul.hoffman@vpnc.org Thu Dec 1 08:30:07 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CE711E8231 for ; Thu, 1 Dec 2011 08:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0AZHk--EFoT for ; Thu, 1 Dec 2011 08:30:07 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4A35811E822D for ; Thu, 1 Dec 2011 08:30:07 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pB1GU6Us031061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 1 Dec 2011 09:30:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <357B474A-A161-45CC-888C-F867869FD72B@bbn.com> Date: Thu, 1 Dec 2011 08:30:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <357B474A-A161-45CC-888C-F867869FD72B@bbn.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 16:30:07 -0000 On Nov 30, 2011, at 8:03 PM, Richard L. Barnes wrote: > Do we really need to say anything about this? =20 Yes. In many other security WGs, people have argued against MUST = language in places where trust is applied. This clarifies that the = certificate assertion is available, not mandated at all times. We could possibly use "SHOULD use except where local policy overrides", = but I find that more confusing. Others might want it, however. > ISTM that local policy can always override. =20 Right. > Keep in mind that DANE validation is a part of the overall certificate = acceptance process. There are already other checks (e.g., name checks) = that get applied by the application layer; checking blacklists could be = part of that. Those checks happen during PKIX processing, which starts after the DANE = processing. It would be better if we didn't combine the two. For = example... > Besides, if you see the cert and it's on your black-list, why would = you go to the trouble of invoking DANE? =20 Most applications will do DANE before they start the TLS negotiation, so = they won't have the cert in hand. Again, assuming that DANE is being = done *while* the TLS handshake is in progress is a bad assumption. --Paul Hoffman From ondrej.mikle@nic.cz Thu Dec 1 09:02:59 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99551F0C72 for ; Thu, 1 Dec 2011 09:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdSmkCgogZyH for ; Thu, 1 Dec 2011 09:02:59 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 139DE1F0C71 for ; Thu, 1 Dec 2011 09:02:59 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2] (unknown [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2]) by mail.nic.cz (Postfix) with ESMTPSA id 203122A2C25 for ; Thu, 1 Dec 2011 18:02:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1322758978; bh=+0xbn4kVtTmLjykcmM9B/vn+7ytkuzdIdM2DxL0mWuM=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=OUEQdq0iDUE9vN+rN6ngsaRopFhp+GuVK+ZFC5tns0dW35jUDrprjW+QoBJiBV9j1 MYiZVE1bAM09S+emxeWd8cMrFembUkXSQktfigmZWzF1R1/BkzT9Tefxs0+xineJS9 lgpNylOdCf0DV3FMR4mjTgQUYE1gq6XpKVi3NmQE= Message-ID: <4ED7B326.4020704@nic.cz> Date: Thu, 01 Dec 2011 18:02:30 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Red Hat/3.1.16-2.el6_1 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] Addition to "Security considerations" section - usage type 0 with SubjectPublicKeyInfo selector X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 17:02:59 -0000 Hi, I've written a proposal for addition to "Security considerations" section covering what was said in the "Fragility of binding..." threads about association by SPKI and client-side PKIX validation. Possibly the "should's" are too strong for someone's liking. ---begin text--- DNS administrators SHOULD use selector type 1 (SubjectPublicKeyInfo) in TLSA records where certificate usage field is 0. Many TLS clients exchange intermediate certificates in chains sent by server while performing PKIX validation. Reason for such behavior is that CA certificates are often reissued: with different expiry dates, stronger hashing algorithm, etc. If the aforementioned TLSA record used selector type 0 (full certificate), it might cause interoperability problems for TLS client that swapped CA certificate for one with identical public key. TLSA record with usage type 0 SHOULD NOT associate with a cross-certificate. TLS clients often cut certificate chain short once the client reaches an intermediate certificate which chains to a trust anchor in client's trusted certificate store. Association with a cross-certificate would be thus rejected by the client. It is RECOMMENDED that the association is made with a CA certificate that directly signed the leaf certificate since it gives the most predictable processing on client's side. ---end text--- Ondrej Mikle From paul.hoffman@vpnc.org Thu Dec 1 09:09:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0BC1F0C70 for ; Thu, 1 Dec 2011 09:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLztZCBJdsEZ for ; Thu, 1 Dec 2011 09:09:16 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 101861F0C61 for ; Thu, 1 Dec 2011 09:09:10 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pB1H98Pc034905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Dec 2011 10:09:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4ED7B326.4020704@nic.cz> Date: Thu, 1 Dec 2011 09:09:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6997ED7D-A028-487A-BBF0-0888FE9E4CE4@vpnc.org> References: <4ED7B326.4020704@nic.cz> To: Ondrej Mikle X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Addition to "Security considerations" section - usage type 0 with SubjectPublicKeyInfo selector X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 17:09:16 -0000 First: thanks for providing text! It's so rare these days... On Dec 1, 2011, at 9:02 AM, Ondrej Mikle wrote: > I've written a proposal for addition to "Security considerations" = section covering what was said in the "Fragility of binding..." threads = about association by SPKI and client-side PKIX validation. Possibly the = "should's" are too strong for someone's liking. I generally really dislike 2119 language in "security considerations" = because that is normative language. In this specific case, I think it is = too strong anyhow, but can be managed easily. > ---begin text--- >=20 > DNS administrators SHOULD use selector type 1 (SubjectPublicKeyInfo) = in TLSA records where certificate usage field is 0. Many TLS clients = exchange intermediate certificates in chains sent by server while = performing PKIX validation. Reason for such behavior is that CA = certificates are often reissued: with different expiry dates, stronger = hashing algorithm, etc. If the aforementioned TLSA record used selector = type 0 (full certificate), it might cause interoperability problems for = TLS client that swapped CA certificate for one with identical public = key. >=20 > TLSA record with usage type 0 SHOULD NOT associate with a = cross-certificate. TLS clients often cut certificate chain short once = the client reaches an intermediate certificate which chains to a trust = anchor in client's trusted certificate store. Association with a = cross-certificate would be thus rejected by the client. It is = RECOMMENDED that the association is made with a CA certificate that = directly signed the leaf certificate since it gives the most predictable = processing on client's side. >=20 > ---end text--- Instead, how about "DNS administrators should strongly consider using = selector type 1 (SubjectPublicKeyInfo) in TLSA records where certificate = usage field is 0 because many TLS clients...", with a similar type of = change for the second paragraph? --Paul Hoffman From zack.weinberg@gmail.com Thu Dec 1 09:42:23 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5561F0C7B for ; Thu, 1 Dec 2011 09:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ndi0tBQvdd8E for ; Thu, 1 Dec 2011 09:42:22 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BD5851F0C36 for ; Thu, 1 Dec 2011 09:42:19 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so1883182vcb.31 for ; Thu, 01 Dec 2011 09:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ikC48o9nEnkS8wHLCjDw4NwmoBibUwjnX2iNwwHp4rg=; b=Wy9ICUevVFGkvokVaerHBYJlfwA3Ijq8dt56lmZ4Z4uv/EOGMehMsDOxcvSbbccHKp hRTwbS6ZxGXFmfvqgKjvFoTYS1NfV9HYuPjPqnOzwaCvAz6xkpOoqdpKAy8l9awE+jPQ xoGjw4KAx4csdrbM+/tbjlxMJ9L28iwX5b6gE= MIME-Version: 1.0 Received: by 10.182.118.67 with SMTP id kk3mr1330387obb.27.1322761339245; Thu, 01 Dec 2011 09:42:19 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.88.103 with HTTP; Thu, 1 Dec 2011 09:42:19 -0800 (PST) In-Reply-To: <4ED7B326.4020704@nic.cz> References: <4ED7B326.4020704@nic.cz> Date: Thu, 1 Dec 2011 09:42:19 -0800 X-Google-Sender-Auth: LE3HreUn6Oh1r6X_w5yfK3oLIhE Message-ID: From: Zack Weinberg To: Ondrej Mikle Content-Type: text/plain; charset=UTF-8 Cc: dane@ietf.org Subject: Re: [dane] Addition to "Security considerations" section - usage type 0 with SubjectPublicKeyInfo selector X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 17:42:23 -0000 On Thu, Dec 1, 2011 at 9:02 AM, Ondrej Mikle wrote: > Hi, > > I've written a proposal for addition to "Security considerations" section > covering what was said in the "Fragility of binding..." threads about > association by SPKI and client-side PKIX validation. Possibly the "should's" > are too strong for someone's liking. Thanks! This was on my list of things to file as issues. It seems to me that this is valuable to have, but it's not a _security_ consideration. Can I suggest that we add an "operational considerations" section covering this and anything else that's useful for operators to know but not security-critical? zw From warren@kumari.net Thu Dec 1 10:09:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5351F0C76 for ; Thu, 1 Dec 2011 10:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf+d84BspINS for ; Thu, 1 Dec 2011 10:09:45 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id E54401F0C72 for ; Thu, 1 Dec 2011 10:09:44 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 177831B40424; Thu, 1 Dec 2011 13:09:44 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <4ED7B326.4020704@nic.cz> Date: Thu, 1 Dec 2011 13:09:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4ED7B326.4020704@nic.cz> To: Ondrej Mikle X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Addition to "Security considerations" section - usage type 0 with SubjectPublicKeyInfo selector X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 18:09:45 -0000 On Dec 1, 2011, at 12:02 PM, Ondrej Mikle wrote: > Hi, >=20 > I've written a proposal for addition to "Security considerations" = section covering what was said in the "Fragility of binding..." threads = about association by SPKI and client-side PKIX validation. Possibly the = "should's" are too strong for someone's liking. Awesome, thank you for text, it makes discussions *much* clearer and = consensus *much* easier to judge. >=20 > ---begin text--- >=20 > DNS administrators SHOULD use selector type 1 (SubjectPublicKeyInfo) = in TLSA records where certificate usage field is 0. Many TLS clients = exchange intermediate certificates in chains sent by server while = performing PKIX validation. Reason for such behavior is that CA = certificates are often reissued: with different expiry dates, stronger = hashing algorithm, etc. If the aforementioned TLSA record used selector = type 0 (full certificate), it might cause interoperability problems for = TLS client that swapped CA certificate for one with identical public = key. >=20 > TLSA record with usage type 0 SHOULD NOT associate with a = cross-certificate. TLS clients often cut certificate chain short once = the client reaches an intermediate certificate which chains to a trust = anchor in client's trusted certificate store. Association with a = cross-certificate would be thus rejected by the client. It is = RECOMMENDED that the association is made with a CA certificate that = directly signed the leaf certificate since it gives the most predictable = processing on client's side. >=20 > ---end text--- Hmmm, I like the text, but how would you feel about having this text in = the "Operational Considerations for Deploying TLSA Records" section = instead of the "Security Considerations" section? It feels like it it more operational in nature to me.... W >=20 > Ondrej Mikle > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From ondrej.sury@nic.cz Thu Dec 1 11:15:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B8321F90E0 for ; Thu, 1 Dec 2011 11:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hkqr-cIOXZdN for ; Thu, 1 Dec 2011 11:15:16 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C533421F9082 for ; Thu, 1 Dec 2011 11:15:15 -0800 (PST) Received: from [10.0.0.12] (173.5.broadband15.iol.cz [90.182.5.173]) by mail.nic.cz (Postfix) with ESMTPSA id 569992A0056; Thu, 1 Dec 2011 20:15:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1322766912; bh=gsgaMofIAlaq+b3DCin1VAWUFykk6WP7X+2nn5DbN5Y=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=I1nI2rTpUI6SHAZaMpBTL1fGI+Mx4fSyHDicpcrGKYI/fPuLuh+folusvDb+o5d5t YTS/RWuHxBThx8QZuHCaIJ6oOnBlkDjUQgW2+ZIgvhp+nwtIEps6/VUiUX4zLaSMhr BIw67LXsjjQZvh/80vZaeIXPOVb8RkdPHjHRfs0E= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20111201131720.GG17317@x27.adm.denic.de> Date: Thu, 1 Dec 2011 20:15:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8D71ACF1-A834-4B14-8FE6-56EC72F77CC5@nic.cz> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> <20111201131720.GG17317@x27.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: [dane] RFC2119 MAY (Was: Call for consensus on level of DNSSEC support) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 19:15:17 -0000 So can we use 'can' instead of MAY? > Determining whether a TLSA RRset can be used depends > on the DNSSEC validation state (as defined in [RFC4033]). We are asking 'whether X can be used' > o A TLSA RRset whose DNSSEC validation state is secure can be used > as a certificate association for TLS. We are saying: 'Yes, it can be used'. I may be wrong, but I don't see a need for normative MAY here. O. On 1. 12. 2011, at 14:17, Peter Koch wrote: > On Thu, Dec 01, 2011 at 07:58:40AM -0500, Andrew Sullivan wrote: >=20 >>> just default-untrusted). Can we make sure we allow local policy to = do >>> that? >>=20 >> Isn't that exactly the sort of thing the MAY (that people seem uneasy >> about) permits? >=20 > if all else fails, ..., RFC 2119, section 5: >=20 > 5. MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the same item. > An implementation which does not include a particular option MUST be > prepared to interoperate with another implementation which does > include the option, though perhaps with reduced functionality. In = the > same vein an implementation which does include a particular option > MUST be prepared to interoperate with another implementation which > does not include the option (except, of course, for the feature the > option provides.) >=20 > The use of the normative language has 'evolved' over time, though, but > it doesn't seem like MAY was invented to permit "local policy". >=20 > -Peter > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ajs@anvilwalrusden.com Thu Dec 1 11:26:43 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5301F0C54 for ; Thu, 1 Dec 2011 11:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mAjI30U8mHv for ; Thu, 1 Dec 2011 11:26:41 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id BE6731F0C4D for ; Thu, 1 Dec 2011 11:25:36 -0800 (PST) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E3DA21ECB420 for ; Thu, 1 Dec 2011 19:25:19 +0000 (UTC) Date: Thu, 1 Dec 2011 14:25:33 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111201192533.GS61329@shinkuro.com> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> <20111201131720.GG17317@x27.adm.denic.de> <8D71ACF1-A834-4B14-8FE6-56EC72F77CC5@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8D71ACF1-A834-4B14-8FE6-56EC72F77CC5@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] RFC2119 MAY (Was: Call for consensus on level of DNSSEC support) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 19:26:43 -0000 On Thu, Dec 01, 2011 at 08:15:09PM +0100, OndÅ™ej Surý wrote: > I may be wrong, but I don't see a need for normative MAY here. I don't care one way or another. A -- Andrew Sullivan ajs@anvilwalrusden.com From ondrej.sury@nic.cz Thu Dec 1 11:29:30 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E96111E8095 for ; Thu, 1 Dec 2011 11:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nan2ZwUJJVl1 for ; Thu, 1 Dec 2011 11:29:29 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A33BA21F9023 for ; Thu, 1 Dec 2011 11:29:29 -0800 (PST) Received: from [10.0.0.12] (173.5.broadband15.iol.cz [90.182.5.173]) by mail.nic.cz (Postfix) with ESMTPSA id BD6FC2A03DA; Thu, 1 Dec 2011 20:29:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1322767768; bh=cyiuYoh3iEPY2BUG5T9XrNpli1wzAT99/uoKBaF2Yg4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qdFr0yql2DE1yEgYd1XeIkumoMOMmaqqxctY/0u4BQVbFE6o052m2V+oHXkOV5qUm kULPPG5xmt9D3QKg2MqLU1plaYCUiETjfWjoav8Mg28BrxudMpQjXLis/4BQ7PwSAX DpnURDANlHvVoCDdH/fK1SEL+DhraRU4V3PEVnbo= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Thu, 1 Dec 2011 20:29:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6AE9B0EE-FF71-4184-8489-89E34A340E32@nic.cz> References: <4ED7B326.4020704@nic.cz> To: Warren Kumari X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Addition to "Security considerations" section - usage type 0 with SubjectPublicKeyInfo selector X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 19:29:30 -0000 On 1. 12. 2011, at 19:09, Warren Kumari wrote: > > Hmmm, I like the text, but how would you feel about having this text = in the "Operational Considerations for Deploying TLSA Records" section = instead of the "Security Considerations" section? > It feels like it it more operational in nature to me.... > That was my silly idea in a first place, since I didn't realize that we = already have Operational Considerations when we talked about these = issues today. So I think that Operational Considerations are better = place... O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From mrex@sap.com Thu Dec 1 11:36:50 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C586E11E8139 for ; Thu, 1 Dec 2011 11:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.973 X-Spam-Level: X-Spam-Status: No, score=-9.973 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCTdmTtK4qgx for ; Thu, 1 Dec 2011 11:36:50 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id EBC3211E8095 for ; Thu, 1 Dec 2011 11:36:49 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pB1JajcY010696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Dec 2011 20:36:45 +0100 (MET) From: Martin Rex Message-Id: <201112011936.pB1JaiKG014906@fs4113.wdf.sap.corp> To: ajs@anvilwalrusden.com (Andrew Sullivan) Date: Thu, 1 Dec 2011 20:36:44 +0100 (MET) In-Reply-To: <20111201130911.GB61329@shinkuro.com> from "Andrew Sullivan" at Dec 1, 11 08:09:11 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 19:36:50 -0000 Andrew Sullivan wrote: > > On Thu, Dec 01, 2011 at 12:12:05AM +2500, Martin Rex wrote: > > > > If you have a roaming device with a secure resolver (i.e. the root > > zone key locally configured) and you are either a static host and > > behind a middle box that impairs DNS lookups but lets DS records pass, > > or a mobile host that is caching DNS records (including DS records > > for a zone) and you roam to an area where a middlebox prevents you > > from further receiving some of the zones records for whatever reason > > so that you can not perform a signature verification, > > then both 4033 and 4035 say that all lookups for that zone > > are to be flagged as "bogus". > > > > > > I believe DANE should avoid creating new interop problems. > > Of course they're flagged as bogus. They _are_ bogus. Something is > standing in the way and removing DNS data. That's a MITM, and it's > exactly what DNSSEC is supposed to detect. What's the problem? There may be too many non-malicous middleboxes that perform DNS-MITM as a service (as recursive resolver or forwarding resolver) on network edges in the installed base. The use of DHCP is extremely common. The only situation when I would actively support aborting the connection for "bogus" is when the entire set of DNS records has been conveyed by the server to the client in-band with a TLS extension. This is the situation where a reliable transport is used end-to-end, and the server can be held responsible for providing incorrect data. But even in that situation there is a huge caveat: What about root key roll-over? How will a client that is behind a dense middle-box be able to roll the DNS root key? > > This is like claiming that there's some special interop problem > created by IMAP because a lot of hotel networks only permit > connections on port 80. It's the network that's broken in that case, > and DANE isn't creating a new interop problem. This particular discussion is about usage types 0/1 that require that the servers certificate can be successfully validated under the TLS X.509 PKI and the server endpoint identity match succeeds. The hotel networks (and firewalled company networks) may be permitting outbound access to port 443 in addition to accessing port 80. If adding support for DANE creates new interop problem, because of DANE not being able to obtain all necessary DNS records to reliably perform a validation, then we're doing the users a disservice (they will either switch it off entirely or be desensitized). And if that happens often enough, then users will be sufficiently conditioned to either regularly ignore DANE-related warnings or entirely switch it off, with the effect that DANE validation failures will be ignored, even for DNSSEC secure results. -Martin From jim@rfc1035.com Thu Dec 1 12:08:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F1311E815C for ; Thu, 1 Dec 2011 12:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kG8rJMnh4kAP for ; Thu, 1 Dec 2011 12:08:10 -0800 (PST) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id BD30011E8141 for ; Thu, 1 Dec 2011 12:08:10 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id 9767ECBC44C; Thu, 1 Dec 2011 20:08:07 +0000 (GMT) Message-Id: <6316719A-E602-462F-BB74-8B91E15F398E@rfc1035.com> From: Jim Reid To: mrex@sap.com In-Reply-To: <201112011936.pB1JaiKG014906@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Dec 2011 20:08:06 +0000 References: <201112011936.pB1JaiKG014906@fs4113.wdf.sap.corp> X-Mailer: Apple Mail (2.936) Cc: dane@ietf.org Subject: [dane] fixing DNSSEC problems that are out of scope for DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 20:08:11 -0000 On 1 Dec 2011, at 19:36, Martin Rex wrote: > How will a client that is behind a dense middle-box be able to roll > the DNS root key? This has nothing to do with this WG. Please ask in dsnop: that's the right place to discuss the operational issues surrounding DNSSEC deployment and validation. There are essentially two answers to your question. The first is move the client to a network that has working DNS. [Which may well be easier said than done.] This is no different from how the world already has to deal with middleboxes that mess up DNS packets. The second answer would be for the client to disable DNSSEC validation, slurp the new key and check it somehow by some out of band means -- handwave, handwave! -- do a manual rollover and then switch DNSSEC validation back on again. For dumb devices, that might well be achieved by a hard reset of the firmware or something lke that. From mrex@sap.com Thu Dec 1 12:16:17 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75F011E80EF for ; Thu, 1 Dec 2011 12:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvsMeFxEv7Eh for ; Thu, 1 Dec 2011 12:16:17 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D675A11E8089 for ; Thu, 1 Dec 2011 12:16:16 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pB1KGCml022423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Dec 2011 21:16:12 +0100 (MET) From: Martin Rex Message-Id: <201112012016.pB1KGB2R017286@fs4113.wdf.sap.corp> To: dot@dotat.at (Tony Finch) Date: Thu, 1 Dec 2011 21:16:11 +0100 (MET) In-Reply-To: from "Tony Finch" at Dec 1, 11 11:41:44 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 20:16:17 -0000 Tony Finch wrote: > > Martin Rex wrote: > > > > If you have a roaming device with a secure resolver (i.e. the root > > zone key locally configured) and you are either a static host and > > behind a middle box that impairs DNS lookups but lets DS records pass, > > or a mobile host that is caching DNS records (including DS records > > for a zone) and you roam to an area where a middlebox prevents you > > from further receiving some of the zones records for whatever reason > > so that you can not perform a signature verification, > > then both 4033 and 4035 say that all lookups for that zone > > are to be flagged as "bogus". > > > > I believe DANE should avoid creating new interop problems. > > These are DNSSEC problems not DANE problems, so should be dealt with in > the dnsext and dnsop working groups. They _already_ did. But the current proposals in DANE do not IMO not account for it. http://tools.ietf.org/html/rfc4033#section-6 If a security-aware resolver is separated from the relevant authoritative name servers by a recursive name server or by any sort of intermediary device that acts as a proxy for DNS, and if the recursive name server or intermediary device is not security-aware, the security-aware resolver may not be capable of operating in a secure mode. For example, if a security-aware resolver's packets are routed through a network address translation (NAT) device that includes a DNS proxy that is not security-aware, the security-aware resolver may find it difficult or impossible to obtain or validate signed DNS data. The security-aware resolver may have a particularly difficult time obtaining DS RRs in such a case, as DS RRs do not follow the usual DNS rules for ownership of RRs at zone cuts. Note that this problem is not specific to NATs: any security-oblivious DNS software of any kind between the security-aware resolver and the authoritative name servers will interfere with DNSSEC. If a security-aware resolver must rely on an unsigned zone or a name server that is not security aware, the resolver may not be able to validate DNS responses and will need a local policy on whether to accept unverified responses. Not being able to access a Web-Server with a non-PKIX cert (usage type 2) without DANE-warning behind a DNS-proxy is not a new interop problem, just the lack of a new feature. Newly being harassed with warnings when accessing a Web-Server with a PKIX-validating server cert (usage type 0/1) as soon as the DNS admin enables DNSSEC for the zone will be a *NEW* interop problem created by DANE if it recommends to abort on "Bogus". This could actually amount to a real deterrent of further DNSSEC deployment if we define DANE this way and browsers add support for DANE. -Martin From mrex@sap.com Thu Dec 1 12:21:58 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EECC1F0C40 for ; Thu, 1 Dec 2011 12:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.023 X-Spam-Level: X-Spam-Status: No, score=-10.023 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1hxLiDEXcip for ; Thu, 1 Dec 2011 12:21:57 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 849931F0C55 for ; Thu, 1 Dec 2011 12:21:56 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pB1KLsaT027761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Dec 2011 21:21:55 +0100 (MET) From: Martin Rex Message-Id: <201112012021.pB1KLsOM017495@fs4113.wdf.sap.corp> To: jim@rfc1035.com (Jim Reid) Date: Thu, 1 Dec 2011 21:21:54 +0100 (MET) In-Reply-To: <6316719A-E602-462F-BB74-8B91E15F398E@rfc1035.com> from "Jim Reid" at Dec 1, 11 08:08:06 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] fixing DNSSEC problems that are out of scope for DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 20:21:58 -0000 Jim Reid wrote: > > On 1 Dec 2011, at 19:36, Martin Rex wrote: > > > How will a client that is behind a dense middle-box be able to roll > > the DNS root key? > > This has nothing to do with this WG. Please ask in dsnop: that's the > right place to discuss the operational issues surrounding DNSSEC > deployment and validation. Not being able to roll the root key will lead to "bogus" state, for which DANE is trying to specify "ABORT". I disagree that this is a problem of other WGs. IMHO this is a pure DANE problem not following the advice from the designers of that technology. > > There are essentially two answers to your question. The first is move > the client to a network that has working DNS. [Which may well be > easier said than done.] This is no different from how the world > already has to deal with middleboxes that mess up DNS packets. The > second answer would be for the client to disable DNSSEC validation, > slurp the new key and check it somehow by some out of band means -- > handwave, handwave! -- do a manual rollover and then switch DNSSEC > validation back on again. For dumb devices, that might well be > achieved by a hard reset of the firmware or something lke that. IMHO obtaining full DNS transparency has the same complexity and likelyhood to happen quickly as IPv6 connectivity for all home customers. Both will require replacement of the customer premises equiment (CPE), often a router attached to or integrated with a DSL modem. -Martin From ajs@anvilwalrusden.com Thu Dec 1 12:46:04 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D3511E80A4 for ; Thu, 1 Dec 2011 12:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJQXeb+TPHsh for ; Thu, 1 Dec 2011 12:46:03 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6395F11E8089 for ; Thu, 1 Dec 2011 12:46:03 -0800 (PST) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D70F81ECB420 for ; Thu, 1 Dec 2011 20:45:46 +0000 (UTC) Date: Thu, 1 Dec 2011 15:46:00 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111201204600.GU61329@shinkuro.com> References: <201112012016.pB1KGB2R017286@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201112012016.pB1KGB2R017286@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 20:46:04 -0000 On Thu, Dec 01, 2011 at 09:16:11PM +0100, Martin Rex wrote: > Not being able to access a Web-Server with a non-PKIX cert (usage type 2) > without DANE-warning behind a DNS-proxy is not a new interop problem, > just the lack of a new feature. Yes. > Newly being harassed with warnings > when accessing a Web-Server with a PKIX-validating server cert > (usage type 0/1) as soon as the DNS admin enables DNSSEC for the zone > will be a *NEW* interop problem created by DANE if it recommends > to abort on "Bogus". Sure. So if you're one of the people faced with this problem, and you are on a broken network, turn off DNSSEC validation. DANE will say "can't use TLSA" and your life is good. It's not like the DNSSEC validation was doing you any good anyway. > This could actually amount to a real deterrent of further DNSSEC > deployment if we define DANE this way and browsers add support for DANE. If you are validating behind a broken proxy, DANE will not be the only thing that doesn't work. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Thu Dec 1 12:59:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CBD11E809D for ; Thu, 1 Dec 2011 12:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkx5s3JlTYSA for ; Thu, 1 Dec 2011 12:59:47 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3EE11E818C for ; Thu, 1 Dec 2011 12:59:47 -0800 (PST) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 037E21ECB420 for ; Thu, 1 Dec 2011 20:59:30 +0000 (UTC) Date: Thu, 1 Dec 2011 15:59:44 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111201205944.GV61329@shinkuro.com> References: <6316719A-E602-462F-BB74-8B91E15F398E@rfc1035.com> <201112012021.pB1KLsOM017495@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201112012021.pB1KLsOM017495@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] fixing DNSSEC problems that are out of scope for DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 20:59:47 -0000 On Thu, Dec 01, 2011 at 09:21:54PM +0100, Martin Rex wrote: > IMHO obtaining full DNS transparency has the same complexity and > likelyhood to happen quickly as IPv6 connectivity for all home customers. > Both will require replacement of the customer premises equiment (CPE), > often a router attached to or integrated with a DSL modem. Things might not be quite as bad as that, although there are certainly problems. We have a little bit of information, however: http://www.icann.org/en/committees/security/sac035.pdf A -- Andrew Sullivan ajs@anvilwalrusden.com From mrex@sap.com Thu Dec 1 13:11:41 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D351421F9399 for ; Thu, 1 Dec 2011 13:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.042 X-Spam-Level: X-Spam-Status: No, score=-10.042 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPXKHJ1rDCyF for ; Thu, 1 Dec 2011 13:11:41 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 30B1D11E8138 for ; Thu, 1 Dec 2011 13:10:56 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pB1LAhoH000770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Dec 2011 22:10:43 +0100 (MET) From: Martin Rex Message-Id: <201112012110.pB1LAgX7020434@fs4113.wdf.sap.corp> To: ajs@anvilwalrusden.com (Andrew Sullivan) Date: Thu, 1 Dec 2011 22:10:42 +0100 (MET) In-Reply-To: <20111201204600.GU61329@shinkuro.com> from "Andrew Sullivan" at Dec 1, 11 03:46:00 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 21:11:42 -0000 Andrew Sullivan wrote: > > On Thu, Dec 01, 2011 at 09:16:11PM +0100, Martin Rex wrote: > > > Not being able to access a Web-Server with a non-PKIX cert (usage type 2) > > without DANE-warning behind a DNS-proxy is not a new interop problem, > > just the lack of a new feature. > > Yes. > > > Newly being harassed with warnings > > when accessing a Web-Server with a PKIX-validating server cert > > (usage type 0/1) as soon as the DNS admin enables DNSSEC for the zone > > will be a *NEW* interop problem created by DANE if it recommends > > to abort on "Bogus". > > Sure. So if you're one of the people faced with this problem, and you > are on a broken network, turn off DNSSEC validation. DANE will say > "can't use TLSA" and your life is good. It's not like the DNSSEC > validation was doing you any good anyway. Users could be easily compelled to believe that they are on a broken network and switch DANE off. If that is turned off once, it will often not be turned back on again. How about mobile nodes that cache DNSSEC responses and that roam between networks with dense DNS-proxies and networks with well-behaved DNS-proxies? Basically all mobile nodes will be using DHCP and use the recursive DNS resolver specified in the DHCP lease. What about alternative transports for DNS records that may be available for a _subset_ of servers (like in-band through a TLS extension)? > > > This could actually amount to a real deterrent of further DNSSEC > > deployment if we define DANE this way and browsers add support for DANE. > > If you are validating behind a broken proxy, DANE will not be the only > thing that doesn't work. There are *lots* of these broken DNS-proxies, but currently there are *NO* such interop problems. Those "broken" DNS-proxies turned out to be good-enough for original DNS. Just as IPv4 turned out to be good-enough for most home users and most manufacturers of home entertainment equipment. (I purchased a brand-new LED-LCD TV from Sony slightly more than a year ago. It supports only IPv4.) It would be ostrich-like to ignore the limitations of the real world and the installed base. -Martin From zack.weinberg@gmail.com Thu Dec 1 14:06:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604BE11E808C for ; Thu, 1 Dec 2011 14:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgiTuS0EQZWo for ; Thu, 1 Dec 2011 14:06:19 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE9C311E8089 for ; Thu, 1 Dec 2011 14:06:18 -0800 (PST) Received: by yenl9 with SMTP id l9so1522428yen.31 for ; Thu, 01 Dec 2011 14:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mFdmdaOBayf0xNdG0VTMiOTb4Y90bx8viEj379Rp1j8=; b=XZgG6DtuRhTjdy1Sd/Dy0DMd+U8xS/vtDmXeUfiuVJmaF6DBqtNIbv6r5kQJ8YRKKH D8E0qwG7lwRCKKGeF/XeYC6h0rX10J64W9PMcgVa5bHQRUluLyZ9L1LGVa5N/c7VBKvD rn79jowTQQEPAQU521mCQbaDuvVl0slTXspjU= MIME-Version: 1.0 Received: by 10.182.225.3 with SMTP id rg3mr1774808obc.77.1322777178373; Thu, 01 Dec 2011 14:06:18 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.88.103 with HTTP; Thu, 1 Dec 2011 14:06:18 -0800 (PST) In-Reply-To: <201112011936.pB1JaiKG014906@fs4113.wdf.sap.corp> References: <20111201130911.GB61329@shinkuro.com> <201112011936.pB1JaiKG014906@fs4113.wdf.sap.corp> Date: Thu, 1 Dec 2011 14:06:18 -0800 X-Google-Sender-Auth: 5B4evFK5uxM1m6Qfi89D2UIeCuE Message-ID: From: Zack Weinberg To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: dane@ietf.org Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 22:06:19 -0000 I understand what you're trying to argue for here, but the problem is, any attacker who is in a position to mount one of the attacks that type 0/1 TLSA records are meant to thwart, is also in a position to degrade DNSSEC service! The only way we can claim that DANE provides an actual, in-practice security improvement over the status quo is if we don't let the attacker win when they do that, and that means BOGUS has to mean fail the TLS handshake. And I'm coming around to the notion we need to do it for INDETERMINATE too. Deployment and interop concerns like the ones you are raising are valid concerns - but we can't let them trump the security properties we are trying to deliver. Maybe that means DANE is useless in the wild - but if so, that's a better outcome than a widely deployed system that makes the existing trainwreck even worse. zw From mrex@sap.com Thu Dec 1 15:49:37 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043B51F0C50 for ; Thu, 1 Dec 2011 15:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.058 X-Spam-Level: X-Spam-Status: No, score=-10.058 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYZeNw10oqvr for ; Thu, 1 Dec 2011 15:49:36 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 005441F0C45 for ; Thu, 1 Dec 2011 15:49:35 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pB1NnXaA020501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Dec 2011 00:49:33 +0100 (MET) From: Martin Rex Message-Id: <201112012349.pB1NnXNt029424@fs4113.wdf.sap.corp> To: zack.weinberg@sv.cmu.edu (Zack Weinberg) Date: Fri, 2 Dec 2011 00:49:33 +0100 (MET) In-Reply-To: from "Zack Weinberg" at Dec 1, 11 02:06:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 23:49:37 -0000 Zack Weinberg wrote: > > Deployment and interop concerns like the ones you are raising are > valid concerns - but we can't let them trump the security properties > we are trying to deliver. Maybe that means DANE is useless in the > wild - but if so, that's a better outcome than a widely deployed > system that makes the existing trainwreck even worse. Actually, I am very concerned about the broader security aspect of the approach you're calling for. Unhampered DNS access is something we *KNOW* does not currently exist in non-marginal areas of the internet. And even if it did exist, DNS has never been known to be a 100% accurate system. The reason why it works for the most part is that 100% accuracy has never been required. DNS has traditionally been quite fault-tolerant, which is the reason why there are so many DNS-proxies in the installed base which will impair DNSSEC and DANE. So the issue we're going to be faced with are "false negatives", which DNSSEC calls "Bogus". Sensibly dealing with false negatives would mean to make better use of caching _valid_ DNS records and using experiences from previous encounters ("soft" cert pinning), which we can update when receiving data securely, and reuse if DNS lookup ends with "bogus". But what you're proposing is a Zero-tolerance policy. http://www.schneier.com/blog/archives/2009/11/zero-tolerance.html With the amount of "false alarms" that are to be expected in the installed base, it will become trivial for an attacker to create the appearance of a false positive and coerce a large part of the users to completely disable DANE checking. http://en.wikipedia.org/wiki/The_Boy_Who_Cried_Wolf I think this is a bad idea. YMMV. -Martin From ondrej.mikle@nic.cz Thu Dec 1 16:55:33 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006FF21F9872 for ; Thu, 1 Dec 2011 16:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKfwyy-5y1Co for ; Thu, 1 Dec 2011 16:55:31 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BBDB921F9871 for ; Thu, 1 Dec 2011 16:55:31 -0800 (PST) Received: from [172.30.151.65] (unknown [84.42.137.177]) by mail.nic.cz (Postfix) with ESMTPSA id 013D12A27FA; Fri, 2 Dec 2011 01:55:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1322787329; bh=tkL5h2LfrYgOG3sScg9HFB1KizgKwA18qU+uwoyb5Qw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Rj8yaWMESoqcEc5H3R3Q4SH6MreTIfOxo1KEQXVJaMy9xVlHQXzJrQpZCwFpaEFB6 vmv5nTbdKsnnvvUwJBnOBxh5x5ePh50X3PfxE0ViWsOKi61RsISVM6db7ezwr3r8JJ U/bGb7jXia+h79QYXRfNjHpcq0UpEdqw6vY7bQGY= Message-ID: <4ED821F1.4000703@nic.cz> Date: Fri, 02 Dec 2011 01:55:13 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110409 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Paul Hoffman References: <4ED7B326.4020704@nic.cz> <6997ED7D-A028-487A-BBF0-0888FE9E4CE4@vpnc.org> In-Reply-To: <6997ED7D-A028-487A-BBF0-0888FE9E4CE4@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Addition to "Security considerations" section - usage type 0 with SubjectPublicKeyInfo selector X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 00:55:33 -0000 On 12/01/11 18:09, Paul Hoffman wrote: > Instead, how about "DNS administrators should strongly consider using selector type 1 (SubjectPublicKeyInfo) in TLSA records where certificate usage field is 0 because many TLS clients...", with a similar type of change for the second paragraph? > OK. I wasn't sure where the text belongs. So what about new subsection under "Operational Considerations for Deploying TLSA Records" called "Provisioning TLSA records with usage type 0" saying (normative language substituted): ---begin text--- DNS administrators should strongly consider using selector type 1 (SubjectPublicKeyInfo) in TLSA records where certificate usage field is 0 because many TLS clients exchange intermediate certificates in chains sent by server while performing PKIX validation. Reason for such behavior is that CA certificates are often reissued: with different expiry dates, stronger hashing algorithm, etc. If the aforementioned TLSA record used selector type 0 (full certificate), it might cause interoperability problems for TLS client that swapped CA certificate for one with identical public key. When using certificate usage 0, association should not be made with a cross-certificate. TLS clients often cut certificate chain short once the client reaches an intermediate certificate which chains to a trust anchor in client's trusted certificate store. Association with a cross-certificate would be thus rejected by the client. In order to assure predictable results at client's side, the association should be made with a CA certificate that directly signed the leaf certificate. ---end text--- Thanks everyone for the feedback. Ondrej Mikle From fanf2@hermes.cam.ac.uk Thu Dec 1 16:56:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AF921F9874 for ; Thu, 1 Dec 2011 16:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6e6ZTn8D+F+6 for ; Thu, 1 Dec 2011 16:56:46 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 468E821F9871 for ; Thu, 1 Dec 2011 16:56:39 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from 74.168.pn.adsl.brightview.com ([91.125.168.74]:64377 helo=[192.168.0.5]) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1RWHQa-0005hD-Ye (Exim 4.72) (return-path ); Fri, 02 Dec 2011 00:56:36 +0000 References: <20111201130911.GB61329@shinkuro.com> <201112011936.pB1JaiKG014906@fs4113.wdf.sap.corp> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5B6923E6-750F-4E6E-A6C1-CB6D50D83345@dotat.at> X-Mailer: iPhone Mail (9A405) From: Tony Finch Date: Fri, 2 Dec 2011 00:56:35 +0000 To: Zack Weinberg Sender: Tony Finch Cc: "dane@ietf.org" Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 00:56:47 -0000 On 1 Dec 2011, at 22:06, Zack Weinberg wrote: > and that means BOGUS > has to mean fail the TLS handshake. And I'm coming around to the > notion we need to do it for INDETERMINATE too. Indeterminate means the client has no trust anchor covering the zone. It is u= nreasonable to break a server when the client has new software with an old c= onfiguration. I think you wanted to say insecure, which means the chain of t= rust is deliberately incomplete, since that might imply a misconfiguration. B= ut this can legitimately occur if the service provider is relying on an alte= rnate chain of trust, eg DLV or a private trust anchor. So again I think you= are wrong. Tony. -- f.anthony.n.finch http://dotat.at/= From gnu@toad.com Thu Dec 1 17:37:51 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1B711E808A for ; Thu, 1 Dec 2011 17:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFbZzPRo396h for ; Thu, 1 Dec 2011 17:37:50 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id BC80511E8081 for ; Thu, 1 Dec 2011 17:37:50 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id pB21bhpX031396; Thu, 1 Dec 2011 17:37:43 -0800 Message-Id: <201112020137.pB21bhpX031396@new.toad.com> To: Andrew Sullivan In-reply-to: <20111201124746.GA61329@shinkuro.com> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> Comments: In-reply-to Andrew Sullivan message dated "Thu, 01 Dec 2011 07:58:40 -0500." Date: Thu, 01 Dec 2011 17:37:43 -0800 From: John Gilmore Cc: dane@ietf.org Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 01:37:51 -0000 Is there some reason why we are trying to write the protocol spec for orgs or apps who have hardwired particular keys to particular names? Those people may deviate from our spec, and that's fine if that is what they want. Most important is what the generic apps and orgs (99.9% of the net) do. If they follow our spec, they should deliver real privacy and authenticity, if the constraints that we define in our security considerations section are met. If a client obtains a securely signed TLSA RRSET, and the TLS connection comes up with a server key that isn't part of that RRSET, generic apps should terminate hard. Due to the well known attack surfaces of pre-DNSSEC TLS, which are known to fail under active attacks seen today in the real Internet, TLSA "must" cause the TLS connection to terminate, rather than merely falling back to the insecure method that will lead the user to think they are secure when they aren't. In a TLSA-enabled TLS implementation, the only two ways to fall back to old-TLS, while retaining the security properties that our committee exists to provide, are if a DNSSEC-secured domain proves that there are no TLSA records, or if the user tries to contact a domain that (it can securely determine) is not secured by DNSSEC. Implementations that want to do otherwise "must" not be compliant with our spec. John From mrex@sap.com Thu Dec 1 18:49:28 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8424111E80A4 for ; Thu, 1 Dec 2011 18:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58KNzo+25M5k for ; Thu, 1 Dec 2011 18:49:27 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9A64C11E8073 for ; Thu, 1 Dec 2011 18:49:27 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pB22nIOH007402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Dec 2011 03:49:23 +0100 (MET) From: Martin Rex Message-Id: <201112020249.pB22nIxK009991@fs4113.wdf.sap.corp> To: ajs@anvilwalrusden.com (Andrew Sullivan) Date: Fri, 2 Dec 2011 03:49:18 +0100 (MET) In-Reply-To: <20111201205944.GV61329@shinkuro.com> from "Andrew Sullivan" at Dec 1, 11 03:59:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] fixing DNSSEC problems that are out of scope for DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 02:49:28 -0000 Andrew Sullivan wrote: > > On Thu, Dec 01, 2011 at 09:21:54PM +0100, Martin Rex wrote: > > > IMHO obtaining full DNS transparency has the same complexity and > > likelyhood to happen quickly as IPv6 connectivity for all home customers. > > Both will require replacement of the customer premises equiment (CPE), > > often a router attached to or integrated with a DSL modem. > > Things might not be quite as bad as that, although there are certainly > problems. We have a little bit of information, however: > > http://www.icann.org/en/committees/security/sac035.pdf Admittedly, I stopped doing DNS-admin stuff >12 years ago and have zero experience with DNSSEC. I did not notice any NSEC/NSEC3 proof-of-nonexistence tests in that document. And unfortunately it does not contain a simple dig-based shell script that I could just copy&paste and run in my various environments to see how badly the middleboxes on my path would interfere with DNSSEC lookups. How common is the use of NSEC/NSEC3 actually in DNS zones that have DNSSEC enabled? Without a proof-of-nonexistence, an attacker should be able to force "indeterminate" status (absence of TLSA records), I assume. -Martin From marka@isc.org Thu Dec 1 19:03:21 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D592F1F0C7B for ; Thu, 1 Dec 2011 19:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZESGMvzkRd8 for ; Thu, 1 Dec 2011 19:03:21 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 32C211F0C35 for ; Thu, 1 Dec 2011 19:03:21 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 5D6F45F9917; Fri, 2 Dec 2011 03:03:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:c4e:33ca:5ce7:5b40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 450CA216C70; Fri, 2 Dec 2011 03:02:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id BFA1018E9E2B; Fri, 2 Dec 2011 14:02:54 +1100 (EST) To: mrex@sap.com From: Mark Andrews References: <201112020249.pB22nIxK009991@fs4113.wdf.sap.corp> In-reply-to: Your message of "Fri, 02 Dec 2011 03:49:18 BST." <201112020249.pB22nIxK009991@fs4113.wdf.sap.corp> Date: Fri, 02 Dec 2011 14:02:54 +1100 Message-Id: <20111202030254.BFA1018E9E2B@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] fixing DNSSEC problems that are out of scope for DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 03:03:22 -0000 In message <201112020249.pB22nIxK009991@fs4113.wdf.sap.corp>, Martin Rex writes : > How common is the use of NSEC/NSEC3 actually in DNS zones that > have DNSSEC enabled? Without a proof-of-nonexistence, an attacker > should be able to force "indeterminate" status (absence of TLSA records), > I assume. All DNSSEC signed zones have NSEC/NSEC3 records. The signers don't produce zones without them. Validators would be throwing errors all the time without them. Even some positive answers need NSEC/NSEC3 records in the responses. If you don't have NSEC/NSEC3 records in a negative response then the answer is bogus not indeterminate. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From i.grok@comcast.net Thu Dec 1 19:45:10 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFE811E8096 for ; Thu, 1 Dec 2011 19:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDKeG0mtzVFu for ; Thu, 1 Dec 2011 19:45:10 -0800 (PST) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF5C11E8082 for ; Thu, 1 Dec 2011 19:45:10 -0800 (PST) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta04.emeryville.ca.mail.comcast.net with comcast id 43jY1i0070vp7WLA43l3T9; Fri, 02 Dec 2011 03:45:03 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta05.emeryville.ca.mail.comcast.net with comcast id 43Tu1i00l00PQ6U8R3TvaH; Fri, 02 Dec 2011 03:27:55 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id pB23j7HG016702 for ; Thu, 1 Dec 2011 22:45:07 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id pB23j59a016700 for dane@ietf.org; Thu, 1 Dec 2011 22:45:05 -0500 Date: Thu, 1 Dec 2011 22:45:05 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20111202034505.GA16591@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20111201204600.GU61329@shinkuro.com> <201112012110.pB1LAgX7020434@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <201112012110.pB1LAgX7020434@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 03:45:10 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 01, 2011 at 10:10:42PM +0100, Martin Rex wrote: > Andrew Sullivan wrote: > > Sure. So if you're one of the people faced with this problem, and you > > are on a broken network, turn off DNSSEC validation. DANE will say > > "can't use TLSA" and your life is good. It's not like the DNSSEC > > validation was doing you any good anyway. >=20 > Users could be easily compelled to believe that they are on a broken netw= ork > and switch DANE off. If the only thing validating DNSSEC is DANE, sure. If the system resolver is validating DNSSEC, nothing will work, as the root is signed. If you're suggesting that DNSSEC is undeployable because of broken networks, then this WG is wasting its time. For what it's worth, since the root has been signed, I've noticed a trend in hotel networks away =66rom hijacking DNS and towards hijacking IP instead. If enough stuff breaks, the middleboxes will eventually be forced to adapt. Meanwhile, future drafts can work on stapling, etc. --=20 Scott Schmit --a8Wt8u1KmwUX3Y2C Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTExMjAyMDM0NTA1WjAjBgkqhkiG9w0BCQQxFgQU1hrccF7g LuhxZr7KfSzOImdKwQIweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAZFEtlM9E y7Cnu14/aq53HaG5pdd8U/El0hJtylu2Exxq9Bp9PF5ecFf5MqamVUk4UWxHZahf3FtSsoWn kwe/LDXuN7y8suqgVx6iF+ofl85SBrm8SD6iu6QsN60zsBSKiCynjAk2Ci3a9+BvsJr3sUoR 7iTXFpVQKUwif828BA7E6O+4MB57pO2DoMjwMTaQeOsvndI+m/99UUPT1yjMZKKAAtM6kthW E47oMCM0fHpvfVOfF5Va7i1CTsUfFk0y0sYhYiIVkVSrVC9k7mixxe76wpZ2+DI6bDtzTTnd JQrl+UkpfGkRBMLLuCOuVpA83huwumChRPt6GwW+M0TfaA== --a8Wt8u1KmwUX3Y2C-- From i.grok@comcast.net Thu Dec 1 19:53:40 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A8121F848A for ; Thu, 1 Dec 2011 19:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmtbk9lMYzsY for ; Thu, 1 Dec 2011 19:53:40 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id BEFB521F8484 for ; Thu, 1 Dec 2011 19:53:39 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta15.westchester.pa.mail.comcast.net with comcast id 43VW1i0020QuhwU5F3tgXE; Fri, 02 Dec 2011 03:53:40 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta02.westchester.pa.mail.comcast.net with comcast id 43tf1i01Z00PQ6U3N3tguL; Fri, 02 Dec 2011 03:53:40 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id pB23rbDh016727 for ; Thu, 1 Dec 2011 22:53:37 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id pB23rbYY016725 for dane@ietf.org; Thu, 1 Dec 2011 22:53:37 -0500 Date: Thu, 1 Dec 2011 22:53:37 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20111202035337.GB16591@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20111201130911.GB61329@shinkuro.com> <201112011936.pB1JaiKG014906@fs4113.wdf.sap.corp> <5B6923E6-750F-4E6E-A6C1-CB6D50D83345@dotat.at> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="v9Ux+11Zm5mwPlX6" Content-Disposition: inline In-Reply-To: <5B6923E6-750F-4E6E-A6C1-CB6D50D83345@dotat.at> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 03:53:40 -0000 --v9Ux+11Zm5mwPlX6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 02, 2011 at 12:56:35AM +0000, Tony Finch wrote: > On 1 Dec 2011, at 22:06, Zack Weinberg wrote: >=20 > > and that means BOGUS > > has to mean fail the TLS handshake. And I'm coming around to the > > notion we need to do it for INDETERMINATE too. >=20 > Indeterminate means the client has no trust anchor covering the zone. > It is unreasonable to break a server when the client has new software > with an old configuration. I think you wanted to say insecure, which > means the chain of trust is deliberately incomplete, since that might > imply a misconfiguration. But this can legitimately occur if the > service provider is relying on an alternate chain of trust, eg DLV or > a private trust anchor. So again I think you are wrong. It can also happen if the zone is in the middle of switching from insecure to secure. You want to add the DS after the unsigned records have expired out of the caches or you'll go bogus until they do. --=20 Scott Schmit --v9Ux+11Zm5mwPlX6 Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTExMjAyMDM1MzM3WjAjBgkqhkiG9w0BCQQxFgQUSGIgzLgH MSc2AwSH8UHfAPHAqZ0weQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAOeLAZuVJ 0nHRdzGfOcc4VC3Kvp+3z3y/+roUx4UZfsnd4d4OICBaV0exLStKR7r6cgr3O4mlMr/kcEo9 /m4Sa7zekMTzXGsB4aGhjsSRkgL8QY3a8DWqD9hyJtx96UdNee89exgv3C3KoiIf2Wu/l1XD KopB4jfqcxgoWgVPTUqO5AyOcud82yNiAhlekF4iAp2dWJLh8Ew//xJ0kYoGrHQZocPoZwWv oUTKAlsurin30v1TKiDJhQr3n/MhfTA86FCSqV16rzl96q6uP/+55Qvmu6KfqDrVjZTauLlF QvqKMGHjs23fynj2b2kVeCGBdK+ActNeXNFEb2NegoimJA== --v9Ux+11Zm5mwPlX6-- From marka@isc.org Thu Dec 1 20:23:59 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6D711E8082 for ; Thu, 1 Dec 2011 20:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55-HEcRg6EbU for ; Thu, 1 Dec 2011 20:23:58 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id ACBB611E8081 for ; Thu, 1 Dec 2011 20:23:58 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 05C6F5F990B for ; Fri, 2 Dec 2011 04:23:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:c4e:33ca:5ce7:5b40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0D989216C6B for ; Fri, 2 Dec 2011 04:23:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 81E5E18EB604 for ; Fri, 2 Dec 2011 15:23:33 +1100 (EST) To: dane@ietf.org From: Mark Andrews References: <20111201130911.GB61329@shinkuro.com> <201112011936.pB1JaiKG014906@fs4113.wdf.sap.corp> <5B6923E6-750F-4E6E-A6C1-CB6D50D83345@dotat.at> <20111202035337.GB16591@odin.ulthar.us> Mail-Followup-To: dane@ietf.org In-reply-to: Your message of "Thu, 01 Dec 2011 22:53:37 CDT." <20111202035337.GB16591@odin.ulthar.us> Date: Fri, 02 Dec 2011 15:23:33 +1100 Message-Id: <20111202042333.81E5E18EB604@drugs.dv.isc.org> Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 04:23:59 -0000 In message <20111202035337.GB16591@odin.ulthar.us>, Scott Schmit writes: > On Fri, Dec 02, 2011 at 12:56:35AM +0000, Tony Finch wrote: > > On 1 Dec 2011, at 22:06, Zack Weinberg wrote: > > > > > and that means BOGUS > > > has to mean fail the TLS handshake. And I'm coming around to the > > > notion we need to do it for INDETERMINATE too. > > > > Indeterminate means the client has no trust anchor covering the zone. > > It is unreasonable to break a server when the client has new software > > with an old configuration. I think you wanted to say insecure, which > > means the chain of trust is deliberately incomplete, since that might > > imply a misconfiguration. But this can legitimately occur if the > > service provider is relying on an alternate chain of trust, eg DLV or > > a private trust anchor. So again I think you are wrong. > > It can also happen if the zone is in the middle of switching from > insecure to secure. You want to add the DS after the unsigned records > have expired out of the caches or you'll go bogus until they do. There are lots of ways that you can mis-manage zones. DNSSEC is more sensitive to mis-management. That however is not a reason to not use DNSSEC or to not use DANE. It is possible to switch from insecure to secure and secure to insecure without validators returning bogus. We have lots of operational experience with doing so with some of the biggest zones on the planet. > -- > Scott Schmit -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From i.grok@comcast.net Thu Dec 1 20:56:12 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B886F11E80A6 for ; Thu, 1 Dec 2011 20:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcJeBNvoPITH for ; Thu, 1 Dec 2011 20:56:12 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by ietfa.amsl.com (Postfix) with ESMTP id 39AD511E80A3 for ; Thu, 1 Dec 2011 20:56:12 -0800 (PST) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta03.emeryville.ca.mail.comcast.net with comcast id 44sX1i0010FhH24A34w5pQ; Fri, 02 Dec 2011 04:56:05 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta08.emeryville.ca.mail.comcast.net with comcast id 44vC1i00f00PQ6U8U4vDoH; Fri, 02 Dec 2011 04:55:13 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id pB24u9is017005 for ; Thu, 1 Dec 2011 23:56:09 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id pB24u5RK017002 for dane@ietf.org; Thu, 1 Dec 2011 23:56:05 -0500 Date: Thu, 1 Dec 2011 23:56:05 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20111202045605.GA16902@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20111201130911.GB61329@shinkuro.com> <201112011936.pB1JaiKG014906@fs4113.wdf.sap.corp> <5B6923E6-750F-4E6E-A6C1-CB6D50D83345@dotat.at> <20111202035337.GB16591@odin.ulthar.us> <20111202042333.81E5E18EB604@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <20111202042333.81E5E18EB604@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 04:56:12 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 02, 2011 at 03:23:33PM +1100, Mark Andrews wrote: > In message <20111202035337.GB16591@odin.ulthar.us>, Scott Schmit writes: > > On Fri, Dec 02, 2011 at 12:56:35AM +0000, Tony Finch wrote: > > > On 1 Dec 2011, at 22:06, Zack Weinberg wro= te: > > >=20 > > > > and that means BOGUS > > > > has to mean fail the TLS handshake. And I'm coming around to the > > > > notion we need to do it for INDETERMINATE too. > > >=20 > > > Indeterminate means the client has no trust anchor covering the zone. > > > It is unreasonable to break a server when the client has new software > > > with an old configuration. I think you wanted to say insecure, which > > > means the chain of trust is deliberately incomplete, since that might > > > imply a misconfiguration. But this can legitimately occur if the > > > service provider is relying on an alternate chain of trust, eg DLV or > > > a private trust anchor. So again I think you are wrong. > >=20 > > It can also happen if the zone is in the middle of switching from > > insecure to secure. You want to add the DS after the unsigned records > > have expired out of the caches or you'll go bogus until they do. >=20 > There are lots of ways that you can mis-manage zones. DNSSEC is > more sensitive to mis-management. That however is not a reason to > not use DNSSEC or to not use DANE. It is possible to switch from > insecure to secure and secure to insecure without validators returning > bogus. We have lots of operational experience with doing so with > some of the biggest zones on the planet. Sorry, I wasn't clear. I was trying to point out that as a zone transitions (properly), it will go from insecure to indeterminate (when the zone gets signed, but the DS record is not yet available) to secure (when the DS record is deployed). So, being indeterminate is a legitimate state, even if one ignores DLV, etc. At no point is the zone bogus, nor should DANE treat it that way. As to TLSA records, if they're deployed before the zone is signed, they'll go through the same progression. --=20 Scott Schmit --9jxsPFA5p3P2qPhR Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTExMjAyMDQ1NjA1WjAjBgkqhkiG9w0BCQQxFgQU44v1vaIx dRyP0iT5y6XM5BK04cwweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAB8hIxhqq wI84XsL0hCssj/ps8ANRBc9OzdnhcyLnulKvdfnWnBAln7wv5lYe6Fx4Jwjbw/MLCbokHm0D asHIpUd2gNfh9EYInIiAOeCB7lCjEtOyvclvYEtkLov+E8cE58oZQMkGuzwdWmHlz/doIauU GYYZUsW5F6B5jAa4vSRCs+aZLreF33NRnI3jlVb43CITnb1+f+c4NiMigviwmRnicbru+v6p E2pLAaqKagjRHT6MhtGV8PqRypuH9mMJuaNt9jNUGa4Wnh85OoJDvVd6DElaj+HJbNRlyE+J 1hQAsVUP/aruwKMWtDlw53sq56uiguzZJ8vrNIY58Bn2lA== --9jxsPFA5p3P2qPhR-- From Suresh.Krishnaswamy@sparta.com Fri Dec 2 07:08:58 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302EB21F8BB0 for ; Fri, 2 Dec 2011 07:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8EzvxHfjCw2 for ; Fri, 2 Dec 2011 07:08:54 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4049C21F8B95 for ; Fri, 2 Dec 2011 07:08:54 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id pB2F8oNP023005; Fri, 2 Dec 2011 09:08:52 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pB2F8o01029804; Fri, 2 Dec 2011 09:08:50 -0600 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0339.001; Fri, 2 Dec 2011 10:08:43 -0500 From: "Krishnaswamy, Suresh" To: Andrew Sullivan Thread-Topic: [dane] fixing DNSSEC problems that are out of scope for DANE Thread-Index: AQHMsQRIbL5/K27UkEiTW5DcK4m+8g== Date: Fri, 2 Dec 2011 15:08:43 +0000 Message-ID: References: <6316719A-E602-462F-BB74-8B91E15F398E@rfc1035.com> <201112012021.pB1KLsOM017495@fs4113.wdf.sap.corp> <20111201205944.GV61329@shinkuro.com> In-Reply-To: <20111201205944.GV61329@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.23] Content-Type: text/plain; charset="us-ascii" Content-ID: <5970F163C13D9D418F6CCBB2FF4871A5@ads.sparta.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 02 Dec 2011 07:37:15 -0800 Cc: "dane@ietf.org" Subject: Re: [dane] fixing DNSSEC problems that are out of scope for DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 15:13:04 -0000 On Dec 1, 2011, at 3:59 PM, Andrew Sullivan wrote: > Things might not be quite as bad as that, although there are certainly > problems. We have a little bit of information, however: >=20 > http://www.icann.org/en/committees/security/sac035.pdf >=20 There's one differentiator in this study that I wanted to focus on, namely = that most middle-boxes are shown to _route_ DNS traffic through them withou= t any problems. Extrapolating further, middle-boxes should not (are less li= kely to) interfere with queries that originate from a validating stub resol= ver/validating name server that operates within/in proximity to the client.= I run a DNSSEC-enabled version of firefox routinely - behind various middl= e-boxes - and do in fact see evidence of this fact. =20 It seems to me, as much as I feel uncomfortable saying it, that there might= be a reason to define a policy knob that controls the manner in which DANE= handles the BOGUS condition. If the BOGUS condition was determined locally= (through a validating stub resolver or a validating name server running at= 127.0.0.1), we would fail-close; if the BOGUS condition was determined thr= ough the error code, we'd fail-degrade. Suresh= From fanf2@hermes.cam.ac.uk Fri Dec 2 07:41:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678B921F8C73 for ; Fri, 2 Dec 2011 07:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lri5PmAXiaAO for ; Fri, 2 Dec 2011 07:41:44 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8E41621F8B68 for ; Fri, 2 Dec 2011 07:41:44 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:34637) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1RWVF7-0006Iu-YH (Exim 4.72) (return-path ); Fri, 02 Dec 2011 15:41:41 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RWVF7-0006SZ-Iy (Exim 4.67) (return-path ); Fri, 02 Dec 2011 15:41:41 +0000 Date: Fri, 2 Dec 2011 15:41:41 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Krishnaswamy, Suresh" In-Reply-To: Message-ID: References: <6316719A-E602-462F-BB74-8B91E15F398E@rfc1035.com> <201112012021.pB1KLsOM017495@fs4113.wdf.sap.corp> <20111201205944.GV61329@shinkuro.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "dane@ietf.org" Subject: Re: [dane] fixing DNSSEC problems that are out of scope for DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 15:41:45 -0000 > It seems to me, as much as I feel uncomfortable saying it, that there > might be a reason to define a policy knob that controls the manner in > which DANE handles the BOGUS condition. If the BOGUS condition was > determined locally (through a validating stub resolver or a validating > name server running at 127.0.0.1), we would fail-close; if the BOGUS > condition was determined through the error code, we'd fail-degrade. This is a job for software like dnssec-trigger. Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Westerly 4 in south at first, otherwise northerly 5 to 7. Rough or very rough but moderate in south at first. Showers. Moderate or good. From peter@denic.de Sat Dec 3 14:53:39 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C54421F93B0 for ; Sat, 3 Dec 2011 14:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrQL6XzYHMrT for ; Sat, 3 Dec 2011 14:53:39 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id BFBC521F939F for ; Sat, 3 Dec 2011 14:53:38 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1RWySd-0007KM-GA; Sat, 03 Dec 2011 23:53:35 +0100 Received: from localhost by x27.adm.denic.de with local id 1RWySd-0001Xp-BR; Sat, 03 Dec 2011 23:53:35 +0100 Date: Sat, 3 Dec 2011 23:53:35 +0100 From: Peter Koch To: dane@ietf.org Message-ID: <20111203225335.GL17317@x27.adm.denic.de> Mail-Followup-To: dane@ietf.org References: <4ED7B326.4020704@nic.cz> <6997ED7D-A028-487A-BBF0-0888FE9E4CE4@vpnc.org> <4ED821F1.4000703@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ED821F1.4000703@nic.cz> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dane] Addition to "Security considerations" section - usage type 0 with SubjectPublicKeyInfo selector X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 22:53:39 -0000 On Fri, Dec 02, 2011 at 01:55:13AM +0100, Ondrej Mikle wrote: > DNS administrators should strongly consider using selector type 1 > (SubjectPublicKeyInfo) in TLSA records where certificate usage field is 0 > because many TLS clients exchange intermediate certificates in chains sent by [...] I consider this type of language confusing. "should strongly consider" is not formally normative because of the lack of capitalization but what is this advice worth? Given the elaborate reasoning that follows, wouldn't "RECOMMENDED" be the appropriate level of direction? Also, I'd suggest not to address the "DNS administrator" because it's not necessarily their choice. "The use of selector type 1 (SubjectPublicKeyInfo) is RECOMMENDED where the TLSA record's usage field is 0 ..." -Peter From peter@denic.de Sat Dec 3 15:07:38 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E26221F9387 for ; Sat, 3 Dec 2011 15:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkEjcv1u8bzp for ; Sat, 3 Dec 2011 15:07:38 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id E19D621F9343 for ; Sat, 3 Dec 2011 15:07:37 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1RWygD-0007QC-8E; Sun, 04 Dec 2011 00:07:37 +0100 Received: from localhost by x27.adm.denic.de with local id 1RWygD-0001kG-49; Sun, 04 Dec 2011 00:07:37 +0100 Date: Sun, 4 Dec 2011 00:07:37 +0100 From: Peter Koch To: dane@ietf.org Message-ID: <20111203230737.GM17317@x27.adm.denic.de> Mail-Followup-To: dane@ietf.org References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> <20111201131720.GG17317@x27.adm.denic.de> <8D71ACF1-A834-4B14-8FE6-56EC72F77CC5@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8D71ACF1-A834-4B14-8FE6-56EC72F77CC5@nic.cz> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dane] RFC2119 MAY (Was: Call for consensus on level of DNSSEC support) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 23:07:38 -0000 On Thu, Dec 01, 2011 at 08:15:09PM +0100, Ond??ej Surý wrote: > We are asking 'whether X can be used' > > > o A TLSA RRset whose DNSSEC validation state is secure can be used > > as a certificate association for TLS. > > > We are saying: 'Yes, it can be used'. in my eyes this is fuzzy wording. > I may be wrong, but I don't see a need for normative MAY here. If I read the discussion correctly, "SHOULD" is probably what you're looking for: "using" the TLSA RR is the recommended way forward and exceptional circumstances (local policy override) might suggest otherwise. -Peter From ondrej.mikle@nic.cz Sat Dec 3 19:56:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C6411E8094 for ; Sat, 3 Dec 2011 19:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_DOSE=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxAWx3cRSyol for ; Sat, 3 Dec 2011 19:56:44 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DF9FF11E807F for ; Sat, 3 Dec 2011 19:56:43 -0800 (PST) Received: from [172.30.151.65] (ip-84-42-137-177.net.upcbroadband.cz [84.42.137.177]) by mail.nic.cz (Postfix) with ESMTPSA id 501DE2A2EF5; Sun, 4 Dec 2011 04:56:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1322971001; bh=o/wEH5dZVjJTe6KxUtZTYGi2CQlPvtb/Pk9ZeSBo0WE=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=KXTY6XKKQR3Nr7RAJwITu9pBufwlgfDLHqRlF8M0AN2n4jeHCNd9ovbv67WJ+LKFf LXh68pWEEGsEBWfanCl8PesuBzzKej4B8lA5jMc7f4EUutRdNAzTdJYHyMRtmKOFdR W36TknU5KzV68JIYRI1nQnBW4sTdmrCkumjqw0r8= Message-ID: <4EDAEF78.80504@nic.cz> Date: Sun, 04 Dec 2011 04:56:40 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110409 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Peter Koch , dane@ietf.org References: <4ED7B326.4020704@nic.cz> <6997ED7D-A028-487A-BBF0-0888FE9E4CE4@vpnc.org> <4ED821F1.4000703@nic.cz> <20111203225335.GL17317@x27.adm.denic.de> In-Reply-To: <20111203225335.GL17317@x27.adm.denic.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Addition to "Security considerations" section - usage type 0 with SubjectPublicKeyInfo selector X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 03:56:45 -0000 On 12/03/11 23:53, Peter Koch wrote: > On Fri, Dec 02, 2011 at 01:55:13AM +0100, Ondrej Mikle wrote: > >> DNS administrators should strongly consider using selector type 1 >> (SubjectPublicKeyInfo) in TLSA records where certificate usage field is 0 >> because many TLS clients exchange intermediate certificates in chains sent by > [...] > > I consider this type of language confusing. "should strongly consider" is > not formally normative because of the lack of capitalization but what is this advice > worth? Given the elaborate reasoning that follows, wouldn't "RECOMMENDED" > be the appropriate level of direction? Also, I'd suggest not to address > the "DNS administrator" because it's not necessarily their choice. > > "The use of selector type 1 (SubjectPublicKeyInfo) is RECOMMENDED where the TLSA > record's usage field is 0 ..." (Sorry for the length of following post, I've tried to cover every relevant case I count think of.) I admit I am new at writing RFCese. In first proposal I had "SHOULD, SHOULD NOT and RECOMMENDED". Paul Hoffman felt that the normative RFC 2119 language was too strong and suggested a replacement. I personally prefer the normative language in this case, because the text aims to avoid hard-to-debug "cooperation paradoxes". (Safe to skip this paragraph: Example of similar not-so-rare "cooperation paradox" to-date: Some TLS servers do not send complete intermediate chain. Though it works for server administrator when he checks and most clients, but "strangely" fails for a few other clients - it's because TLS clients often cache valid intermediate certificates, thus only fresh client installations tend to encounter the failure-to-build-trust-chain problem. Even most IT admin folk haven't heard about this caching/'transvalid' building-of-cert-chain behavior. Which is why is it hard to for client to correctly report bug and the server admin to understand and fix it.) My goal is that this pitfall with unpredictable chain-of-trust building at client's side is documented. I let the decision "normative" vs "plain" language to more skilled RFC veterans. So I've written two versions, one normative, one non-normative (just reminding that it's for "operational considerations" section): ---begin text normative version--- When deploying TLSA record with certificate usage field 0, it is RECOMMENDED to use selector type 1 (SubjectPublicKeyInfo) in such TLSA record. Many TLS clients exchange intermediate certificates in chains sent by server while performing PKIX validation. Reason for such behavior is that CA certificates are often reissued: with different expiry dates, stronger hashing algorithm, etc. If the aforementioned TLSA record used selector type 0 (full certificate), it might cause interoperability problems for TLS client that swapped CA certificate for one with identical public key. TLSA record with certificate usage type 0 SHOULD NOT associate with a cross-certificate. TLS clients often cut certificate chain short once the client reaches an intermediate certificate which chains to a trust anchor in client's trusted certificate store. Association with a cross-certificate would be thus rejected by the client. It is RECOMMENDED that the association is made with a CA certificate that directly signed the leaf certificate since it gives the most predictable processing on client's side. ---end text normative version--- ---begin text non-normative version--- When constructing certificate usage field 0 in a TLSA record, the best course of action is to use selector type 1 (SubjectPublicKeyInfo) in such TLSA record. Many TLS clients exchange intermediate certificates in chains sent by server while performing PKIX validation. Reason for such behavior is that CA certificates are often reissued: with different expiry dates, stronger hashing algorithm, etc. If the aforementioned TLSA record used selector type 0 (full certificate), it might cause interoperability problems for TLS client that swapped CA certificate for one with identical public key. It is important to avoid associating TLSA record with certificate usage type 0 with a cross-certificate. TLS clients often cut certificate chain short once the client reaches an intermediate certificate which chains to a trust anchor in client's trusted certificate store. Association with a cross-certificate would be thus rejected by the client. Best approach would be to make the TLSA association with a CA certificate that directly signed the leaf certificate since it gives the most predictable processing on client's side. ---end text non-normative version--- A possible reason to use full certificate in the certificate usage 0 case anyway is when the site operator/admin/etc absolutely wants to ensure that extensions of the certificate he chose needs to be preserved. I could think only of two attacks that would be possible on bare SPKI compared to full-cert association: DOS (e.g. using an expired CA cert in TLS MitM handshake) or exploiting some X.509 implementation quirks of ASN.1 parsing issuing CA's software or in clients. (I'm sure someone will come up with something else eventually; e.g. I came accross a case where handling of few not-so-often used certificate extensions varies widely among common clients). Ondrej From lconroy@insensate.co.uk Sun Dec 4 06:42:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7733021F84E5 for ; Sun, 4 Dec 2011 06:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_DOSE=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLMtn1M5gq2l for ; Sun, 4 Dec 2011 06:42:46 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 46B1821F84DD for ; Sun, 4 Dec 2011 06:42:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 9BE0126C500; Sun, 4 Dec 2011 14:42:45 +0000 (GMT) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LakEoHIU7A1X; Sun, 4 Dec 2011 14:42:44 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 2B81626C4F5; Sun, 4 Dec 2011 14:42:44 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <4EDAEF78.80504@nic.cz> Date: Sun, 4 Dec 2011 14:42:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <4C7EF296-D27E-4738-B189-A0C9A99D09B1@insensate.co.uk> References: <4ED7B326.4020704@nic.cz> <6997ED7D-A028-487A-BBF0-0888FE9E4CE4@vpnc.org> <4ED821F1.4000703@nic.cz> <20111203225335.GL17317@x27.adm.denic.de> <4EDAEF78.80504@nic.cz> To: Ondrej Mikle X-Mailer: Apple Mail (2.1084) Cc: Peter Koch , dane@ietf.org Subject: Re: [dane] Addition to "Security considerations" section - usage type 0 with SubjectPublicKeyInfo selector X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 14:42:47 -0000 Hi Ondrej, Peter, folks, For me, the normative form is best, as from this implementors know what is intended in one (clear) sentence. Personally, I'm really happy that it has an explanation/justification as well. This is a Very Good Thing (many RFCs just let you guess the = rationale, IMHO forcing implementors [and product manager :] into guru meditation = is risky). One thing (editorial only) -- the proposed text is missing definite and = indefinite article(s). I read the first paragraph as including: "A TLSA record", "the server", "The reason", "a TLS client", "the CA = certificate", "an identical public key". I read the second paragraph as including: "A TLSA record", "a certificate chain", "those clients' trusted = certificate stores", 'the client' -> "such clients", 'client's side' -> "the client side". So, Im a +1 for the normative form. Quick question: what would it mean if there were to be more than one = TLSA record in the RRSet? all the best, Lawrence On 4 Dec 2011, at 03:56, Ondrej Mikle wrote: > On 12/03/11 23:53, Peter Koch wrote: >> On Fri, Dec 02, 2011 at 01:55:13AM +0100, Ondrej Mikle wrote: >>=20 >>> DNS administrators should strongly consider using selector type 1 >>> (SubjectPublicKeyInfo) in TLSA records where certificate usage field = is 0 >>> because many TLS clients exchange intermediate certificates in = chains sent by >> [...] >>=20 >> I consider this type of language confusing. "should strongly = consider" is >> not formally normative because of the lack of capitalization but what = is this advice >> worth? Given the elaborate reasoning that follows, wouldn't = "RECOMMENDED" >> be the appropriate level of direction? Also, I'd suggest not to = address >> the "DNS administrator" because it's not necessarily their choice. >>=20 >> "The use of selector type 1 (SubjectPublicKeyInfo) is RECOMMENDED = where the TLSA >> record's usage field is 0 ..." >=20 > (Sorry for the length of following post, I've tried to cover every = relevant case > I count think of.) >=20 > I admit I am new at writing RFCese. In first proposal I had "SHOULD, = SHOULD NOT > and RECOMMENDED". Paul Hoffman felt that the normative RFC 2119 = language was too > strong and suggested a replacement. I personally prefer the normative = language > in this case, because the text aims to avoid hard-to-debug = "cooperation paradoxes". >=20 > (Safe to skip this paragraph: Example of similar not-so-rare = "cooperation > paradox" to-date: Some TLS servers do not send complete intermediate = chain. > Though it works for server administrator when he checks and most = clients, but > "strangely" fails for a few other clients - it's because TLS clients = often cache > valid intermediate certificates, thus only fresh client installations = tend to > encounter the failure-to-build-trust-chain problem. Even most IT admin = folk > haven't heard about this caching/'transvalid' building-of-cert-chain = behavior. > Which is why is it hard to for client to correctly report bug and the = server > admin to understand and fix it.) >=20 >=20 > My goal is that this pitfall with unpredictable chain-of-trust = building at > client's side is documented. I let the decision "normative" vs "plain" = language > to more skilled RFC veterans. So I've written two versions, one = normative, one > non-normative (just reminding that it's for "operational = considerations" section): >=20 >=20 > ---begin text normative version--- >=20 > When deploying TLSA record with certificate usage field 0, it is = RECOMMENDED to > use selector type 1 (SubjectPublicKeyInfo) in such TLSA record. Many = TLS clients > exchange intermediate certificates in chains sent by server while = performing > PKIX validation. Reason for such behavior is that CA certificates are = often > reissued: with different expiry dates, stronger hashing algorithm, = etc. If the > aforementioned TLSA record used selector type 0 (full certificate), it = might > cause interoperability problems for TLS client that swapped CA = certificate for > one with identical public key. >=20 > TLSA record with certificate usage type 0 SHOULD NOT associate with a > cross-certificate. TLS clients often cut certificate chain short once = the client > reaches an intermediate certificate which chains to a trust anchor in = client's > trusted certificate store. Association with a cross-certificate would = be thus > rejected by the client. It is RECOMMENDED that the association is made = with a CA > certificate that directly signed the leaf certificate since it gives = the most > predictable processing on client's side. >=20 > ---end text normative version--- >=20 >=20 > ---begin text non-normative version--- >=20 > When constructing certificate usage field 0 in a TLSA record, the best = course of > action is to use selector type 1 (SubjectPublicKeyInfo) in such TLSA = record. > Many TLS clients exchange intermediate certificates in chains sent by = server > while performing PKIX validation. Reason for such behavior is that CA > certificates are often reissued: with different expiry dates, stronger = hashing > algorithm, etc. If the aforementioned TLSA record used selector type 0 = (full > certificate), it might cause interoperability problems for TLS client = that > swapped CA certificate for one with identical public key. >=20 > It is important to avoid associating TLSA record with certificate = usage type 0 > with a cross-certificate. TLS clients often cut certificate chain = short once the > client reaches an intermediate certificate which chains to a trust = anchor in > client's trusted certificate store. Association with a = cross-certificate would > be thus rejected by the client. Best approach would be to make the = TLSA > association with a CA certificate that directly signed the leaf = certificate > since it gives the most predictable processing on client's side. >=20 > ---end text non-normative version--- >=20 >=20 > A possible reason to use full certificate in the certificate usage 0 = case anyway > is when the site operator/admin/etc absolutely wants to ensure that = extensions > of the certificate he chose needs to be preserved. I could think only = of two > attacks that would be possible on bare SPKI compared to full-cert = association: > DOS (e.g. using an expired CA cert in TLS MitM handshake) or = exploiting some > X.509 implementation quirks of ASN.1 parsing issuing CA's software or = in > clients. (I'm sure someone will come up with something else = eventually; e.g. I > came accross a case where handling of few not-so-often used = certificate > extensions varies widely among common clients). >=20 > Ondrej > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From i.grok@comcast.net Sun Dec 4 13:16:30 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A1121F867F for ; Sun, 4 Dec 2011 13:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hrNIS3BBtlq for ; Sun, 4 Dec 2011 13:16:30 -0800 (PST) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF9821F8495 for ; Sun, 4 Dec 2011 13:16:30 -0800 (PST) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta12.emeryville.ca.mail.comcast.net with comcast id 597W1i0051eYJf8AC9GQVT; Sun, 04 Dec 2011 21:16:24 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta19.emeryville.ca.mail.comcast.net with comcast id 58lR1i00H00PQ6U018lS4e; Sun, 04 Dec 2011 20:45:26 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id pB4LGSoM002788 for ; Sun, 4 Dec 2011 16:16:28 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id pB4LGSBs002787 for dane@ietf.org; Sun, 4 Dec 2011 16:16:28 -0500 Date: Sun, 4 Dec 2011 16:16:28 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20111204211628.GA2627@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <4ED7B326.4020704@nic.cz> <6997ED7D-A028-487A-BBF0-0888FE9E4CE4@vpnc.org> <4ED821F1.4000703@nic.cz> <20111203225335.GL17317@x27.adm.denic.de> <4EDAEF78.80504@nic.cz> <4C7EF296-D27E-4738-B189-A0C9A99D09B1@insensate.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <4C7EF296-D27E-4738-B189-A0C9A99D09B1@insensate.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Addition to "Security considerations" section - usage type 0 with SubjectPublicKeyInfo selector X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 21:16:31 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 04, 2011 at 02:42:43PM +0000, Lawrence Conroy wrote: > Quick question: what would it mean if there were to be more than one > TLSA record in the RRSet? Multiple associations are possible. Only one must be valid. This allows cert/key rolling, multiple servers, certs/keys for different algorithms, etc. That said, the consensus call for the document edit includes the entire paragraph as "old" and misses some of the processing after deciding that the records have been recieved securely in the "new", namely: "if the application doesn't understand it, drop it; iterate through each remaining records until you find one that matches, otherwise abort." My +1 is contingent on that latter bit still being in the new, since that's what makes the document usable. :-) I trust that was an oversight? --=20 Scott Schmit --oyUTqETQ0mS9luUI Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTExMjA0MjExNjI3WjAjBgkqhkiG9w0BCQQxFgQUTRTPcNoz ZQfsSCshxN7kdYQzgKcweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAM71NuphH /tAkw1eFPp0IsnLqta6dR+t5kCiGiTZG7Y62ixvK1D8oMvaeylJoZxvC86DJySFBPQBauRhy I45vdoqUrsgJhm0WJEChiMnMkE+AGHdfIhpSuwAUqDL8GU++3ZvXQkopT/w0Zwp9RxTVad/R xRFSQz/3LCLsVnm8EOHO0G4U9lTC644pJLJ6yUXbbC34+KfnPMVrSvdaFzi8nNLQQ3Ei0rHD 1iz+tFe452sEueJoQl28oibzgsu2mICAF9PUUxUg8gE6DVDcb0wCR/y+T2XXuk7GttnNZzbR jcMDGGeVF0c1lmgA2RvsMzFe/9P7z6YsH8c9e33CioMJtA== --oyUTqETQ0mS9luUI-- From ondrej.sury@nic.cz Tue Dec 6 01:41:46 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EF921F8B66 for ; Tue, 6 Dec 2011 01:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTC8sa4KVwrq for ; Tue, 6 Dec 2011 01:41:46 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DB64821F8B63 for ; Tue, 6 Dec 2011 01:41:45 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id E61202A2F5E for ; Tue, 6 Dec 2011 10:41:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1323164502; bh=sJNcdi9wo9FQ7K4MiRqdlSLIZx950pY292C6ecbmEbI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=SORA+E+vnojPRGD/qacXgqpdZLRXlvcASXcs0ZwzDPXU8X3lhiyUjFntoSDoYI/ZA /hurIuGFSjeLibybARAX8naeB3TeUK2g28O6MXcmkOOihmLvOwz464xqaIDOscNbXj oXytGN0tz5wU4klaFEnU3Bd7WL9Ir6B1Z6eX4d/c= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1251.1) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4EDAEF78.80504@nic.cz> Date: Tue, 6 Dec 2011 10:41:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4ED7B326.4020704@nic.cz> <6997ED7D-A028-487A-BBF0-0888FE9E4CE4@vpnc.org> <4ED821F1.4000703@nic.cz> <20111203225335.GL17317@x27.adm.denic.de> <4EDAEF78.80504@nic.cz> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Addition to "Security considerations" section - usage type 0 with SubjectPublicKeyInfo selector X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 09:41:46 -0000 Hi all, any objections to adding this text to operational recommendations = section? I feel that the text was generally well received and thus no call is = needed (unless I hear from you now). O. On 4. 12. 2011, at 4:56, Ondrej Mikle wrote: > ---begin text normative version--- >=20 > When deploying TLSA record with certificate usage field 0, it is = RECOMMENDED to > use selector type 1 (SubjectPublicKeyInfo) in such TLSA record. Many = TLS clients > exchange intermediate certificates in chains sent by server while = performing > PKIX validation. Reason for such behavior is that CA certificates are = often > reissued: with different expiry dates, stronger hashing algorithm, = etc. If the > aforementioned TLSA record used selector type 0 (full certificate), it = might > cause interoperability problems for TLS client that swapped CA = certificate for > one with identical public key. >=20 > TLSA record with certificate usage type 0 SHOULD NOT associate with a > cross-certificate. TLS clients often cut certificate chain short once = the client > reaches an intermediate certificate which chains to a trust anchor in = client's > trusted certificate store. Association with a cross-certificate would = be thus > rejected by the client. It is RECOMMENDED that the association is made = with a CA > certificate that directly signed the leaf certificate since it gives = the most > predictable processing on client's side. >=20 > ---end text normative version--- -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Tue Dec 6 01:54:36 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63F621F8801 for ; Tue, 6 Dec 2011 01:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.513 X-Spam-Level: X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4UzTc1Kd6e7 for ; Tue, 6 Dec 2011 01:54:36 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E0C9C21F87FC for ; Tue, 6 Dec 2011 01:54:35 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 29A002A2F90; Tue, 6 Dec 2011 10:54:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1323165275; bh=lEGmWjoFQ6EgozFblO+m+0syEywkh24jzxGpdiiAU5U=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=v44YZs2FVj75/FrlyiKF9/yi+Udzow7E+jIGF2TInX2Fjh5gHzCs6fSat8iePZP0k sKjHLBQtQuJawu6kHYUww9ukW/cqhyAwtE636w0rfp9PomZ27L8u3v0k79Lglwql20 kA+da+FTIHdOwx0mCRtrBbnA4RVPygahk5zIibmM= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20111203230737.GM17317@x27.adm.denic.de> Date: Tue, 6 Dec 2011 10:54:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B7A07B4-50FE-4839-8683-74B0B2E7024D@nic.cz> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> <20111201131720.GG17317@x27.adm.denic.de> <8D71ACF1-A834-4B14-8FE6-56EC72F77CC5@nic.cz> <20111203230737.GM17317@x27.adm.denic.de> To: Eric Osterweil X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: [dane] Call for DNSSEC validation states ending soon (Was: RFC2119 MAY (Was: Call for consensus on level of DNSSEC support)) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 09:54:36 -0000 On 4. 12. 2011, at 0:07, Peter Koch wrote: > On Thu, Dec 01, 2011 at 08:15:09PM +0100, Ond??ej Sur=C3=BD wrote: >=20 >> We are asking 'whether X can be used' >>=20 >>> o A TLSA RRset whose DNSSEC validation state is secure can be used >>> as a certificate association for TLS. >>=20 >>=20 >> We are saying: 'Yes, it can be used'. >=20 > in my eyes this is fuzzy wording. >=20 >> I may be wrong, but I don't see a need for normative MAY here. >=20 > If I read the discussion correctly, "SHOULD" is probably what you're = looking for: > "using" the TLSA RR is the recommended way forward and exceptional > circumstances (local policy override) might suggest otherwise. I am fine with Peter's SHOULD, so the full text will be: > An application that complies with this document first requests TLSA > records in order to make certificate associations. >=20 > Determining whether a TLSA RRset can be used depends > on the DNSSEC validation state (as defined in [RFC4033]). >=20 > o A TLSA RRset whose DNSSEC validation state is secure SHOULD be = used > as a certificate association for TLS. >=20 > o If the DNSSEC validation state on the response to the request > for the TLSA RRset is bogus, this MUST cause TLS not to be started > or, if the TLS negotiation is already in progress, to cause > the connection to be aborted. >=20 > o A TLSA RRset whose DNSSEC validation state is indeterminate or > insecure cannot be used for TLS and MUST be marked as unusable. So far we have: +1 Zack, Richard, Bert, Andrew, Paul H., Marco, Warren, Peter, Yoav, = JimC, Paul W., Scott, Jakob, Antoin, Olafur, /me If you have +1ed earlier text, please review this one since the MAY has = changed to SHOULD (no need to +1 again if you still agree). Martin Rex has some objections, so I take it as -1. Also Eric Osterweil = has objected to the badly formatted text in the beginning of this = thread; Eric could you please review current proposed text? Overall we have a very strong consensus, so I would like to end the call = by the end of this week (say Friday), so we can wrap this up and move = on. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From i.grok@comcast.net Tue Dec 6 05:05:32 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93C121F8B30 for ; Tue, 6 Dec 2011 05:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+9XSH0d1Kds for ; Tue, 6 Dec 2011 05:05:32 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id EB46021F8B49 for ; Tue, 6 Dec 2011 05:05:31 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta09.westchester.pa.mail.comcast.net with comcast id 5p5X1i00B0EZKEL59p5YvQ; Tue, 06 Dec 2011 13:05:32 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta01.westchester.pa.mail.comcast.net with comcast id 5p5W1i01Z00PQ6U3Mp5WiM; Tue, 06 Dec 2011 13:05:32 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id pB6D5SDj004967 for ; Tue, 6 Dec 2011 08:05:28 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id pB6D5Scv004966 for dane@ietf.org; Tue, 6 Dec 2011 08:05:28 -0500 Date: Tue, 6 Dec 2011 08:05:28 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20111206130528.GA2104@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> <20111201131720.GG17317@x27.adm.denic.de> <8D71ACF1-A834-4B14-8FE6-56EC72F77CC5@nic.cz> <20111203230737.GM17317@x27.adm.denic.de> <9B7A07B4-50FE-4839-8683-74B0B2E7024D@nic.cz> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <9B7A07B4-50FE-4839-8683-74B0B2E7024D@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for DNSSEC validation states ending soon (Was: RFC2119 MAY (Was: Call for consensus on level of DNSSEC support)) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 13:05:33 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 06, 2011 at 10:54:34AM +0100, Ond=C5=99ej Sur=C3=BD wrote: > I am fine with Peter's SHOULD, so the full text will be: >=20 > > An application that complies with this document first requests TLSA > > records in order to make certificate associations. > >=20 > > Determining whether a TLSA RRset can be used depends > > on the DNSSEC validation state (as defined in [RFC4033]). > >=20 > > o A TLSA RRset whose DNSSEC validation state is secure SHOULD be used > > as a certificate association for TLS. > >=20 > > o If the DNSSEC validation state on the response to the request > > for the TLSA RRset is bogus, this MUST cause TLS not to be started > > or, if the TLS negotiation is already in progress, to cause > > the connection to be aborted. > >=20 > > o A TLSA RRset whose DNSSEC validation state is indeterminate or > > insecure cannot be used for TLS and MUST be marked as unusable. >=20 > So far we have: +1 Zack, Richard, Bert, Andrew, Paul H., Marco, > Warren, Peter, Yoav, JimC, Paul W., Scott, Jakob, Antoin, Olafur, /me >=20 > If you have +1ed earlier text, please review this one since the MAY > has changed to SHOULD (no need to +1 again if you still agree). I don't object to the should. That said, I'd like to clarify the purpose of the consensus call: is it a consensus on DNSSEC processing only (but we're being very precise about the language of that processing to make sure everyone is in agreement), and we can expect that other text in the section/document will get adjusted to integrate the consensus/text, or is this more of text replacement consensus, and no other text will be modified? If the former, i'm still +1. If the latter, I have to be -1, because the old paragraph also explained how to process the records once you know they're secure, which isn't mentioned in the new version. Also, rereading section 4.4 in its entirety, we'd want to do the check above before dropping malformed or intelligible records. This would suggest something like: ["!" used for modifications, ":" for moves, reflows ignored.] 4.4. Use of TLS Certificate Associations in TLS The TLS session that is to be set up MUST be for the specific port number and transport name that was given in the TLSA query. The matching or chaining MUST be done within the life of the TTL on the TLSA record. Some specifications for applications that run under TLS, such as [RFC2818] for HTTP, require the server's certificate to have a domain name that matches the host name expected by the client. Some ! specifications such as [RFC6125] detail how to match the identity [typos: ^ ^ ] given in a PKIX certificate with those expected by the user. In order to use one or more TLS certificate associations described in this document obtained from the DNS, an application MUST assure that ! the associations were obtained using DNS protected by DNSSEC. TLSA [ ^^^^^^^^^^^^ was "certificates" ] records must only be trusted if they were obtained from a trusted source. This could be a localhost DNS resolver answer with the AD bit set, an inline validating resolver library primed with the proper trust anchors, or obtained from a remote name server to which one has a secured channel of communication. [Inserted this text here, rather than replace the last paragraph:] ! An application that complies with this document first requests TLSA ! records in order to make certificate associations. ! ! Determining whether a TLSA RRset can be used depends ! on the DNSSEC validation state (as defined in [RFC4033]). ! ! o A TLSA RRset whose DNSSEC validation state is secure SHOULD be used ! as a certificate association for TLS. ! ! o If the DNSSEC validation state on the response to the request ! for the TLSA RRset is bogus, this MUST cause TLS not to be started ! or, if the TLS negotiation is already in progress, to cause ! the connection to be aborted. ! ! o A TLSA RRset whose DNSSEC validation state is indeterminate or ! insecure cannot be used for TLS and MUST be marked as unusable. If a certificate association contains a certificate usage, selector, or matching type that is not understood by the TLS client, that certificate association MUST be marked as unusable. If the comparison data for a certificate is malformed, the certificate association MUST be marked as unusable. [Removed the first sentence of the last paragraph, as that's what I think the above text is really replacing.] ! If the application receives zero usable certificate associations, it processes TLS in the normal fashion; otherwise, that application attempts to match each certificate association with the TLS server's end entity certificate. [Moved the first paragraph here to fit into the processing better] : Section 2.1 of this document defines the mandatory matching rules for : the data from the TLS certificate associations and the certificates : received from the TLS server. If such a match is found, that application continues the TLS handshake and ignores any remaining certificate associations; otherwise, that application MUST abort the TLS handshake with an "access_denied" error. Sorry I didn't notice this earlier, but I hope the suggested text helps. --=20 Scott Schmit --y0ulUmNC+osPPQO6 Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTExMjA2MTMwNTI4WjAjBgkqhkiG9w0BCQQxFgQUTGYvQm97 BqA8NqucAJlcUOlenwYweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAFiDUsw/O RGfAL+REhWT8LHT5ytezbkkiP0xQRGGVWafN7NeLQEwmtFWgoYBUKdQJ117Qq8Ov3R7rL2lg Sdc0boZIiM4eNZHIM8ghqlrEEYeF2QaKxHNq34luIg0v9pBBb2OyUJK/jnCQjLRAD6W2V8K8 ZYpEuw/W85kainGaO5n2gZVK8j5XodQqZEKhWQEdJWVlWSEINHbNLR1KU8Alwym7F3G8JOdI J05bq+L1NPCD7JAtUZkHrzkKwbU1lToD19RrOYc2CAJuYm6lmRxme1Vu2Mlho+Evx0Psdec1 g4FUVg5cC6psWHHNOmmTeIrSBqMFoD5cQDXKzEFvX8Em4A== --y0ulUmNC+osPPQO6-- From paul.hoffman@vpnc.org Tue Dec 6 07:21:37 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3C221F8BBE for ; Tue, 6 Dec 2011 07:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6JxqIclKYX5 for ; Tue, 6 Dec 2011 07:21:37 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 20B3121F8BBC for ; Tue, 6 Dec 2011 07:21:37 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pB6FLXf9055001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Dec 2011 08:21:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: <9B7A07B4-50FE-4839-8683-74B0B2E7024D@nic.cz> Date: Tue, 6 Dec 2011 07:21:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> <20111201131720.GG17317@x27.adm.denic.de> <8D71ACF1-A834-4B14-8FE6-56EC72F77CC5@nic.cz> <20111203230737.GM17317@x27.adm.denic.de> <9B7A07B4-50FE-4839-8683-74B0B2E7024D@nic.cz> To: Ondrej Sury , Peter Koch X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Call for DNSSEC validation states ending soon (Was: RFC2119 MAY (Was: Call for consensus on level of DNSSEC support)) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 15:21:37 -0000 On Dec 6, 2011, at 1:54 AM, Ond=C5=99ej Sur=C3=BD wrote: > I am fine with Peter's SHOULD, so the full text will be: >=20 >> . . . >> o A TLSA RRset whose DNSSEC validation state is secure SHOULD be = used >> as a certificate association for TLS. Text with "SHOULD" needs to list when the "SHOULD" doesn't apply; = otherwise, implementers do not have the guidance they need. Can you (or = Peter) fill that in a bit more? If not, can we go back to "MAY"? --Paul Hoffman From ondrej.sury@nic.cz Tue Dec 6 07:46:19 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EB521F8BD7 for ; Tue, 6 Dec 2011 07:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylceLZhCf03t for ; Tue, 6 Dec 2011 07:46:15 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 85E8421F8B92 for ; Tue, 6 Dec 2011 07:46:14 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 5B40B2A2F59; Tue, 6 Dec 2011 16:46:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1323186373; bh=L9c7PTIipj3I6j/v9yH7rjsTmvaiaMuf9IXOEFc9Vpg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=gpPAobp7bduMU3qTJHqrIZDunNYeETE6ul8DVPL6mKTyXiB5CcrOS6MRp141UI4cn pfJ8H7enMZLfKgaCskG7Lt/onhMdYyKX86f91VuQqZ0skFEBlWoEZnn9xDwL1KKXKT w3gjlcGJb+iRDAGk4f0mjl0UxSm5PqEqpnuqKU9s= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Tue, 6 Dec 2011 16:46:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> <20111201131720.GG17317@x27.adm.denic.de> <8D71ACF1-A834-4B14-8FE6-56EC72F77CC5@nic.cz> <20111203230737.GM17317@x27.adm.denic.de> <9B7A07B4-50FE-4839-8683-74B0B2E7024D@nic.cz> To: Paul Hoffman X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Peter Koch , IETF DANE WG list Subject: [dane] SHOULD vs MAY for local policies (Was: Call for DNSSEC validation states ending soon) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 15:46:20 -0000 On 6. 12. 2011, at 16:21, Paul Hoffman wrote: > On Dec 6, 2011, at 1:54 AM, Ond=C5=99ej Sur=C3=BD wrote: >=20 >> I am fine with Peter's SHOULD, so the full text will be: >>=20 >>> . . . >>> o A TLSA RRset whose DNSSEC validation state is secure SHOULD be = used >>> as a certificate association for TLS. >=20 > Text with "SHOULD" needs to list when the "SHOULD" doesn't apply; = otherwise, implementers do not have the guidance they need. Can you (or = Peter) fill that in a bit more? If not, can we go back to "MAY"? Could you provide reference to that requirement? RFC2119 says: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that = there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I don't see how is that worse for implementors than: 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because = a particular marketplace requires it or because the vendor feels = that it enhances the product while another vendor may omit the same = item. An implementation which does not include a particular option MUST = be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In = the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature = the option provides.) My understanding is that we need a better text about local policy in any = case. Right now we have this text in the security recommendations: Client treatment of any information included in the trust anchor is a matter of local policy. This specification does not mandate that such information be inspected or validated by the domain name administrator. I think that Scott's proposal to modify 4.4 fits quite good here. If we are still talking about local policy than adding something like o A TLSA RRset whose DNSSEC validation state is secure SHOULD be used as a certificate association for TLS. Whether this certificate association will be used for TLS is a matter of a local policy. Or just change (f.e. elaborating on Scott's email) If such a match is found, that application continues the TLS handshake and ignores any remaining certificate associations; otherwise, that application MUST abort the TLS handshake with an "access_denied" error. to If such a match is found, that application continues the TLS handshake if the local policy allows it and ignores any remaining certificate associations; otherwise, that application MUST abort the TLS handshake with an "access_denied" error. ** Anyway the whole "local policy" is also a bit vague. What can you specify in the local policy: - to ignore specific certificate association (when you receive only this treat as empty) - to abort on specific certificate association (when you match this certificate association abort TLS) O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Tue Dec 6 07:49:39 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232B721F8BB6 for ; Tue, 6 Dec 2011 07:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyLR42cY8xx9 for ; Tue, 6 Dec 2011 07:49:38 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 04C4321F8B81 for ; Tue, 6 Dec 2011 07:49:38 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 026212A2E44; Tue, 6 Dec 2011 16:49:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1323186577; bh=tbddRFh+PLcYkokpqczs4fFEq6BCYacZkJTPMK5KJtw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=BiwLmclkSGsabfvc0olWQM6A/IKTVd7rEAz47EEjEHnoI2mipNr3ra1QXX7UMK+EP Aw5QcgxRTm5tR03+9I35CKvrF53wclVBksh9EDO7MXpDD3rlW/xdm8mOJ8pnOdmTey 145D4vVo4qTqdb2vDDX9uMgRSP6Qg8io0zgmVcy8= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20111206130528.GA2104@odin.ulthar.us> Date: Tue, 6 Dec 2011 16:49:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> <20111201131720.GG17317@x27.adm.denic.de> <8D71ACF1-A834-4B14-8FE6-56EC72F77CC5@nic.cz> <20111203230737.GM17317@x27.adm.denic.de> <9B7A07B4-50FE-4839-8683-74B0B2E7024D@nic.cz> <20111206130528.GA2104@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Call for DNSSEC validation states ending soon (Was: RFC2119 MAY (Was: Call for consensus on level of DNSSEC support)) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 15:49:39 -0000 On 6. 12. 2011, at 14:05, Scott Schmit wrote: > On Tue, Dec 06, 2011 at 10:54:34AM +0100, Ond=C5=99ej Sur=C3=BD wrote: >> I am fine with Peter's SHOULD, so the full text will be: >>=20 >>> An application that complies with this document first requests TLSA >>> records in order to make certificate associations. >>>=20 >>> Determining whether a TLSA RRset can be used depends >>> on the DNSSEC validation state (as defined in [RFC4033]). >>>=20 >>> o A TLSA RRset whose DNSSEC validation state is secure SHOULD be = used >>> as a certificate association for TLS. >>>=20 >>> o If the DNSSEC validation state on the response to the request >>> for the TLSA RRset is bogus, this MUST cause TLS not to be = started >>> or, if the TLS negotiation is already in progress, to cause >>> the connection to be aborted. >>>=20 >>> o A TLSA RRset whose DNSSEC validation state is indeterminate or >>> insecure cannot be used for TLS and MUST be marked as unusable. >>=20 >> So far we have: +1 Zack, Richard, Bert, Andrew, Paul H., Marco, >> Warren, Peter, Yoav, JimC, Paul W., Scott, Jakob, Antoin, Olafur, /me >>=20 >> If you have +1ed earlier text, please review this one since the MAY >> has changed to SHOULD (no need to +1 again if you still agree). >=20 > I don't object to the should. That said, I'd like to clarify the = purpose > of the consensus call: is it a consensus on DNSSEC processing only = (but > we're being very precise about the language of that processing to make > sure everyone is in agreement), and we can expect that other text in = the > section/document will get adjusted to integrate the consensus/text, or > is this more of text replacement consensus, and no other text will be > modified? The former. > If the former, i'm still +1. If the latter, I have to be -1, because > the old paragraph also explained how to process the records once you > know they're secure, which isn't mentioned in the new version. Also, > rereading section 4.4 in its entirety, we'd want to do the check above > before dropping malformed or intelligible records. This would suggest > something like: >=20 > ["!" used for modifications, ":" for moves, reflows ignored.] >=20 > 4.4. Use of TLS Certificate Associations in TLS >=20 > The TLS session that is to be set up MUST be for the specific port > number and transport name that was given in the TLSA query. The > matching or chaining MUST be done within the life of the TTL on the > TLSA record. >=20 > Some specifications for applications that run under TLS, such as > [RFC2818] for HTTP, require the server's certificate to have a = domain > name that matches the host name expected by the client. Some > ! specifications such as [RFC6125] detail how to match the identity > [typos: ^ ^ ] > given in a PKIX certificate with those expected by the user. >=20 > In order to use one or more TLS certificate associations described = in > this document obtained from the DNS, an application MUST assure that > ! the associations were obtained using DNS protected by DNSSEC. TLSA > [ ^^^^^^^^^^^^ was "certificates" ] > records must only be trusted if they were obtained from a trusted > source. This could be a localhost DNS resolver answer with the AD > bit set, an inline validating resolver library primed with the = proper > trust anchors, or obtained from a remote name server to which one = has > a secured channel of communication. >=20 > [Inserted this text here, rather than replace the last paragraph:] > ! An application that complies with this document first requests TLSA > ! records in order to make certificate associations. > ! > ! Determining whether a TLSA RRset can be used depends > ! on the DNSSEC validation state (as defined in [RFC4033]). > ! > ! o A TLSA RRset whose DNSSEC validation state is secure SHOULD be = used > ! as a certificate association for TLS. > ! > ! o If the DNSSEC validation state on the response to the request > ! for the TLSA RRset is bogus, this MUST cause TLS not to be = started > ! or, if the TLS negotiation is already in progress, to cause > ! the connection to be aborted. > ! > ! o A TLSA RRset whose DNSSEC validation state is indeterminate or > ! insecure cannot be used for TLS and MUST be marked as unusable. >=20 > If a certificate association contains a certificate usage, selector, > or matching type that is not understood by the TLS client, that > certificate association MUST be marked as unusable. If the > comparison data for a certificate is malformed, the certificate > association MUST be marked as unusable. >=20 > [Removed the first sentence of the last paragraph, as that's what I > think the above text is really replacing.] > ! If the application receives zero usable certificate associations, = it > processes TLS in the normal fashion; otherwise, that application > attempts to match each certificate association with the TLS server's > end entity certificate. >=20 > [Moved the first paragraph here to fit into the processing better] > : Section 2.1 of this document defines the mandatory matching rules = for > : the data from the TLS certificate associations and the certificates > : received from the TLS server. > If such a match is found, that application continues the TLS = handshake > and ignores any remaining certificate associations; otherwise, that > application MUST abort the TLS handshake with an "access_denied" > error. This should be aligned with bogus state: > If such a match is found, that application continues the TLS = handshake > and ignores any remaining certificate associations; otherwise, that > ! application MUST NOT start TLS or, if the TLS negotiation in already > ! in progress, to cause the connection to be aborted. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From paul.hoffman@vpnc.org Tue Dec 6 07:56:53 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7434221F8B81 for ; Tue, 6 Dec 2011 07:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.366 X-Spam-Level: X-Spam-Status: No, score=-102.366 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+ZDcfsyZhaM for ; Tue, 6 Dec 2011 07:56:53 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F3CB121F8B7D for ; Tue, 6 Dec 2011 07:56:52 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pB6FupBY056328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Dec 2011 08:56:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: Date: Tue, 6 Dec 2011 07:56:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <24A230F6-276C-4370-85EA-5B6B55B52740@vpnc.org> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> <20111201131720.GG17317@x27.adm.denic.de> <8D71ACF1-A834-4B14-8FE6-56EC72F77CC5@nic.cz> <20111203230737.GM17317@x27.adm.denic.de> <9B7A07B4-50FE-4839-8683-74B0B2E7024D@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1251.1) Cc: Peter Koch , IETF DANE WG list Subject: Re: [dane] SHOULD vs MAY for local policies (Was: Call for DNSSEC validation states ending soon) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 15:56:53 -0000 On Dec 6, 2011, at 7:46 AM, Ond=C5=99ej Sur=C3=BD wrote: >=20 > On 6. 12. 2011, at 16:21, Paul Hoffman wrote: >=20 >> On Dec 6, 2011, at 1:54 AM, Ond=C5=99ej Sur=C3=BD wrote: >>=20 >>> I am fine with Peter's SHOULD, so the full text will be: >>>=20 >>>> . . . >>>> o A TLSA RRset whose DNSSEC validation state is secure SHOULD be = used >>>> as a certificate association for TLS. >>=20 >> Text with "SHOULD" needs to list when the "SHOULD" doesn't apply; = otherwise, implementers do not have the guidance they need. Can you (or = Peter) fill that in a bit more? If not, can we go back to "MAY"? >=20 >=20 > Could you provide reference to that requirement? A zillion threads in dozens of WGs over the past 20 years where an = implementor didn't do what the SHOULD said because they thought they = knew better. > I think that Scott's proposal to modify 4.4 fits quite good here. If = we > are still talking about local policy than adding something like >=20 > o A TLSA RRset whose DNSSEC validation state is secure SHOULD be = used > as a certificate association for TLS. Whether this certificate > association will be used for TLS is a matter of a local policy. That works for me. A more specific way might be: o A TLSA RRset whose DNSSEC validation state is secure SHOULD be used as a certificate association for TLS unless a local policy would prohibit the use of the specific certificate association in the secure TLSA RRset. > Anyway the whole "local policy" is also a bit vague. Yes, of course. We can never put bounds on all types of local policies. > What can you specify in the local policy: > - to ignore specific certificate association > (when you receive only this treat as empty) > - to abort on specific certificate association > (when you match this certificate association abort TLS) Are you proposing that we put those restrictions on local policy in the = protocol, or simply to list them as examples of local policy? --Paul Hoffman From ondrej.sury@nic.cz Tue Dec 6 08:08:38 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0682621F856F for ; Tue, 6 Dec 2011 08:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.593 X-Spam-Level: X-Spam-Status: No, score=-1.593 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzD1ZPJ3dZjV for ; Tue, 6 Dec 2011 08:08:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B874B21F8531 for ; Tue, 6 Dec 2011 08:08:36 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id B79252A2D37; Tue, 6 Dec 2011 17:08:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1323187715; bh=u5Un5dfIKyN/N3XRUzcXbbNpeUdxfWvJ0E/0QlR6+TQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=aMo6Nf53FnWL3ZYNAHbewhch5Q/785yuhJ++80GUMjlUOUYmcIm/dNbBO8v4LwEig fzU1pfH5ZA7t9DGRfR2MH17qJvU281vpXs9FPO/kuDT8ausn0pf2tCYoRPRC7gBWwf 2XI5TBTQh8FpWI/LIF0Xb22ZVOe7AgSvjd6WePDI= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <24A230F6-276C-4370-85EA-5B6B55B52740@vpnc.org> Date: Tue, 6 Dec 2011 17:08:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4EFD32A2-8CFD-433C-A260-60AF3EED9402@nic.cz> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> <20111201131720.GG17317@x27.adm.denic.de> <8D71ACF1-A834-4B14-8FE6-56EC72F77CC5@nic.cz> <20111203230737.GM17317@x27.adm.denic.de> <9B7A07B4-50FE-4839-8683-74B0B2E7024D@nic.cz> <24A230F6-276C-4370-85EA-5B6B55B52740@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Peter Koch , IETF DANE WG list Subject: Re: [dane] SHOULD vs MAY for local policies (Was: Call for DNSSEC validation states ending soon) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 16:08:38 -0000 On 6. 12. 2011, at 16:56, Paul Hoffman wrote: > On Dec 6, 2011, at 7:46 AM, Ond=C5=99ej Sur=C3=BD wrote: >=20 >>=20 >> On 6. 12. 2011, at 16:21, Paul Hoffman wrote: >>=20 >>> On Dec 6, 2011, at 1:54 AM, Ond=C5=99ej Sur=C3=BD wrote: >>>=20 >>>> I am fine with Peter's SHOULD, so the full text will be: >>>>=20 >>>>> . . . >>>>> o A TLSA RRset whose DNSSEC validation state is secure SHOULD be = used >>>>> as a certificate association for TLS. >>>=20 >>> Text with "SHOULD" needs to list when the "SHOULD" doesn't apply; = otherwise, implementers do not have the guidance they need. Can you (or = Peter) fill that in a bit more? If not, can we go back to "MAY"? >>=20 >>=20 >> Could you provide reference to that requirement? >=20 > A zillion threads in dozens of WGs over the past 20 years where an = implementor didn't do what the SHOULD said because they thought they = knew better. Ok :) >> I think that Scott's proposal to modify 4.4 fits quite good here. If = we >> are still talking about local policy than adding something like >>=20 >> o A TLSA RRset whose DNSSEC validation state is secure SHOULD be = used >> as a certificate association for TLS. Whether this certificate >> association will be used for TLS is a matter of a local policy. >=20 > That works for me. A more specific way might be: >=20 > o A TLSA RRset whose DNSSEC validation state is secure SHOULD be used > as a certificate association for TLS unless a local policy would > prohibit the use of the specific certificate association in the > secure TLSA RRset. Works for me if it works for you. >> Anyway the whole "local policy" is also a bit vague. >=20 > Yes, of course. We can never put bounds on all types of local = policies. >=20 >> What can you specify in the local policy: >> - to ignore specific certificate association >> (when you receive only this treat as empty) >> - to abort on specific certificate association >> (when you match this certificate association abort TLS) >=20 >=20 > Are you proposing that we put those restrictions on local policy in = the protocol, or simply to list them as examples of local policy? More of questions than examples or anything else... in any case not the = restrictions. But I am fine with listing examples, since it could cut = down the creativity if we list the sane ones. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From peter@denic.de Tue Dec 6 08:10:34 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A07821F8C09 for ; Tue, 6 Dec 2011 08:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6Y2kHofxrZl for ; Tue, 6 Dec 2011 08:10:33 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 73A0C21F8BFE for ; Tue, 6 Dec 2011 08:10:33 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1RXxb2-0006my-OE; Tue, 06 Dec 2011 17:10:20 +0100 Received: from localhost by x27.adm.denic.de with local id 1RXxb2-0003bk-KX; Tue, 06 Dec 2011 17:10:20 +0100 Date: Tue, 6 Dec 2011 17:10:20 +0100 From: Peter Koch To: IETF DANE WG Message-ID: <20111206161020.GA10101@x27.adm.denic.de> Mail-Followup-To: IETF DANE WG References: <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> <20111201131720.GG17317@x27.adm.denic.de> <8D71ACF1-A834-4B14-8FE6-56EC72F77CC5@nic.cz> <20111203230737.GM17317@x27.adm.denic.de> <9B7A07B4-50FE-4839-8683-74B0B2E7024D@nic.cz> <24A230F6-276C-4370-85EA-5B6B55B52740@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24A230F6-276C-4370-85EA-5B6B55B52740@vpnc.org> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dane] SHOULD vs MAY for local policies (Was: Call for DNSSEC validation states ending soon) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 16:10:34 -0000 On Tue, Dec 06, 2011 at 07:56:51AM -0800, Paul Hoffman wrote: > A zillion threads in dozens of WGs over the past 20 years where an implementor didn't do what the SHOULD said because they thought they knew better. in general some ambiguity is a feature of "SHOULD" over "MUST", while at the same time giving guidance is probably a good idea. To that extent I think you, Paul, are on the right track, without furthering discussion about the formalities or not of a general requirement. In this particular case, we have an idea what would qualify for a "SHOULD" escape, so to preserve some of the discussion on this list, it's useful to state a reason. The guidance to the implementor then is, however, to allow for local overrides rather than not implementing the "use" at all - which would render the whole effort useless. > > o A TLSA RRset whose DNSSEC validation state is secure SHOULD be used > > as a certificate association for TLS. Whether this certificate > > association will be used for TLS is a matter of a local policy. > > That works for me. A more specific way might be: > > o A TLSA RRset whose DNSSEC validation state is secure SHOULD be used > as a certificate association for TLS unless a local policy would > prohibit the use of the specific certificate association in the > secure TLSA RRset. This second version gives more guidance, although one could now argue that the "unless" makes the exemption list complete and would actually even justify a "MUST". I'll refrain from being this "one". -Peter From sm@resistor.net Tue Dec 6 08:29:27 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC8621F8A67 for ; Tue, 6 Dec 2011 08:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EswfzZOkIw3c for ; Tue, 6 Dec 2011 08:29:21 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 035A921F8801 for ; Tue, 6 Dec 2011 08:29:20 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pB6GTDS8007162; Tue, 6 Dec 2011 08:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1323188959; bh=qQmA5gdoc5Q5UxJv0vmUxQf/5jDqKVM6oN1xDPBK1DQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=h7y95kXWHv6nOHVaVR/tVrqC49VCXIXuvl97JEOj1FYxdbABXckI8ULgqA4aY+cKO RrSqXXiE17gcJ0xbjavP3fsa+0h5awpwC5a2LVTxhjyT+MlTeOHHbgcR/P5JxI4+9r kWwz0DFolG4ErX6hpFq9NVqRfyIJVFgx5crfha5M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1323188959; bh=qQmA5gdoc5Q5UxJv0vmUxQf/5jDqKVM6oN1xDPBK1DQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=XKQN7LtIGtteFWX8V1jP7obalTHZ1m7YPIITfNeCOET26wQUh8+IsRicsel9JcT5F oVp2AUeeQAc9Qj/Ljhdsk5hRBkx4/kD7tIcakk2+aFwbvU8zLMCOeXmn2QI0ttlz4d UvT2/eVSApIRfL4f4iWKdofP01rNuTgant1Bv+I4= Message-Id: <6.2.5.6.2.20111206080841.0a546c40@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 06 Dec 2011 08:26:08 -0800 To: IETF DANE WG list From: SM Cc: IETF DANE WG list In-Reply-To: <24A230F6-276C-4370-85EA-5B6B55B52740@vpnc.org> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> <20111201131720.GG17317@x27.adm.denic.de> <8D71ACF1-A834-4B14-8FE6-56EC72F77CC5@nic.cz> <20111203230737.GM17317@x27.adm.denic.de> <9B7A07B4-50FE-4839-8683-74B0B2E7024D@nic.cz> <24A230F6-276C-4370-85EA-5B6B55B52740@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dane] SHOULD vs MAY for local policies (Was: Call for DNSSEC validation states ending soon) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 16:29:27 -0000 At 07:56 06-12-2011, Paul Hoffman wrote: >Are you proposing that we put those restrictions on local policy in >the protocol, or simply to list them as examples of local policy? Restricting local policy is akin to censorship. :-) It's better to provide guidance, e.g. informative examples and leave it to the implementor to decide. Regards, -sm From ietf@augustcellars.com Tue Dec 6 11:44:05 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C26121F8C22 for ; Tue, 6 Dec 2011 11:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.831 X-Spam-Level: X-Spam-Status: No, score=-2.831 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viy4xigFchB9 for ; Tue, 6 Dec 2011 11:44:04 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7492921F8B67 for ; Tue, 6 Dec 2011 11:44:04 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id B29672CA18; Tue, 6 Dec 2011 11:44:03 -0800 (PST) From: "Jim Schaad" To: =?utf-8?Q?'Ondrej_Sur=C3=BD'?= , "'IETF DANE WG list'" References: <4ED7B326.4020704@nic.cz> <6997ED7D-A028-487A-BBF0-0888FE9E4CE4@vpnc.org> <4ED821F1.4000703@nic.cz> <20111203225335.GL17317@x27.adm.denic.de> <4EDAEF78.80504@nic.cz> In-Reply-To: Date: Tue, 6 Dec 2011 11:43:34 -0800 Message-ID: <017301ccb44f$57a10c10$06e32430$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF9njdbYC/MIDgDNCJ6rDoPvoYR2gK/fcgTAc3vuEgCJNScwAJcgdWHARQWL8+WHEelUA== Content-Language: en-us Subject: Re: [dane] Addition to "Security considerations" section - usage type 0 with SubjectPublicKeyInfo selector X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 19:44:05 -0000 I kind of read this text, despaired and then, because I was at the = winery, shrugged off and tried to forget. Issues that I have: 1. I don't know how to identify cross-certificates and thus cannot = figure out how to identify these in the second paragraph. 2. A large part of the reasons that I would use a certificate with a = usage field of 0 would be to force specific extensions to be used during = the process of PKIX certificate validation. This recommendation does = not allow for that to be the recommended usage and thus gives me a = problem. 3. As was pointed out, rolling over CA certificates is not an issue as = multiple TLSA records with a usage field of 0 can be in the DNS records. = This means that basing the behavior on the CA roll over case is = probably not valid. 4. I don't understand what is being said in the second sentence of the = first paragraph. I assume this came about as a result of the = discussions dealing with the fact that the Msft code will actually = re-build the certificate chain from scratch rather than use the one = provided by the TLS server in its messages. In the case of the Msft = code, it will also return ALL of the chains that were found so that the = client code can select the chain(s) that match the DANE restrictions if = such a chain can be built to a trusted anchor. The case where this = would not be doable are going to be those cases which are, I think, = addressed in the second paragraph where an alternative chain with a = cross certificate (possibly issued by my corp) are found. 5. It is not clear to me that the most predictable processing would be = done by making the association on the CA closest to the client = certificate as oppose to being on the most distant certificate. What do = you want to be able to be predictable? The enforcement of the selected = extensions chosen by the CA issuer or the ability to be any arbitrary = chain that will get to some trust anchor? Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of > Ondrej Sur=C3=BD > Sent: Tuesday, December 06, 2011 1:42 AM > To: IETF DANE WG list > Subject: Re: [dane] Addition to "Security considerations" section - = usage type > 0 with SubjectPublicKeyInfo selector >=20 > Hi all, >=20 > any objections to adding this text to operational recommendations = section? > I feel that the text was generally well received and thus no call is = needed > (unless I hear from you now). >=20 > O. >=20 > On 4. 12. 2011, at 4:56, Ondrej Mikle wrote: > > ---begin text normative version--- > > > > When deploying TLSA record with certificate usage field 0, it is > > RECOMMENDED to use selector type 1 (SubjectPublicKeyInfo) in such = TLSA > > record. Many TLS clients exchange intermediate certificates in = chains > > sent by server while performing PKIX validation. Reason for such > > behavior is that CA certificates are often > > reissued: with different expiry dates, stronger hashing algorithm, > > etc. If the aforementioned TLSA record used selector type 0 (full > > certificate), it might cause interoperability problems for TLS = client > > that swapped CA certificate for one with identical public key. > > > > TLSA record with certificate usage type 0 SHOULD NOT associate with = a > > cross-certificate. TLS clients often cut certificate chain short = once > > the client reaches an intermediate certificate which chains to a = trust > > anchor in client's trusted certificate store. Association with a > > cross-certificate would be thus rejected by the client. It is > > RECOMMENDED that the association is made with a CA certificate that > > directly signed the leaf certificate since it gives the most = predictable > processing on client's side. > > > > ---end text normative version--- >=20 > -- > Ondrej Sur > vedouc v zkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratore CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ietf@augustcellars.com Tue Dec 6 11:45:21 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3B721F8B67 for ; Tue, 6 Dec 2011 11:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-+U0c2WJR-V for ; Tue, 6 Dec 2011 11:45:21 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 031F621F8C18 for ; Tue, 6 Dec 2011 11:45:21 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id A8AD32CA0C; Tue, 6 Dec 2011 11:45:20 -0800 (PST) From: "Jim Schaad" To: =?utf-8?Q?'Ondrej_Sur=C3=BD'?= References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> <20111201131720.GG17317@x27.adm.denic.de> <8D71ACF1-A834-4B14-8FE6-56EC72F77CC5@nic.cz> <20111203230737.GM17317@x27.adm.denic.de> <9B7A07B4-50FE-4839-8683-74B0B2E7024D@nic.cz> In-Reply-To: <9B7A07B4-50FE-4839-8683-74B0B2E7024D@nic.cz> Date: Tue, 6 Dec 2011 11:44:51 -0800 Message-ID: <017401ccb44f$8575aec0$90610c40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGut/YJDNlSCGQivK9LrRHjlJIdAgMw0D5YAZIwvGYBa3GUPgK6NfQHAtbEpMkCFicPiwJW8yxiALHsVmwB4mf/0wGO1p8VAkenqq+VVnQhgA== Content-Language: en-us Cc: 'IETF DANE WG list' Subject: Re: [dane] Call for DNSSEC validation states ending soon (Was: RFC2119 MAY (Was: Call for consensus on level of DNSSEC support)) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 19:45:21 -0000 -1 I believe that if the policy statement needs to be made, then it should = be made in a different location and the MAY needs to be a MUST. > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of > Ondrej Sur=C3=BD > Sent: Tuesday, December 06, 2011 1:55 AM > To: Eric Osterweil > Cc: IETF DANE WG list > Subject: [dane] Call for DNSSEC validation states ending soon (Was: = RFC2119 > MAY (Was: Call for consensus on level of DNSSEC support)) >=20 >=20 > On 4. 12. 2011, at 0:07, Peter Koch wrote: >=20 > > On Thu, Dec 01, 2011 at 08:15:09PM +0100, Ond??ej Sur wrote: > > > >> We are asking 'whether X can be used' > >> > >>> o A TLSA RRset whose DNSSEC validation state is secure can be used > >>> as a certificate association for TLS. > >> > >> > >> We are saying: 'Yes, it can be used'. > > > > in my eyes this is fuzzy wording. > > > >> I may be wrong, but I don't see a need for normative MAY here. > > > > If I read the discussion correctly, "SHOULD" is probably what you're = looking > for: > > "using" the TLSA RR is the recommended way forward and exceptional > > circumstances (local policy override) might suggest otherwise. >=20 > I am fine with Peter's SHOULD, so the full text will be: >=20 > > An application that complies with this document first requests = TLSA > > records in order to make certificate associations. > > > > Determining whether a TLSA RRset can be used depends > > on the DNSSEC validation state (as defined in [RFC4033]). > > > > o A TLSA RRset whose DNSSEC validation state is secure SHOULD be = used > > as a certificate association for TLS. > > > > o If the DNSSEC validation state on the response to the request > > for the TLSA RRset is bogus, this MUST cause TLS not to be = started > > or, if the TLS negotiation is already in progress, to cause > > the connection to be aborted. > > > > o A TLSA RRset whose DNSSEC validation state is indeterminate or > > insecure cannot be used for TLS and MUST be marked as unusable. >=20 >=20 > So far we have: > +1 Zack, Richard, Bert, Andrew, Paul H., Marco, Warren, Peter, Yoav, > +JimC, Paul W., Scott, Jakob, Antoin, Olafur, /me >=20 > If you have +1ed earlier text, please review this one since the MAY = has > changed to SHOULD (no need to +1 again if you still agree). >=20 > Martin Rex has some objections, so I take it as -1. Also Eric = Osterweil has > objected to the badly formatted text in the beginning of this thread; = Eric > could you please review current proposed text? >=20 > Overall we have a very strong consensus, so I would like to end the = call by > the end of this week (say Friday), so we can wrap this up and move on. >=20 > O. > -- > Ondrej Sur > vedouc v zkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratore CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From mrex@sap.com Tue Dec 6 13:25:18 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B574B21F8C0C for ; Tue, 6 Dec 2011 13:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.133 X-Spam-Level: X-Spam-Status: No, score=-10.133 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZ+jIRmiuyLv for ; Tue, 6 Dec 2011 13:25:18 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7C30221F8C14 for ; Tue, 6 Dec 2011 13:25:15 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pB6LOl4g020356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Dec 2011 22:24:47 +0100 (MET) From: Martin Rex Message-Id: <201112062124.pB6LOk4x016998@fs4113.wdf.sap.corp> To: ietf@augustcellars.com (Jim Schaad) Date: Tue, 6 Dec 2011 22:24:46 +0100 (MET) In-Reply-To: <017301ccb44f$57a10c10$06e32430$@augustcellars.com> from "Jim Schaad" at Dec 6, 11 11:43:34 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Addition to "Security considerations" section - X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 21:25:18 -0000 Jim Schaad wrote: > > I kind of read this text, despaired and then, > because I was at the winery, shrugged off and tried to forget. While I do understand the technical problem, I do not really understand the meaning of the proposed text. > > Issues that I have: > > 1. I don't know how to identify cross-certificates and thus cannot > figure out how to identify these in the second paragraph. One of the PKIX folks recently told me that the term "intermediate CA" is no longer used, and every CA cert that is neither self-signed nor self-issued is called a cross-certificate. > > 2. A large part of the reasons that I would use a certificate with > a usage field of 0 would be to force specific extensions to be used > during the process of PKIX certificate validation. > This recommendation does not allow for that to be the recommended > usage and thus gives me a problem. You can force 100% of the acceptable characteristics by listing the server certificate that you're using. The only reason not to list the server certificate but rather the CA's certificate that signed the server's certificate is the lifetime difference (the issuing CA's cert lifetime is typically 5-10 years whereas the server's cert lifetime is typically 1 year (because markedroids might change names or the company or business might be sold). > > 3. As was pointed out, rolling over CA certificates is not an issue > as multiple TLSA records with a usage field of 0 can be in the > DNS records. This means that basing the behavior on the CA roll > over case is probably not valid. You're missing the point. You may get your server cert issued with a lifetime of 1 year when the remaining lifetime of the issuing CAs cert is 1.5 years. When the DNS zone is configured and the server cert is installed on the server, the successor CA cert does not even exist yet. 6 months later, a new issuing CA cert with an extended lifetime is created (so that further server certs with a lifetime of one year can be issued), and the renewed CA cert slowly migrates onto clients of the installed base, some of which cache such intermediate CA certs and reuse it for certificate path discovery before validating server certificates. Server admins do not track such CA cert renewals, because the CA cert that they send in their forward path has sufficient lifetime left on it. Anyhow there are TLS clients in the installed base that might replace the CA cert sent by the server with a newer one they obtained from another Web Server that they connected to. > > 5. It is not clear to me that the most predictable processing would > be done by making the association on the CA closest to the client > certificate as oppose to being on the most distant certificate. > What do you want to be able to be predictable? The enforcement > of the selected extensions chosen by the CA issuer or the ability > to be any arbitrary chain that will get to some trust anchor? The problem here is that every client might built his certficate chain individually different from any other client and different from the server, so the only two things that are reliably predictable for the server admin are the server certificate itself, and the subjectpublickeyinfo that can be used to verify the signature on the server certificate. Everything else has the potential to badly interfere with weird PKI cross-certifictations that might be in use on some of the clients. -Martin From ietf@augustcellars.com Tue Dec 6 14:34:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4389421F8C66 for ; Tue, 6 Dec 2011 14:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.215 X-Spam-Level: X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtcmBcUCM5jf for ; Tue, 6 Dec 2011 14:34:28 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFBD21F8B50 for ; Tue, 6 Dec 2011 14:34:28 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 926362CA13; Tue, 6 Dec 2011 14:34:27 -0800 (PST) From: "Jim Schaad" To: References: <017301ccb44f$57a10c10$06e32430$@augustcellars.com> from "Jim Schaad" at Dec 6, 11 11:43:34 am <201112062124.pB6LOk4x016998@fs4113.wdf.sap.corp> In-Reply-To: <201112062124.pB6LOk4x016998@fs4113.wdf.sap.corp> Date: Tue, 6 Dec 2011 14:33:58 -0800 Message-ID: <001401ccb467$25ecd150$71c673f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIWq+wEStU34gkH/JcV290ABtBhzpU7b7YQ Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] Addition to "Security considerations" section - X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 22:34:29 -0000 > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Tuesday, December 06, 2011 1:25 PM > To: Jim Schaad > Cc: ondrej.sury@nic.cz; dane@ietf.org > Subject: Re: [dane] Addition to "Security considerations" section - > > Jim Schaad wrote: > > > > I kind of read this text, despaired and then, because I was at the > > winery, shrugged off and tried to forget. > > While I do understand the technical problem, I do not really understand the > meaning of the proposed text. > > > > > > Issues that I have: > > > > 1. I don't know how to identify cross-certificates and thus cannot > > figure out how to identify these in the second paragraph. > > One of the PKIX folks recently told me that the term "intermediate CA" > is no longer used, and every CA cert that is neither self-signed nor self-issued > is called a cross-certificate. > That would not be a definition that I would ever use. The term cross-cert means something very specific to me. However if that were the case, then the text would make even less since you would be "going through" a certificate and that would not be a certificate - i.e. what you claim is now referred to as a cross-cert. I would probably just refer to it as a CA certificate, but since I am old and inflexible I would also use the term intermediate. Looking at RFC 4949 - it still says that cross-certificates are for use between different PKIs. However, there is nothing in the certificate itself which distinguishes it between a normal CA certificate and a cross-certificate. > > > > 2. A large part of the reasons that I would use a certificate with a > > usage field of 0 would be to force specific extensions to be used > > during the process of PKIX certificate validation. > > This recommendation does not allow for that to be the recommended > > usage and thus gives me a problem. > > You can force 100% of the acceptable characteristics by listing the server > certificate that you're using. I would disagree with this statement, but then I doubt that you care about those extensions which are hierarchical in nature and therefore you believe this to be a true statement. > > The only reason not to list the server certificate but rather the CA's certificate > that signed the server's certificate is the lifetime difference (the issuing CA's > cert lifetime is typically 5-10 years whereas the server's cert lifetime is > typically 1 year (because markedroids might change names or the company > or business might be sold). > Or a situation where you might return different server certificates based on the TLS handshake and don't want to overload the DNS with all of the different possible server certificates you might be returning. > > > > > 3. As was pointed out, rolling over CA certificates is not an issue > > as multiple TLSA records with a usage field of 0 can be in the DNS > > records. This means that basing the behavior on the CA roll over case > > is probably not valid. > > You're missing the point. You may get your server cert issued with a lifetime > of 1 year when the remaining lifetime of the issuing CAs cert is 1.5 years. > When the DNS zone is configured and the server cert is installed on the > server, the successor CA cert does not even exist yet. 6 months later, a new > issuing CA cert with an extended lifetime is created (so that further server > certs with a lifetime of one year can be issued), and the renewed CA cert > slowly migrates onto clients of the installed base, some of which cache such > intermediate CA certs and reuse it for certificate path discovery before > validating server certificates. > > Server admins do not track such CA cert renewals, because the CA cert that > they send in their forward path has sufficient lifetime left on it. Anyhow > there are TLS clients in the installed base that might replace the CA cert sent > by the server with a newer one they obtained from another Web Server that > they connected to. > And low and behold, if that is the case then some of the client software will also say that there is not a valid path through the new certificate since there is a school of thought which says that a certificate must be properly nested in the time scale of its parent certificate. I doubt that I would have much sympathy for such a set of client software (either one). So you are assuming that you have a CA which does not change its keys, that the TLS server does not send a certificate chain and you have a client cache which can hold only one CA certificate for a given public key. This seems more brain dead than normal. > > > > > 5. It is not clear to me that the most predictable processing would > > be done by making the association on the CA closest to the client > > certificate as oppose to being on the most distant certificate. > > What do you want to be able to be predictable? The enforcement of the > > selected extensions chosen by the CA issuer or the ability to be any > > arbitrary chain that will get to some trust anchor? > > The problem here is that every client might built his certficate chain > individually different from any other client and different from the server, so > the only two things that are reliably predictable for the server admin are the > server certificate itself, and the subjectpublickeyinfo that can be used to > verify the signature on the server certificate. Everything else has the > potential to badly interfere with weird PKI cross-certifictations that might be > in use on some of the clients. > And thus the admin is banned from doing what they want to get the best possible enforcement of the certificate policies that it is selecting - this seems to be bad design. The situation will be even worse if they happen to use the usage 2 and people do cross certificates. I thought that one of the things that DANE was setup to avoid was the entire world of people issuing cross-certificates that were not desired by the TLS site administrator. Now you are telling me that this is not of any interest at all. Go figure. jim > > -Martin From i.grok@comcast.net Tue Dec 6 17:04:12 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4CB21F8558 for ; Tue, 6 Dec 2011 17:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4hiocz7NTVw for ; Tue, 6 Dec 2011 17:04:11 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 782D811E8096 for ; Tue, 6 Dec 2011 17:04:11 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta13.westchester.pa.mail.comcast.net with comcast id 5z8p1i00c1ZXKqc5D14B8u; Wed, 07 Dec 2011 01:04:11 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta21.westchester.pa.mail.comcast.net with comcast id 614A1i00i00PQ6U3h14BeQ; Wed, 07 Dec 2011 01:04:11 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id pB7147Iu006449 for ; Tue, 6 Dec 2011 20:04:07 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id pB7147l9006448 for dane@ietf.org; Tue, 6 Dec 2011 20:04:07 -0500 Date: Tue, 6 Dec 2011 20:04:07 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20111207010407.GB2104@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <20111201124746.GA61329@shinkuro.com> <20111201131720.GG17317@x27.adm.denic.de> <8D71ACF1-A834-4B14-8FE6-56EC72F77CC5@nic.cz> <20111203230737.GM17317@x27.adm.denic.de> <9B7A07B4-50FE-4839-8683-74B0B2E7024D@nic.cz> <20111206130528.GA2104@odin.ulthar.us> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="H1spWtNR+x+ondvy" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for DNSSEC validation states ending soon (Was: RFC2119 MAY (Was: Call for consensus on level of DNSSEC support)) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 01:04:12 -0000 --H1spWtNR+x+ondvy Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 06, 2011 at 04:49:36PM +0100, Ond=C5=99ej Sur=C3=BD wrote: > On 6. 12. 2011, at 14:05, Scott Schmit wrote: >=20 > > If such a match is found, that application continues the TLS handshake > > and ignores any remaining certificate associations; otherwise, that > > application MUST abort the TLS handshake with an "access_denied" > > error. >=20 > This should be aligned with bogus state: >=20 > > If such a match is found, that application continues the TLS handshake > > and ignores any remaining certificate associations; otherwise, that > > ! application MUST NOT start TLS or, if the TLS negotiation in already > > ! in progress, to cause the connection to be aborted. The reason I didn't was because at the point you're matching the TLSA RR to the certificate recieved from TLS, you--by definition--have already started the TLS negotiation. --=20 Scott Schmit --H1spWtNR+x+ondvy Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTExMjA3MDEwNDA3WjAjBgkqhkiG9w0BCQQxFgQUCJJ9lnNR vf7B/moK8ckfu9WdU6wweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAfhB6s6iR fCo7OBUeOb4MyTEltM0G/CuQQJDkHM/ukoxig0cZG8RW5DSsPkcX8RoNmg/gV7BiBq7bjD2d WbH6XIx5+8KHfFe8uhWtR6LtcPf1kAV4gkE9gbIQkp0jy9sK+M3JGOPGzOAQIKsB+94ZGBD1 LzLdiF9e3Ec4JrZ09MALEWgnEbPPrCecrneHdB5gukYENqWAOjIch9S05I8+mlNZp3JoPhMM l2TVn8QB4SQUdH8tw4aaSvQn/0C4k/l9wYqz+cWUMPqBf6rZdZ1bF17HUX7mEE9T68XL5juL Jv7SvaN1klxIW/2wVu2qQ1IUnZsTWl7DbRw2vOV/r3EgdA== --H1spWtNR+x+ondvy-- From ondrej.mikle@nic.cz Wed Dec 7 08:10:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD7D21F8C0C for ; Wed, 7 Dec 2011 08:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3LiFw8SAJvd for ; Wed, 7 Dec 2011 08:10:46 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C047E21F8C4F for ; Wed, 7 Dec 2011 08:10:45 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2] (unknown [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2]) by mail.nic.cz (Postfix) with ESMTPSA id 942022A0971 for ; Wed, 7 Dec 2011 17:10:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1323274206; bh=3Vkhty8OMteCx/klG+RfQ0CRTsQ1LtYGs84NzOmA0no=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=t+wyKxwXun0orWW1PGPcujQhK8n0PHMwhcBoi1yWj0l2VlX9RSMEqxrmvSOJtAS34 TLdaD10f/DrRN1UH27CwL4ki8EDZQq2RFvqBCz9TzvCiZ4CXt9Z1h91jQSABv+xpQP en0JQ+ohDrpHWuYXP0xgc89InUpiyBln2JKWCOFE= Message-ID: <4EDF8FC1.2080303@nic.cz> Date: Wed, 07 Dec 2011 17:09:37 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Red Hat/3.1.16-2.el6_1 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org References: <017301ccb44f$57a10c10$06e32430$@augustcellars.com> from "Jim Schaad" at Dec 6, 11 11:43:34 am <201112062124.pB6LOk4x016998@fs4113.wdf.sap.corp> <001401ccb467$25ecd150$71c673f0$@augustcellars.com> In-Reply-To: <001401ccb467$25ecd150$71c673f0$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Addition to "Security considerations" section - X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 16:10:47 -0000 On 12/06/2011 11:33 PM, Jim Schaad wrote: >> -----Original Message----- >> From: Martin Rex [mailto:mrex@sap.com] >> Sent: Tuesday, December 06, 2011 1:25 PM >> To: Jim Schaad >> Cc: ondrej.sury@nic.cz; dane@ietf.org >> Subject: Re: [dane] Addition to "Security considerations" section - >> >> Jim Schaad wrote: >>> >>> Issues that I have: >>> >>> 1. I don't know how to identify cross-certificates and thus cannot >>> figure out how to identify these in the second paragraph. >> >> One of the PKIX folks recently told me that the term "intermediate CA" >> is no longer used, and every CA cert that is neither self-signed nor > self-issued >> is called a cross-certificate. >> > > That would not be a definition that I would ever use. The term cross-cert > means something very specific to me. However if that were the case, then > the text would make even less since you would be "going through" a > certificate and that would not be a certificate - i.e. what you claim is now > referred to as a cross-cert. I would probably just refer to it as a CA > certificate, but since I am old and inflexible I would also use the term > intermediate. Looking at RFC 4949 - it still says that cross-certificates > are for use between different PKIs. However, there is nothing in the > certificate itself which distinguishes it between a normal CA certificate > and a cross-certificate. The term 'cross-certificate' was meant as described in RFC 4949, as you say (which I believe is the way the term is commonly used). I admit that it is difficult to describe it in technical terms, i.e. extra information is necessary than just the fields of certificate. >>> 2. A large part of the reasons that I would use a certificate with a >>> usage field of 0 would be to force specific extensions to be used >>> during the process of PKIX certificate validation. >>> This recommendation does not allow for that to be the recommended >>> usage and thus gives me a problem. >> >> You can force 100% of the acceptable characteristics by listing the server >> certificate that you're using. > > I would disagree with this statement, but then I doubt that you care about > those extensions which are hierarchical in nature and therefore you believe > this to be a true statement. I wrote an informal comment before expressing that: "A possible reason to use full certificate in the certificate usage 0 case anyway is when the site operator/admin/etc absolutely wants to ensure that extensions of the certificate he chose needs to be preserved." Would it make it more acceptable for you if a formalized version of the comment was added to the proposed text? >>> 3. As was pointed out, rolling over CA certificates is not an issue >>> as multiple TLSA records with a usage field of 0 can be in the DNS >>> records. This means that basing the behavior on the CA roll over case >>> is probably not valid. >> >> You're missing the point. You may get your server cert issued with a > lifetime >> of 1 year when the remaining lifetime of the issuing CAs cert is 1.5 > years. >> When the DNS zone is configured and the server cert is installed on the >> server, the successor CA cert does not even exist yet. 6 months later, a > new >> issuing CA cert with an extended lifetime is created (so that further > server >> certs with a lifetime of one year can be issued), and the renewed CA cert >> slowly migrates onto clients of the installed base, some of which cache > such >> intermediate CA certs and reuse it for certificate path discovery before >> validating server certificates. >> >> Server admins do not track such CA cert renewals, because the CA cert that >> they send in their forward path has sufficient lifetime left on it. > Anyhow >> there are TLS clients in the installed base that might replace the CA cert > sent >> by the server with a newer one they obtained from another Web Server that >> they connected to. >> > > And low and behold, if that is the case then some of the client software > will also say that there is not a valid path through the new certificate > since there is a school of thought which says that a certificate must be > properly nested in the time scale of its parent certificate. I doubt that I > would have much sympathy for such a set of client software (either one). So > you are assuming that you have a CA which does not change its keys, that the > TLS server does not send a certificate chain and you have a client cache > which can hold only one CA certificate for a given public key. This seems > more brain dead than normal. The case I'm seeing more often is that client software swaps certificate for one having stronger hash function, but identical public key, issuer, subject and (almost) identical validity period (difference of one day). Note that in these cases the swapped certificate is client's built-in trust anchor and the TLS server sends proper chain. >>> 5. It is not clear to me that the most predictable processing would >>> be done by making the association on the CA closest to the client >>> certificate as oppose to being on the most distant certificate. >>> What do you want to be able to be predictable? The enforcement of the >>> selected extensions chosen by the CA issuer or the ability to be any >>> arbitrary chain that will get to some trust anchor? >> >> The problem here is that every client might built his certficate chain >> individually different from any other client and different from the > server, so >> the only two things that are reliably predictable for the server admin are > the >> server certificate itself, and the subjectpublickeyinfo that can be used > to >> verify the signature on the server certificate. Everything else has the >> potential to badly interfere with weird PKI cross-certifictations that > might be >> in use on some of the clients. >> > > And thus the admin is banned from doing what they want to get the best > possible enforcement of the certificate policies that it is selecting - this > seems to be bad design. The situation will be even worse if they happen to > use the usage 2 and people do cross certificates. I thought that one of the > things that DANE was setup to avoid was the entire world of people issuing > cross-certificates that were not desired by the TLS site administrator. Now > you are telling me that this is not of any interest at all. Go figure. No, the admin is not banned from using association with a full certificate. It is a recommendation to avoid breakage listing some of the reasons seen in actual deployment so that the admin can figure when to make an exception. As I stated before, my goal is to have it documented; I don't insist on normative version. Ondrej From ietf@augustcellars.com Thu Dec 8 11:37:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B4321F8B77 for ; Thu, 8 Dec 2011 11:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.292 X-Spam-Level: X-Spam-Status: No, score=-3.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1na38x0DQSkR for ; Thu, 8 Dec 2011 11:37:10 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6615B21F8B76 for ; Thu, 8 Dec 2011 11:37:10 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 81BDC38F49; Thu, 8 Dec 2011 11:37:09 -0800 (PST) From: "Jim Schaad" To: "'Ondrej Mikle'" , References: <017301ccb44f$57a10c10$06e32430$@augustcellars.com> from "Jim Schaad" at Dec 6, 11 11:43:34 am <201112062124.pB6LOk4x016998@fs4113.wdf.sap.corp> <001401ccb467$25ecd150$71c673f0$@augustcellars.com> <4EDF8FC1.2080303@nic.cz> In-Reply-To: <4EDF8FC1.2080303@nic.cz> Date: Thu, 8 Dec 2011 11:36:40 -0800 Message-ID: <003e01ccb5e0$b5761be0$206253a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMxa6gy6miAcgn5tDNAlmvMh4dkxgIWq+wEAhRLlX0BELC/IZLfAYRQ Content-Language: en-us Subject: Re: [dane] Addition to "Security considerations" section - X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 19:37:11 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Ondrej Mikle > Sent: Wednesday, December 07, 2011 8:10 AM > To: dane@ietf.org > Subject: Re: [dane] Addition to "Security considerations" section - > > On 12/06/2011 11:33 PM, Jim Schaad wrote: > >> -----Original Message----- > >> From: Martin Rex [mailto:mrex@sap.com] > >> Sent: Tuesday, December 06, 2011 1:25 PM > >> To: Jim Schaad > >> Cc: ondrej.sury@nic.cz; dane@ietf.org > >> Subject: Re: [dane] Addition to "Security considerations" section - > >> > >> Jim Schaad wrote: > >>> > >>> Issues that I have: > >>> > >>> 1. I don't know how to identify cross-certificates and thus cannot > >>> figure out how to identify these in the second paragraph. > >> > > The term 'cross-certificate' was meant as described in RFC 4949, as you > say (which I believe is the way the term is commonly used). I admit that > it is difficult to describe it in technical terms, i.e. extra > information is necessary than just the fields of certificate. > Ok - given that a cross-certificate would have the same key as the original key. How can one possibly enforce the SHOULD NOT in the first line of the second paragraph? I would think that the whole thing is to allow for a cross-certificate if one specifies match by key. > >>> 2. A large part of the reasons that I would use a certificate with a > >>> usage field of 0 would be to force specific extensions to be used > >>> during the process of PKIX certificate validation. > >>> This recommendation does not allow for that to be the recommended > >>> usage and thus gives me a problem. > >> > >> You can force 100% of the acceptable characteristics by listing the server > >> certificate that you're using. > > > > I would disagree with this statement, but then I doubt that you care about > > those extensions which are hierarchical in nature and therefore you > believe > > this to be a true statement. > > I wrote an informal comment before expressing that: > > "A possible reason to use full certificate in the certificate usage 0 > case anyway is when the site operator/admin/etc absolutely wants to > ensure that extensions of the certificate he chose needs to be preserved." > > Would it make it more acceptable for you if a formalized version of the > comment was added to the proposed text? I think it would be more acceptable to give both sides of the argument in terms of which option one would want to use and then to remove the normative language. > > >>> 3. As was pointed out, rolling over CA certificates is not an issue > >>> as multiple TLSA records with a usage field of 0 can be in the DNS > >>> records. This means that basing the behavior on the CA roll over case > >>> is probably not valid. > >> > >> You're missing the point. You may get your server cert issued with a > > lifetime > >> of 1 year when the remaining lifetime of the issuing CAs cert is 1.5 > > years. > >> When the DNS zone is configured and the server cert is installed on the > >> server, the successor CA cert does not even exist yet. 6 months later, a > > new > >> issuing CA cert with an extended lifetime is created (so that further > > server > >> certs with a lifetime of one year can be issued), and the renewed CA cert > >> slowly migrates onto clients of the installed base, some of which cache > > such > >> intermediate CA certs and reuse it for certificate path discovery before > >> validating server certificates. > >> > >> Server admins do not track such CA cert renewals, because the CA cert > that > >> they send in their forward path has sufficient lifetime left on it. > > Anyhow > >> there are TLS clients in the installed base that might replace the CA cert > > sent > >> by the server with a newer one they obtained from another Web Server > that > >> they connected to. > >> > > > > And low and behold, if that is the case then some of the client software > > will also say that there is not a valid path through the new certificate > > since there is a school of thought which says that a certificate must be > > properly nested in the time scale of its parent certificate. I doubt that I > > would have much sympathy for such a set of client software (either one). > So > > you are assuming that you have a CA which does not change its keys, that > the > > TLS server does not send a certificate chain and you have a client cache > > which can hold only one CA certificate for a given public key. This seems > > more brain dead than normal. > > The case I'm seeing more often is that client software swaps certificate > for one having stronger hash function, but identical public key, issuer, > subject and (almost) identical validity period (difference of one day). > Note that in these cases the swapped certificate is client's built-in > trust anchor and the TLS server sends proper chain. Are you suggesting this is a new certificate representing a known TA? If so then it would be more appropriate to have a usage type of 2 rather than 0 in this case. If the TA is a local certificate to the client then a whole different set of problems ensue. I would argue that there is a large difference between talking about a generic CA certificate being re-issued for various reasons and a TA certificate being re-issued for much the same reasons. If you want to discuss what happens when a TA certificate is re-issued and how and administrator should handle that, that that is fine. But please be clear exactly what cases you are addressing. > > >>> 5. It is not clear to me that the most predictable processing would > >>> be done by making the association on the CA closest to the client > >>> certificate as oppose to being on the most distant certificate. > >>> What do you want to be able to be predictable? The enforcement of the > >>> selected extensions chosen by the CA issuer or the ability to be any > >>> arbitrary chain that will get to some trust anchor? > >> > >> The problem here is that every client might built his certficate chain > >> individually different from any other client and different from the > > server, so > >> the only two things that are reliably predictable for the server admin are > > the > >> server certificate itself, and the subjectpublickeyinfo that can be used > > to > >> verify the signature on the server certificate. Everything else has the > >> potential to badly interfere with weird PKI cross-certifictations that > > might be > >> in use on some of the clients. > >> > > > > And thus the admin is banned from doing what they want to get the best > > possible enforcement of the certificate policies that it is selecting - this > > seems to be bad design. The situation will be even worse if they happen to > > use the usage 2 and people do cross certificates. I thought that one of the > > things that DANE was setup to avoid was the entire world of people issuing > > cross-certificates that were not desired by the TLS site administrator. Now > > you are telling me that this is not of any interest at all. Go figure. > > No, the admin is not banned from using association with a full > certificate. It is a recommendation to avoid breakage listing some of > the reasons seen in actual deployment so that the admin can figure when > to make an exception. Ok - but you are making a strong recommendation without given a suggestion on when it would not be followed. You are talking to people who are probably not going to understand the subtleties of the issues and thus be able to make good decisions. They are going to generally blindly follow the recommendation especially since it is stated in normative language. Jim > > As I stated before, my goal is to have it documented; I don't insist on > normative version. > > Ondrej > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From mrex@sap.com Fri Dec 9 06:31:04 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A0521F85DB for ; Fri, 9 Dec 2011 06:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.061 X-Spam-Level: X-Spam-Status: No, score=-10.061 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc91I-Xo51gG for ; Fri, 9 Dec 2011 06:31:03 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A572221F85CE for ; Fri, 9 Dec 2011 06:31:02 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pB9EUtgf027426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Dec 2011 15:30:55 +0100 (MET) From: Martin Rex Message-Id: <201112091430.pB9EUs0S026400@fs4113.wdf.sap.corp> To: ietf@augustcellars.com (Jim Schaad) Date: Fri, 9 Dec 2011 15:30:54 +0100 (MET) In-Reply-To: <001401ccb467$25ecd150$71c673f0$@augustcellars.com> from "Jim Schaad" at Dec 6, 11 02:33:58 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Addition to "Security considerations" section - X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 14:31:04 -0000 Jim Schaad wrote: > >Martin Rex wrote: >> >> Jim Schaad wrote: >> > >> > Issues that I have: >> > >> > 1. I don't know how to identify cross-certificates and thus cannot >> > figure out how to identify these in the second paragraph. >> >> One of the PKIX folks recently told me that the term "intermediate CA" >> is no longer used, and every CA cert that is neither self-signed nor >> self-issued is called a cross-certificate. > > That would not be a definition that I would ever use. The term cross-cert > means something very specific to me. However if that were the case, then > the text would make even less since you would be "going through" a > certificate and that would not be a certificate - i.e. what you claim is now > referred to as a cross-cert. I would probably just refer to it as a CA > certificate, but since I am old and inflexible I would also use the term > intermediate. Looking at RFC 4949 - it still says that cross-certificates > are for use between different PKIs. However, there is nothing in the > certificate itself which distinguishes it between a normal CA certificate > and a cross-certificate. Thanks for the Pointer to rfc4949. It reads (on bottom of that page): http://tools.ietf.org/html/rfc4949#page-156 $ intermediate CA (D) The CA that issues a cross-certificate to another CA. [X509] (See: cross-certification.) Deprecated Term: IDOCs SHOULD NOT use this term because it is not widely known and mixes concepts in a potentially misleading way. For example, suppose that end entity 1 ("EE1) is in one PKI ("PKI1"), end entity 2 ("EE2) is in another PKI ("PKI2"), and the root in PKI1 ("CA1") cross-certifies the root CA in PKI2 ("CA2"). Then, if EE1 constructs the certification path CA1-to-CA2-to-EE2 to validate a certificate of EE2, conventional English usage would describe CA2 as being in the "intermediate" position in that path, not CA1. Considering the definition of cross-certification (bottom of this page): http://tools.ietf.org/html/rfc4949#page-86 $ cross-certification (I) The act or process by which a CA in one PKI issues a public- key certificate to a CA in another PKI. [X509] (See: bridge CA.) Tutorial: X.509 says that a CA (say, CA1) may issue a "cross- certificate" in which the subject is another CA (say, CA2). X.509 calls CA2 the "subject CA" and calls CA1 an "intermediate CA", but this Glossary deprecates those terms. (See: intermediate CA, subject CA). this looks inconsistent to me, and create the impression to delibertately sneak a PKI architectural change past implementors and protocol designers. -Martin From ondrej.mikle@nic.cz Mon Dec 12 07:00:22 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144FD21F8B5A for ; Mon, 12 Dec 2011 07:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NR6vOJOSIF1 for ; Mon, 12 Dec 2011 07:00:21 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DAA9221F8B51 for ; Mon, 12 Dec 2011 07:00:20 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2] (unknown [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2]) by mail.nic.cz (Postfix) with ESMTPSA id 67B022A2F4F; Mon, 12 Dec 2011 16:00:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1323702019; bh=/N3pPTTTuvX71IGj+/K33zu6BrAEJeJ3VPRrVSv/7Ug=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=JJ5j9yNbZkqZ7u+vTl1jPhnNZYXNJhoec92+Biihehsy20i3PpSstOmNf9JGFpR0o 0DNOss3/AGvBvd5uzHzgaVtfLQW3BmAn8Tiri96y542MumctM2dJ0XpuEYUUHhraLv Ugi+oI2fAB4G/4KuHUbIhNbGnUyqdvS7/VN1Ap4g= Message-ID: <4EE616E7.2090507@nic.cz> Date: Mon, 12 Dec 2011 15:59:51 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Red Hat/3.1.16-2.el6_1 Thunderbird/3.1.16 MIME-Version: 1.0 To: Jim Schaad References: <017301ccb44f$57a10c10$06e32430$@augustcellars.com> from "Jim Schaad" at Dec 6, 11 11:43:34 am <201112062124.pB6LOk4x016998@fs4113.wdf.sap.corp> <001401ccb467$25ecd150$71c673f0$@augustcellars.com> <4EDF8FC1.2080303@nic.cz> <003e01ccb5e0$b5761be0$206253a0$@augustcellars.com> In-Reply-To: <003e01ccb5e0$b5761be0$206253a0$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Addition to "Security considerations" section - X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 15:00:22 -0000 I'll write a new non-normative version. I'll just need to get two issues clear (see inline comments below). On 12/08/2011 08:36 PM, Jim Schaad wrote: > > >> -----Original Message----- >> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of >> Ondrej Mikle >> Sent: Wednesday, December 07, 2011 8:10 AM >> To: dane@ietf.org >> Subject: Re: [dane] Addition to "Security considerations" section - >> >> The term 'cross-certificate' was meant as described in RFC 4949, as you >> say (which I believe is the way the term is commonly used). I admit that >> it is difficult to describe it in technical terms, i.e. extra >> information is necessary than just the fields of certificate. >> > > Ok - given that a cross-certificate would have the same key as the original > key. How can one possibly enforce the SHOULD NOT in the first line of the > second paragraph? I would think that the whole thing is to allow for a > cross-certificate if one specifies match by key. I see your point. I'll break it down to two cases (CA1 issues cross-certificate to CA2): - case 1: association to cross-certificate with selector type 0 (full certificate) - clients are known to cut chains in this case, such association would be discouraged - case 2: association with selector type 1 (SPKI) which happens to match other CA2 (root) certificate as well as a cross-certificate issued by CA1 to CA2 - I don't see a problem here >> The case I'm seeing more often is that client software swaps certificate >> for one having stronger hash function, but identical public key, issuer, >> subject and (almost) identical validity period (difference of one day). >> Note that in these cases the swapped certificate is client's built-in >> trust anchor and the TLS server sends proper chain. > > Are you suggesting this is a new certificate representing a known TA? If so > then it would be more appropriate to have a usage type of 2 rather than 0 in > this case. If the TA is a local certificate to the client then a whole > different set of problems ensue. I would argue that there is a large > difference between talking about a generic CA certificate being re-issued > for various reasons and a TA certificate being re-issued for much the same > reasons. If you want to discuss what happens when a TA certificate is > re-issued and how and administrator should handle that, that that is fine. > But please be clear exactly what cases you are addressing. It's happening in both cases: the "generic CA cert case" and the "TA cert case" (the latter being more common). The "TA case" seems to be less predictable in respect to processing at client side: There exist two 'versions' of a CA certificate: deprecated certificate C1 with obsolete hashing algorithm and certificate C2 with stronger hashing algorithm. Many servers still send certificate chain containing the deprecated C1. Some clients will accept C1 as trust anchor, while other swap it for C2. (Certificates with obsolete hash algorithm in signature algorithm are being slowly phased out from clients' trust stores, but at different rate.) Ondrej From ietf@augustcellars.com Mon Dec 12 16:13:34 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ED621F8551 for ; Mon, 12 Dec 2011 16:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZQ2iYqgSVil for ; Mon, 12 Dec 2011 16:13:33 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4EF21F8472 for ; Mon, 12 Dec 2011 16:13:25 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id DE02E38F19; Mon, 12 Dec 2011 16:13:24 -0800 (PST) From: "Jim Schaad" To: "'Ondrej Mikle'" References: <017301ccb44f$57a10c10$06e32430$@augustcellars.com> from "Jim Schaad" at Dec 6, 11 11:43:34 am <201112062124.pB6LOk4x016998@fs4113.wdf.sap.corp> <001401ccb467$25ecd150$71c673f0$@augustcellars.com> <4EDF8FC1.2080303@nic.cz> <003e01ccb5e0$b5761be0$206253a0$@augustcellars.com> <4EE616E7.2090507@nic.cz> In-Reply-To: <4EE616E7.2090507@nic.cz> Date: Mon, 12 Dec 2011 16:12:54 -0800 Message-ID: <015e01ccb92b$f67b4db0$e371e910$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMxa6gy6miAcgn5tDNAlmvMh4dkxgIWq+wEAhRLlX0BELC/IQJZL3+hAicnaqOSwYYNwA== Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] Addition to "Security considerations" section - X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 00:13:34 -0000 > -----Original Message----- > From: Ondrej Mikle [mailto:ondrej.mikle@nic.cz] > Sent: Monday, December 12, 2011 7:00 AM > To: Jim Schaad > Cc: dane@ietf.org > Subject: Re: [dane] Addition to "Security considerations" section - > > I'll write a new non-normative version. I'll just need to get two issues clear > (see inline comments below). > > On 12/08/2011 08:36 PM, Jim Schaad wrote: > > > > > >> -----Original Message----- > >> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf > >> Of Ondrej Mikle > >> Sent: Wednesday, December 07, 2011 8:10 AM > >> To: dane@ietf.org > >> Subject: Re: [dane] Addition to "Security considerations" section - > >> > >> The term 'cross-certificate' was meant as described in RFC 4949, as > >> you say (which I believe is the way the term is commonly used). I > >> admit that it is difficult to describe it in technical terms, i.e. > >> extra information is necessary than just the fields of certificate. > >> > > > > Ok - given that a cross-certificate would have the same key as the > > original key. How can one possibly enforce the SHOULD NOT in the > > first line of the second paragraph? I would think that the whole > > thing is to allow for a cross-certificate if one specifies match by key. > > I see your point. I'll break it down to two cases (CA1 issues cross-certificate to > CA2): > > - case 1: association to cross-certificate with selector type 0 (full > certificate) - clients are known to cut chains in this case, such association > would be discouraged > > - case 2: association with selector type 1 (SPKI) which happens to match > other CA2 (root) certificate as well as a cross-certificate issued by > CA1 to CA2 - I don't see a problem here > Tell me again what the goal of the working group is. My first thought is that if CA2 is the root cert that is being used by the host, then I would expect it to potentially be setup as a trust anchor record and thus you example above could be moot. I don't know that case 1 should be discouraged or encouraged. It should be stated what the goal of the administrator is. From that which case to be used would fall out. > > >> The case I'm seeing more often is that client software swaps > >> certificate for one having stronger hash function, but identical > >> public key, issuer, subject and (almost) identical validity period (difference > of one day). > >> Note that in these cases the swapped certificate is client's built-in > >> trust anchor and the TLS server sends proper chain. > > > > Are you suggesting this is a new certificate representing a known TA? > > If so then it would be more appropriate to have a usage type of 2 > > rather than 0 in this case. If the TA is a local certificate to the client then a > whole > > different set of problems ensue. I would argue that there is a large > > difference between talking about a generic CA certificate being > > re-issued for various reasons and a TA certificate being re-issued for > > much the same reasons. If you want to discuss what happens when a TA > > certificate is re-issued and how and administrator should handle that, that > that is fine. > > But please be clear exactly what cases you are addressing. > > It's happening in both cases: the "generic CA cert case" and the "TA cert > case" (the latter being more common). > > The "TA case" seems to be less predictable in respect to processing at client > side: > There exist two 'versions' of a CA certificate: deprecated certificate > C1 with obsolete hashing algorithm and certificate C2 with stronger hashing > algorithm. Many servers still send certificate chain containing the deprecated > C1. Some clients will accept C1 as trust anchor, while other swap it for C2. > (Certificates with obsolete hash algorithm in signature algorithm are being > slowly phased out from clients' trust stores, but at different rate.) Unless the C1 has been revoked, one can hardly say it is deprecated. It is still a completely valid certificate. I agree that this is the case. Again, what is the problem that the DANE working group is trying to solve? What is the attack case that mimics this same situation and one is trying to prevent. When looking at trust anchors, I tend to be much looser about what is in the self-signed certificate as in this case many systems will ignore the extensions anyway in favor of local configuration and just worry about what the key value is. This would mimic using the SPK as the matching point. But this would be in the context of a trust anchor statement and not a CA statement. > > Ondrej From trac+dane@trac.tools.ietf.org Thu Dec 15 05:00:24 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878DB21F8AAC for ; Thu, 15 Dec 2011 05:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTScarpjzcG5 for ; Thu, 15 Dec 2011 05:00:20 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6822921F852E for ; Thu, 15 Dec 2011 05:00:19 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RbAun-0008TZ-BX; Thu, 15 Dec 2011 08:00:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, matt@mattmccutchen.net, ondrej.sury@nic.cz X-Trac-Project: dane Date: Thu, 15 Dec 2011 13:00:00 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/dane/trac/ticket/36#comment:2 Message-ID: <075.ca189032e0452d9885e0aa53272c8275@trac.tools.ietf.org> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> X-Trac-Ticket-ID: 36 In-Reply-To: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, matt@mattmccutchen.net, ondrej.sury@nic.cz, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111215130020.6822921F852E@ietfa.amsl.com> Resent-Date: Thu, 15 Dec 2011 05:00:19 -0800 (PST) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 13:00:24 -0000 #36: Only requiring DNSSEC where it is needed Changes (by ondrej.sury@…): * status: new => closed * resolution: => fixed Comment: Consensus was reached on incorporating following text into the draft: An application that complies with this document first requests TLSA records in order to make certificate associations. Determining whether a TLSA RRset can be used depends on the DNSSEC validation state (as defined in [RFC4033]). o A TLSA RRset whose DNSSEC validation state is secure MUST be used as a certificate association for TLS unless a local policy would prohibit the use of the specific certificate association in the secure TLSA RRset. o If the DNSSEC validation state on the response to the request for the TLSA RRset is bogus, this MUST cause TLS not to be started or, if the TLS negotiation is already in progress, to cause the connection to be aborted. o A TLSA RRset whose DNSSEC validation state is indeterminate or insecure cannot be used for TLS and MUST be marked as unusable. -- ----------------------------+----------------------------------------- Reporter: paul.hoffman@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------+----------------------------------------- Ticket URL: dane From ondrej.mikle@nic.cz Sun Dec 18 14:06:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E93821F8B1B for ; Sun, 18 Dec 2011 14:06:45 -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_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTSFj-O9oSF5 for ; Sun, 18 Dec 2011 14:06:44 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CDB9421F8B16 for ; Sun, 18 Dec 2011 14:06:39 -0800 (PST) Received: from [172.30.151.65] (ip-84-42-137-177.net.upcbroadband.cz [84.42.137.177]) by mail.nic.cz (Postfix) with ESMTPSA id 2E4092A2F40 for ; Sun, 18 Dec 2011 23:06:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1324245996; bh=JnXSHH6sX/6nIZgEc/u0ediIVIeqMoNP0PHNaAwzJyw=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=b0dfYaDV0j8AqZ4CeMRqXqLI35dHFCFW4c3/kZfjgxF2fRxIzg/2en33dkhEMyHRK xr2HUKRJungWy3mweaws/hisXKIxMKhyZDxpicgWTdbserc0tdt1lVaHRGnDA8BLdl Ouky4Ef6k91Zx2Q8xBGSRKsO6RwcKei3EYlZL7Rk= Message-ID: <4EEE63EB.9020800@nic.cz> Date: Sun, 18 Dec 2011 23:06:35 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110409 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] New "operational considerations" text (was: Addition to "Security considerations") X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 22:06:45 -0000 I've written new non-normative version of text concerning association of certificate usage 0 and 2. Hopefully I did not miss any important point from the discussions so far. I tried to make text as clear as possible to DNS admins/operators who might have no deep knowledge about minutiae in TLS clients' approaches when building certificate chain. Use cases are outlined and administrator/operator is advised why they happen, which choice is better for given situation. I hoped to the balance between possibility of (yet unknown) future attacks and false positive rate (clients denying association). Also see notes below the text with additional suggestions that could be incorporated into the text. RFC technicalities: RFC 4949 deprecates term "CA certificate", though RFC 5280 uses it. RFC 4949 suggests that is should be defined explicitly (as v3 X.509 public-key certificate that has a "basicConstraints" extension containing a "cA" value of "TRUE"; possibly adding v1 certificates may be necessary). Formatting notes: **line** stands for subsection, [--line--] for internal comment. ---begin text--- When creating TLSA record with certificate usage type 0 or 2, care should be taken when choosing between selector type 0 (full certificate) and 1 (SubjectPublicKeyInfo). Careful choice is required due to algorithms in various TLS clients employed to build client's trust-chain. We first outline cases to be aware of and then discuss implications on choice of selector type. Certificate usage 2 is unaffected if association is made to an end entity certificate. **Ambiguities and corner cases of trust-chain building by TLS clients** TLS clients are known to implement methods that may cause any certificate except end entity certificate in original certificate chain sent by server to be exchanged or removed from the chain when client builds trust chain. Certificates the client can use to replace certificates from original chain include: - client's trust anchors - certificates cached locally - certificates retrieved via URI listed in Authority Information Access X.509v3 extension. CAs frequently reissue certificates with different validity period, hash in signature algorithm or extensions (public key, issuer and subject remain intact). Those are the certificates TLS client can use in place of original certificate. Cases when clients are known to exchange or remove certificates that could cause TLSA association by full certificate to fail are listed below: 1. client considers hash in signature algorithm of a certificate no longer sufficiently secure 2. a cross-certificate issued to CA2 by CA1 is represented by a self-signed root certificate of CA2 as a trust anchor in client's trust store 3. a CA certificate above cross-certificate in original chain may be removed from chain, because client found a trust anchor below said CA certificate **Discussion on choice of selector type** 1. Choosing selector type 0 "Full certificate" selector provides most precise specification of trust anchor. Such non-ambiguity foils class of hypothetical future attacks on CA where CA issues new certificate with identical SubjectPublicKeyInfo, but different issuer, subject, extensions (which would allow redirect trust chain). This selector would also foil bad practices or negligence of CA should CA use identical key for unrelated CA certificates. For DNS administrator, best course to avoid false-positive failures at client's side when using this selector is: - don't associate to CA certificates having signature algorithm with hash that is considered weak if CA issued a replacement certificate - check how common client programs process the TLSA association on fresh client installations - local certificate cache needs to be empty. 2. Choosing selector type 1 SPKI selector gives greater flexibility in avoiding share of false-positive failures caused by trust-chain-building algorithms used in clients. One specific use-case should be noted: creating TLSA association to certificate I1 that directly signed end entity certificate S1 of server. Since the key used to sign S1 is fixed, association to I1 must succeed - if client swaps I1 for other certificate I2, its SPKI must match SPKI of I1. Such association would not suffer from false-positive failure on client's side should the client use a reissued CA certificate I2 in place of I1. The attack surface is a bit broader compared to "full certificate" selector: - administrator must know or trust the CA not to engage in bad practices (not sharing key of I1 for unrelated CA certs leading to trust-chain redirect) - administrator should understand whether some X.509v3 extension may adversely affect security of the association. If possible, administrator should overview CA certificates sharing the SPKI. Using SPKI selector for association with a certificate in chain above I1 is to be decided on by-case basis. There are too many possibilities depending on issuing CA. Unless full implications of such association are understood by administrator, using selector type 0 might be better option security-wise. [--following paragraph might need update--] In practice, sharing keys in differently-purposed CA certificates is rare, nevertheless not non-existent. Attack on association by SPKI would require either gross negligence on CA's part or an attacker gaining control of CA. ---end text--- Some additions that could be made to the above text that I am not sure whether they are suitable/allowed for RFC text: I'd like to mention Valicert as a great example of CA issuing cross-certificates (Valicert certificates are present in cert chains sent by at least 400000 hosts). I believe such example would be much more understandable to administrators (target audience) than RFC 4949 definitions. Preceding discussions raised point that cross-certificate cannot be identified from its fields alone. Best document I've found so far identifying CAs issuing cross-certificates is the CA graph done by EFF (I mean primarily the textual discrete graph graphviz source - nodes being CAs and edges showing certifications). Otherwise cross-signing CAs may be found only by reading CPS. On a similar note, listing MD2 and MD5 as "hash algorithms considered weak at the time of writing" would be clearer, too (again not sure whether allowed in RFC). Ad last paragraph "needing update": I've dug a bit into collected CA certificate data to see if CA certificate pairs sharing same public key might belong to different entities. One sample pair found shows key sharing between UK CA and US RA for different products (having different guarantees). This might also be a good reason for suggesting TLSA associations are to be made to certificates lower in the chain (for both selector types). Ondrej Mikle From internet-drafts@ietf.org Mon Dec 19 08:01:40 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108CA1F0C50; Mon, 19 Dec 2011 08:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6pvjisFSOgA; Mon, 19 Dec 2011 08:01:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75921F0C4B; Mon, 19 Dec 2011 08:01:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111219160139.30815.77214.idtracker@ietfa.amsl.com> Date: Mon, 19 Dec 2011 08:01:39 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-13.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 16:01:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Ent= ities Working Group of the IETF. Title : Using Secure DNS to Associate Certificates with Domain N= ames For TLS Author(s) : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-protocol-13.txt Pages : 20 Date : 2011-12-19 TLS and DTLS use PKIX certificates for authenticating the server. Users want their applications to verify that the certificate provided by the TLS server is in fact associated with the domain name they expect. TLSA provides bindings of keys to domains that are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate the TLS server's certificate with the intended domain name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-protocol-13.txt From paul.hoffman@vpnc.org Mon Dec 19 08:03:39 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EF51F0C4F for ; Mon, 19 Dec 2011 08:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPy35P3pA2G1 for ; Mon, 19 Dec 2011 08:03:38 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 978ED1F0C4C for ; Mon, 19 Dec 2011 08:03:38 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pBJG3bE9060784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 19 Dec 2011 09:03:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Dec 2011 08:03:38 -0800 Message-Id: <79E7614A-B28B-4994-AA27-4C8F10915F1F@vpnc.org> To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [dane] Posted draft -13 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 16:03:39 -0000 Greetings again. We have published draft -13, which we thinks reflects = all of the decisions made at the Taiwan face-to-face meeting. The diff = from the previous draft is at = . In specific, we made changes for issues #8, #10, #36. We also note that = issue 23 and 38 weren't closed in the tracker but we think the minutes = say that it was decided to do so, and that #37 wasn't opened on the list = again but the minutes indicate that it will be. We look forward to = making changes as issues are resolved and hopefully finishing work on = this document very soon. --Paul Hoffman From zack.weinberg@gmail.com Mon Dec 19 09:05:03 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F127821F84D2 for ; Mon, 19 Dec 2011 09:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhNEwHgmp40y for ; Mon, 19 Dec 2011 09:05:03 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6F521F84CE for ; Mon, 19 Dec 2011 09:05:03 -0800 (PST) Received: by obcuz6 with SMTP id uz6so2069083obc.31 for ; Mon, 19 Dec 2011 09:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=iIxqrhQloOJvGvmP+Yd3FKk8A568/C77JJ4IsLgdTKQ=; b=WmC9wydbX7R6i3d4IOFabS3zigylzunc5uJTnNx+3/H+of2YEj6sm1pvSMCRc/uEZB O61fuOKE/tHzIzN/ppaXHW9dBd660f/Zx0Mm2R94sJamhdNx3FBQRD2apJu1nDmJO7OP IYbqXdIR7EGYK4refn/ammb57ojv37cQIuu3k= MIME-Version: 1.0 Received: by 10.182.13.105 with SMTP id g9mr10552547obc.63.1324314303095; Mon, 19 Dec 2011 09:05:03 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.75.9 with HTTP; Mon, 19 Dec 2011 09:05:03 -0800 (PST) In-Reply-To: <79E7614A-B28B-4994-AA27-4C8F10915F1F@vpnc.org> References: <79E7614A-B28B-4994-AA27-4C8F10915F1F@vpnc.org> Date: Mon, 19 Dec 2011 09:05:03 -0800 X-Google-Sender-Auth: vSku2OvBRNUb5lN6NqbkXUNyK6E Message-ID: From: Zack Weinberg To: Paul Hoffman , IETF DANE WG list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dane] Posted draft -13 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 17:05:04 -0000 I have a long list of issues to file (from the previous draft - haven't read the new one yet; based on mailing list discussion, some probably have been addressed, but many haven't), but I am not going to have time to do it until after January 6. I will try to do it as quickly as possible after that. Most of my concerns relate to presentation rather than content, but the current presentation is bad enough that I cannot support the document for publication as is. You have in the past said that you wished issues came with suggested text. It would be significantly easier to suggest text if the source document (whatever format it's in) were available to work with, instead of just the generated ASCII form. zw On Mon, Dec 19, 2011 at 8:03 AM, Paul Hoffman wrote= : > Greetings again. We have published draft -13, which we thinks reflects al= l of the decisions made at the Taiwan face-to-face meeting. The diff from t= he previous draft is at . > > In specific, we made changes for issues #8, #10, #36. We also note that i= ssue 23 and 38 weren't closed in the tracker but we think the minutes say t= hat it was decided to do so, and that #37 wasn't opened on the list again b= ut the minutes indicate that it will be. We look forward to making changes = as issues are resolved and hopefully finishing work on this document very s= oon. > > --Paul Hoffman > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From warren@kumari.net Tue Dec 20 10:12:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8856811E8089 for ; Tue, 20 Dec 2011 10:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4Adqv6rM+RV for ; Tue, 20 Dec 2011 10:12:47 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id F2C7411E8083 for ; Tue, 20 Dec 2011 10:12:46 -0800 (PST) Received: from [192.168.0.105] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id D86D21B4068A; Tue, 20 Dec 2011 13:12:45 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Dec 2011 13:12:44 -0500 Message-Id: <71A91CF2-3058-4EF2-ABC0-769B5882C3B4@kumari.net> To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] (Belated) Resolutions from Taipei. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:12:47 -0000 What with one things and another, we get distracted and didn't do what = we promised... During the Taipei meeting we discussed the open issues, and resolutions = were discussed and proposed (to be approved by the list). Some of these = needed text (#8, #10, #36; incorporated into -13), but for some of them = there was no action needed. So, unless I hear very strong objections, we are closing issues were it = was felt no action needed: Issue #23 Idea: Use DANE to assert that no TLS services exist at = specified host and port Proposal: Defer to a separate document, don't address in the = base specification Text for issue tracker: "This is being deferred to a separate = document. We are making the issue as closed, will tag it with a keyword = ("revisit") so we can find it easily again if we want additional work in = the future :-P" Issue # 38 Idea: Enable support for DANE within EAP-FAST Proposal: Do nothing in the protocol specification. *** No objects to this proposal *** CONCLUSION: Do nothing in the protocol document Text for issue tracker: "This issue is being closed, marked as = "wontfix"" For issues number #8, #10 and #36, the authors were asked to incorporate = text -- the text for #36 has already been discussed onlist and consensus = reached. The WG is requested to please confirm (silence will be considered = consent!) that they accept the text incorporated to address issues #8 = and #10, so that we can close these issues too. Once this is done we will (as threatened) open #37... W =09 From zack.weinberg@gmail.com Tue Dec 20 10:31:58 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA22611E8083 for ; Tue, 20 Dec 2011 10:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7wQ2LcKOtcB for ; Tue, 20 Dec 2011 10:31:58 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFA211E807F for ; Tue, 20 Dec 2011 10:31:57 -0800 (PST) Received: by obcuz6 with SMTP id uz6so2929318obc.31 for ; Tue, 20 Dec 2011 10:31:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wZ10Ph3Z7F/O6UJmrouL/xKEq/1ejVU8txIBD3S5Q1M=; b=TJRxXlPjpgYr5Lv9gHBB3vcX6qO/RNQ/Lxs6+lPhfkACUcgq263qZRUVa6fWnKT+4Z SEeXEu2i2mcH0MkYWGwW/pAFYFJFAff7MevVkxfoS7OPBJIsbQhdRD8HSwAXa48qI/PC G6yBcsd6lJAwiZjnAN7UpF/VSgBr1HDFJLf+8= MIME-Version: 1.0 Received: by 10.182.13.105 with SMTP id g9mr2713815obc.63.1324405917665; Tue, 20 Dec 2011 10:31:57 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.75.9 with HTTP; Tue, 20 Dec 2011 10:31:57 -0800 (PST) In-Reply-To: <71A91CF2-3058-4EF2-ABC0-769B5882C3B4@kumari.net> References: <71A91CF2-3058-4EF2-ABC0-769B5882C3B4@kumari.net> Date: Tue, 20 Dec 2011 10:31:57 -0800 X-Google-Sender-Auth: 5pwzpIwZ7u-BKEUwUORiuhLnt6o Message-ID: From: Zack Weinberg To: Warren Kumari Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF DANE WG list Subject: Re: [dane] (Belated) Resolutions from Taipei. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:31:58 -0000 On Tue, Dec 20, 2011 at 10:12 AM, Warren Kumari wrote: > Issue #23 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Idea: Use DANE to assert that no TLS se= rvices exist at specified host > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and port > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Proposal: Defer to a separate document,= don't address in the base > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specification > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Text for issue tracker: "This is being = deferred to a separate document. We are making the issue as closed, will ta= g it with a keyword ("revisit") so we can find it easily again if we want a= dditional work in the future :-P" I'm fine with this resolution, but I suggest that in this document, opcode 0 should be reserved (in all three code bytes) for a hypothetical future "no TLS services at this extended name" record, sliding the existing codes down one. zw From paul.hoffman@vpnc.org Tue Dec 20 10:59:38 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CE721F86A5 for ; Tue, 20 Dec 2011 10:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgOmKMR1pYxu for ; Tue, 20 Dec 2011 10:59:38 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1B08E21F86A0 for ; Tue, 20 Dec 2011 10:59:38 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pBKIxaoC026811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Dec 2011 11:59:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 20 Dec 2011 10:59:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <71A91CF2-3058-4EF2-ABC0-769B5882C3B4@kumari.net> To: Zack Weinberg X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] (Belated) Resolutions from Taipei. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:59:38 -0000 On Dec 20, 2011, at 10:31 AM, Zack Weinberg wrote: > On Tue, Dec 20, 2011 at 10:12 AM, Warren Kumari = wrote: >> Issue #23 >> Idea: Use DANE to assert that no TLS services exist at = specified host >> and port >> Proposal: Defer to a separate document, don't address in the = base >> specification >> Text for issue tracker: "This is being deferred to a = separate document. We are making the issue as closed, will tag it with a = keyword ("revisit") so we can find it easily again if we want additional = work in the future :-P" >=20 > I'm fine with this resolution, but I suggest that in this document, > opcode 0 should be reserved (in all three code bytes) for a > hypothetical future "no TLS services at this extended name" record, > sliding the existing codes down one. That proposal is the opposite of "defer", and also makes "0" special. = When the issue comes up in a separate document, the codes can be = assigned there. Application developers will understand "4 means no TLS" = as well as they would "0 means no TLS". I support the decision in Taipei to actually defer this. --Paul Hoffman From warren@kumari.net Tue Dec 20 14:10:48 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0113C11E8095 for ; Tue, 20 Dec 2011 14:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjrK1plhuJAm for ; Tue, 20 Dec 2011 14:10:47 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC1911E807F for ; Tue, 20 Dec 2011 14:10:47 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 54FAF1B4068A; Tue, 20 Dec 2011 17:10:40 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <71A91CF2-3058-4EF2-ABC0-769B5882C3B4@kumari.net> Date: Tue, 20 Dec 2011 17:10:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8EDA9B83-738F-4126-8201-30CF3874EA34@kumari.net> References: <71A91CF2-3058-4EF2-ABC0-769B5882C3B4@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] (Belated) Resolutions from Taipei. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 22:10:48 -0000 On Dec 20, 2011, at 1:12 PM, Warren Kumari wrote: > What with one things and another, we get distracted and didn't do what = we promised... >=20 > During the Taipei meeting we discussed the open issues, and = resolutions were discussed and proposed (to be approved by the list). = Some of these needed text (#8, #10, #36; incorporated into -13), but for = some of them there was no action needed. >=20 > So, unless I hear very strong objections, we are closing issues were = it was felt no action needed: > Issue #23 > Idea: Use DANE to assert that no TLS services exist at = specified host > and port > Proposal: Defer to a separate document, don't address in the = base > specification > Text for issue tracker: "This is being deferred to a separate = document. We are making the issue as closed, will tag it with a keyword = ("revisit") so we can find it easily again if we want additional work in = the future :-P" >=20 > Issue # 38 > Idea: Enable support for DANE within EAP-FAST > Proposal: Do nothing in the protocol specification. > *** > No objects to this proposal > *** > CONCLUSION: Do nothing in the protocol document > Text for issue tracker: "This issue is being closed, marked = as "wontfix"" >=20 > For issues number #8, #10 and #36, the authors were asked to = incorporate text -- the text for #36 has already been discussed onlist = and consensus reached. > The WG is requested to please confirm (silence will be considered = consent!) that they accept the text incorporated to address issues #8 = and #10, so that we can close these issues too. Just to clarify (and to stop folk having to run the diffs themselves): Text added to satisfy #8: Clients that validate the DNSSEC signatures themselves SHOULD = use=09 standard DNSSEC validation procedures. Clients that do not = validate=09 the DNSSEC signatures themselves MUST use a secure transport = (e.g.,=09 TSIG [RFC2845], SIG(0) [RFC2931], or IPsec [RFC6071]) between=09= themselves and the entity performing the signature = validation. Text added to satisfy #10: If a server's certificate is revoked, or if an intermediate = CA in a=09 chain between the end entity and a trust anchor has its = certificate=09 revoked, a TLSA record with a certificate type of 2 that = matches the=09 revoked certificate would in essence override the revocation = because=09 the client would treat that revoked certificate as a trust = anchor and=09 thus not check its revocation status. Because of this, = domain=09 administrators need to be responsible for being sure that the = key or=09 certificate used in TLSA records with a certificate type of 2 = are in=09 fact able to be used as reliable trust anchors. Text added for #36 is in the issue tracker, consensus was called last = week. > Once this is done we will (as threatened) open #37... As many folk have vacations and other distractions at this time of year, = the opening of #37 will not happen till early / mid January... W >=20 > W >=20 >=20 > =09 >=20 From jakob@kirei.se Tue Dec 20 22:45:54 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8095021F8477 for ; Tue, 20 Dec 2011 22:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mAqzEgWAUoH for ; Tue, 20 Dec 2011 22:45:53 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 33D7E21F846B for ; Tue, 20 Dec 2011 22:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=Vwf6gTYlJlvbT+rompj74jk7XFC/+iRGXLsYxKzzm/c=; b=zVTngMiNqxNtNqrgsT7mPnpr0phrBR4uzIo3rb6OhSc+ySmSM5f2fp45gFFbhRY6gia7COJm8izK4 thAP6PDDblniznEzFjWgRSKtV7cRmt2U+62Gct3Y55nJY8QSrDLKpquP2aAZtYqGfHG/fvNMcAAFJZ YopgbIAh6yy2+yKc= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 21 Dec 2011 07:45:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Wed, 21 Dec 2011 07:45:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8E7A489B-5969-41E9-8A40-75BDE5C4F3C9@kirei.se> References: <71A91CF2-3058-4EF2-ABC0-769B5882C3B4@kumari.net> To: Paul Hoffman X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] (Belated) Resolutions from Taipei. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 06:45:54 -0000 On 20 dec 2011, at 19:59, Paul Hoffman wrote: > That proposal is the opposite of "defer", and also makes "0" special. = When the issue comes up in a separate document, the codes can be = assigned there. Application developers will understand "4 means no TLS" = as well as they would "0 means no TLS". FWIW, and although I agree with Paul H that zero is not special, I do = like the esthetics if reserving zero. jakob From paul.hoffman@vpnc.org Wed Dec 21 07:32:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D457A21F8A57 for ; Wed, 21 Dec 2011 07:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxAi8uk-CKM1 for ; Wed, 21 Dec 2011 07:32:43 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 67ACE21F8A56 for ; Wed, 21 Dec 2011 07:32:43 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pBLFWfIm076165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Dec 2011 08:32:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <8E7A489B-5969-41E9-8A40-75BDE5C4F3C9@kirei.se> Date: Wed, 21 Dec 2011 07:32:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <71A91CF2-3058-4EF2-ABC0-769B5882C3B4@kumari.net> <8E7A489B-5969-41E9-8A40-75BDE5C4F3C9@kirei.se> To: Jakob Schlyter X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] (Belated) Resolutions from Taipei. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 15:32:44 -0000 On Dec 20, 2011, at 10:45 PM, Jakob Schlyter wrote: > On 20 dec 2011, at 19:59, Paul Hoffman wrote: >=20 >> That proposal is the opposite of "defer", and also makes "0" special. = When the issue comes up in a separate document, the codes can be = assigned there. Application developers will understand "4 means no TLS" = as well as they would "0 means no TLS". >=20 > FWIW, and although I agree with Paul H that zero is not special, I do = like the esthetics if reserving zero. Sure, but Zack wasn't proposing "reserving", he was proposing "reserve = for this future use, at which point it would be allocated". Short-lived = aesthetics are not so interesting. --Paul Hoffman From i.grok@comcast.net Sat Dec 24 12:29:14 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0E621F8441 for ; Sat, 24 Dec 2011 12:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4nB-F1lzWtH for ; Sat, 24 Dec 2011 12:29:14 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id D9D3421F8440 for ; Sat, 24 Dec 2011 12:29:13 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta01.westchester.pa.mail.comcast.net with comcast id D8Jl1i0071vXlb8518VEFK; Sat, 24 Dec 2011 20:29:14 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta17.westchester.pa.mail.comcast.net with comcast id D8VE1i00800PQ6U3d8VEtP; Sat, 24 Dec 2011 20:29:14 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id pBOKTCeS007266 for ; Sat, 24 Dec 2011 15:29:12 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id pBOKTC6M007265 for dane@ietf.org; Sat, 24 Dec 2011 15:29:12 -0500 Date: Sat, 24 Dec 2011 15:29:12 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20111224202912.GA30478@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20111219160139.30815.77214.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <20111219160139.30815.77214.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-13.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 20:29:14 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 19, 2011 at 08:01:39AM -0800, internet-drafts@ietf.org wrote: > 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. >=20 > Title : Using Secure DNS to Associate Certificates with Domain= Names For TLS > Author(s) : Paul Hoffman > Jakob Schlyter > Filename : draft-ietf-dane-protocol-13.txt > Pages : 20 > Date : 2011-12-19 >=20 > TLS and DTLS use PKIX certificates for authenticating the server. > Users want their applications to verify that the certificate provided > by the TLS server is in fact associated with the domain name they > expect. TLSA provides bindings of keys to domains that are asserted > not by external entities, but by the entities that operate the DNS. > This document describes how to use secure DNS to associate the TLS > server's certificate with the intended domain name. This draft lost the fallback text explaining what to do when there are no usable certificate associations. --=20 Scott Schmit --pf9I7BMVVzbSWLtt Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTExMjI0MjAyOTEyWjAjBgkqhkiG9w0BCQQxFgQULrf315iQ gfz4LkCkZhTDmW9+im0weQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAyltfvxIb xvAsN3sGIONADa2cWhMrQlTHS+kl+XxfGqjeg5bS5BmVy1ZwI3Z4xb3x5gJolOOyYgiqKbcQ BxUeNZxlnY3S9XwwIgpqYiLw4xGMTsLyOkgG2SIabV3FmbIrJ91r5hvbylLL3ZLb316Wv2ZJ dsLIDdK+p3ICgtMAPTqz3W95mAPHISH+qdra3FUFNRfXstUR908rktuJKNrYfslcd4+618pn ZxjZRS0NQbCx9likIUCa/A4ZC8BellvG9l4maW6EIIO7m3raNhPKJzppZdMhZukYDjULOC8H 2oXj4NtXSW3z+xNl6V+38llUWllPON+9jsbzgI2QpQvm8Q== --pf9I7BMVVzbSWLtt-- From paul.hoffman@vpnc.org Sat Dec 24 16:17:39 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1BD21F848E for ; Sat, 24 Dec 2011 16:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODg1Jf6gQL5r for ; Sat, 24 Dec 2011 16:17:39 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 83EE321F8488 for ; Sat, 24 Dec 2011 16:17:39 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pBP0HW0t051578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 24 Dec 2011 17:17:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20111224202912.GA30478@odin.ulthar.us> Date: Sat, 24 Dec 2011 16:17:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <86307357-C322-4D90-86F2-862F4999B25C@vpnc.org> References: <20111219160139.30815.77214.idtracker@ietfa.amsl.com> <20111224202912.GA30478@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-13.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 00:17:40 -0000 On Dec 24, 2011, at 12:29 PM, Scott Schmit wrote: > This draft lost the fallback text explaining what to do when there > are no usable certificate associations. Quite true. We were simply following directions from the chairs. Would = anyone object if we add the following: If an =09 application receives zero usable certificate associations, it = =09 processes TLS in the normal fashion; otherwise, that application = =09 attempts to match each certificate association with the TLS server's = =09 end entity certificate. --Paul Hoffman From warren@kumari.net Mon Dec 26 10:54:04 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D378F21F8B84 for ; Mon, 26 Dec 2011 10:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.901 X-Spam-Level: X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMpGE4OgMbbJ for ; Mon, 26 Dec 2011 10:54:04 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 52A5C21F8B5C for ; Mon, 26 Dec 2011 10:54:03 -0800 (PST) Received: from [192.168.0.157] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E71621B4085D; Mon, 26 Dec 2011 13:54:01 -0500 (EST) References: <20111219160139.30815.77214.idtracker@ietfa.amsl.com> <20111224202912.GA30478@odin.ulthar.us> <86307357-C322-4D90-86F2-862F4999B25C@vpnc.org> In-Reply-To: <86307357-C322-4D90-86F2-862F4999B25C@vpnc.org> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9A405) From: Warren Kumari Date: Mon, 26 Dec 2011 13:54:00 -0500 To: Paul Hoffman Cc: "dane@ietf.org" Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-13.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 18:54:04 -0000 On Dec 24, 2011, at 7:17 PM, Paul Hoffman wrote: > On Dec 24, 2011, at 12:29 PM, Scott Schmit wrote: >=20 >> This draft lost the fallback text explaining what to do when there >> are no usable certificate associations. >=20 >=20 > Quite true. We were simply following directions from the chairs. Would any= one object if we add the following: > If an =20 > application receives zero usable certificate associations, it = =20 > processes TLS in the normal fashion; otherwise, that application = =20 > attempts to match each certificate association with the TLS server's = =20 > end entity certificate. >=20 > --Paul Hoffman >=20 No objections, LGTM++, etc. W > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From paul@cypherpunks.ca Mon Dec 26 17:04:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E734821F8C4F for ; Mon, 26 Dec 2011 17:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtZhhM6csNZL for ; Mon, 26 Dec 2011 17:04:52 -0800 (PST) Received: from letoams.cypherpunks.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 784EB21F8C28 for ; Mon, 26 Dec 2011 17:04:52 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id A3B5A8194C; Mon, 26 Dec 2011 18:09:54 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.5/8.14.5/Submit) with ESMTP id pBQN9pOj001495; Mon, 26 Dec 2011 18:09:51 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 26 Dec 2011 18:09:51 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Paul Hoffman In-Reply-To: <86307357-C322-4D90-86F2-862F4999B25C@vpnc.org> Message-ID: References: <20111219160139.30815.77214.idtracker@ietfa.amsl.com> <20111224202912.GA30478@odin.ulthar.us> <86307357-C322-4D90-86F2-862F4999B25C@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-13.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 01:04:53 -0000 On Sat, 24 Dec 2011, Paul Hoffman wrote: > Quite true. We were simply following directions from the chairs. Would anyone object if we add the following: > If an > application receives zero usable certificate associations, it > processes TLS in the normal fashion; otherwise, that application > attempts to match each certificate association with the TLS server's > end entity certificate. Would this behaviour be different depending on whether this non-existence was validated versus indeterminate? Paul From ietf@augustcellars.com Wed Dec 28 15:14:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9162B21F84CC for ; Wed, 28 Dec 2011 15:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-1.299, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDMApUYufHIE for ; Wed, 28 Dec 2011 15:14:12 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 784AB21F84C9 for ; Wed, 28 Dec 2011 15:14:12 -0800 (PST) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 017CA2C9F1; Wed, 28 Dec 2011 15:14:11 -0800 (PST) From: "Jim Schaad" To: "'Ondrej Mikle'" , References: <4EEE63EB.9020800@nic.cz> In-Reply-To: <4EEE63EB.9020800@nic.cz> Date: Wed, 28 Dec 2011 15:13:43 -0800 Message-ID: <00ca01ccc5b6$57d79e10$0786da30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEN/+1oJB+kzN84Sepf7JgEBX1cm5dvTJFg Content-Language: en-us Subject: Re: [dane] New "operational considerations" text (was: Addition to "Security considerations") X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 23:14:13 -0000 >From my point of view this text is far improved. Of course I still have some suggestions Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Ondrej Mikle > Sent: Sunday, December 18, 2011 2:07 PM > To: dane@ietf.org > Subject: [dane] New "operational considerations" text (was: Addition to > "Security considerations") > > I've written new non-normative version of text concerning association of > certificate usage 0 and 2. Hopefully I did not miss any important point from > the discussions so far. > > I tried to make text as clear as possible to DNS admins/operators who might > have no deep knowledge about minutiae in TLS clients' approaches when > building certificate chain. > > Use cases are outlined and administrator/operator is advised why they > happen, which choice is better for given situation. I hoped to the balance > between possibility of (yet unknown) future attacks and false positive rate > (clients denying association). > > Also see notes below the text with additional suggestions that could be > incorporated into the text. > > RFC technicalities: RFC 4949 deprecates term "CA certificate", though RFC > 5280 uses it. RFC 4949 suggests that is should be defined explicitly (as v3 > X.509 public-key certificate that has a "basicConstraints" extension containing > a "cA" > value of "TRUE"; possibly adding v1 certificates may be necessary). Given that we use the term CA certificate in other locations in the document, we should just define the term in a glossary and continue to use it. > > Formatting notes: **line** stands for subsection, [--line--] for internal > comment. > > > ---begin text--- > > When creating TLSA record with certificate usage type 0 or 2, care should be s/type 0 or 2/type 0 (CA Certificate) or type 2 (Trust Anchor)/ s/care should be taken/the implications need to be understood/ > taken when choosing between selector type 0 (full certificate) and 1 > (SubjectPublicKeyInfo). Careful choice is required due to algorithms in s/algorithms in/the different methods/ > various TLS clients employed to build client's trust-chain. We first outline s/client's trust-chain/trust-chains/ > cases to be aware of and then discuss implications on choice of selector type. > > Certificate usage 2 is unaffected if association is made to an end entity > certificate. s/*/Certificate usage 2 is not affected by the issue of chain building when the end entity certificate and the trust anchor certificate are the same./ > > **Ambiguities and corner cases of trust-chain building by TLS clients** > > TLS clients are known to implement methods that may cause any certificate > except end entity certificate in original certificate chain sent by server to be > exchanged or removed from the chain when client builds trust chain. TLS clients may implement their own chain building code rather than rely on the chain presented by the server. This means that, except for the end-entity certificate, any certificate presented in the suggested chain may or may not be present in the final chain built by the client. > > Certificates the client can use to replace certificates from original chain > include: > - client's trust anchors > - certificates cached locally > - certificates retrieved via URI listed in Authority Information Access X.509v3 > extension. > > CAs frequently reissue certificates with different validity period, hash in > signature algorithm or extensions (public key, issuer and subject remain > intact). Those are the certificates TLS client can use in place of original > certificate. s$reissue$issue/reissue$ s/hash in signature algorithm/signature algorithm (updated hash), CA key pair (cross-certificate)/ s/,issuer// s/original/an original/ > > Cases when clients are known to exchange or remove certificates that could > cause TLSA association by full certificate to fail are listed below: > > 1. client considers hash in signature algorithm of a certificate no longer > sufficiently secure 2. a cross-certificate issued to CA2 by CA1 is represented > by a self-signed root certificate of CA2 as a trust anchor in client's trust store > 3. a CA certificate above cross-certificate in original chain may be removed > from chain, because client found a trust anchor below said CA certificate Formatting - this should be represented as a list rather than a single sentence. It is hard to follow this way. 1. The client considers the signature algorithm of a certificate to no longer be sufficiently secure. This may be because of the hash algorithm or the signature key size. 2. I cannot follow this sentence 3. This seems to follow the case in #2 so I am not sure why it would be true. I would expect the case to be the opposite direction. > > **Discussion on choice of selector type** > > 1. Choosing selector type 0 > > "Full certificate" selector provides most precise specification of trust anchor. > Such non-ambiguity foils class of hypothetical future attacks on CA where CA > issues new certificate with identical SubjectPublicKeyInfo, but different > issuer, subject, extensions (which would allow redirect trust chain). This > selector would also foil bad practices or negligence of CA should CA use > identical key for unrelated CA certificates. Why does the first sentence talk about trust anchors, and then the rest of the paragraph basically talk about the case of CA certificates? It would not matter how the TA is specified in terms of preventing attacks on CAs in the chain below the TA. > > For DNS administrator, best course to avoid false-positive failures at client's > side when using this selector is: I don't understand what a false-positive failure would be. This needs to be defined. I think that a false-positive failure would be that the client accepts the certificate chain when as the administrator I don't think that they should reject. A false-negative would be when the client rejects a chain that as the administrator I think that they should accept. Under this I think you are talking about false-negatives - that is the client should accept the chain because I gave a valid one and they mucked it up. > - don't associate to CA certificates having signature algorithm with hash that > is considered weak if CA issued a replacement certificate > - check how common client programs process the TLSA association on fresh > client installations - local certificate cache needs to be empty. > > 2. Choosing selector type 1 > > SPKI selector gives greater flexibility in avoiding share of false-positive > failures caused by trust-chain-building algorithms used in clients. > > One specific use-case should be noted: creating TLSA association to > certificate > I1 that directly signed end entity certificate S1 of server. Since the key used > to sign S1 is fixed, association to I1 must succeed - if client swaps I1 for other > certificate I2, its SPKI must match SPKI of I1. Such association would not > suffer from false-positive failure on client's side should the client use a > reissued CA certificate I2 in place of I1. > > The attack surface is a bit broader compared to "full certificate" selector: > - administrator must know or trust the CA not to engage in bad practices (not > sharing key of I1 for unrelated CA certs leading to trust-chain redirect) > - administrator should understand whether some X.509v3 extension may > adversely affect security of the association. If possible, administrator should > overview CA certificates sharing the SPKI. > > Using SPKI selector for association with a certificate in chain above I1 is to be > decided on by-case basis. There are too many possibilities depending on > issuing CA. Unless full implications of such association are understood by > administrator, using selector type 0 might be better option security-wise. > > [--following paragraph might need update--] In practice, sharing keys in > differently-purposed CA certificates is rare, nevertheless not non-existent. > Attack on association by SPKI would require either gross negligence on CA's > part or an attacker gaining control of CA. > > ---end text--- > > > Some additions that could be made to the above text that I am not sure > whether they are suitable/allowed for RFC text: > > I'd like to mention Valicert as a great example of CA issuing cross-certificates > (Valicert certificates are present in cert chains sent by at least 400000 hosts). I > believe such example would be much more understandable to > administrators (target audience) than RFC 4949 definitions. Are they doing it without the "permission" of certificate holder? > > Preceding discussions raised point that cross-certificate cannot be identified > from its fields alone. Best document I've found so far identifying CAs issuing > cross-certificates is the CA graph done by EFF (I mean primarily the textual > discrete graph graphviz source - nodes being CAs and edges showing > certifications). Otherwise cross-signing CAs may be found only by reading > CPS. > > On a similar note, listing MD2 and MD5 as "hash algorithms considered weak > at the time of writing" would be clearer, too (again not sure whether allowed > in RFC). On could easily reference RFC 6331 (MD5), RFC 6149 (MD2) . I have not seen one for SHA1 yet or it has gone stale. > > Ad last paragraph "needing update": I've dug a bit into collected CA > certificate data to see if CA certificate pairs sharing same public key might > belong to different entities. One sample pair found shows key sharing > between UK CA and US RA for different products (having different > guarantees). This might also be a good reason for suggesting TLSA > associations are to be made to certificates lower in the chain (for both > selector types). > > > Ondrej Mikle > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane