From wouter@nlnetlabs.nl Thu Mar 1 01:36:50 2012 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 9E41521F852C for ; Thu, 1 Mar 2012 01:36:50 -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 Y2kl4oWBnpAh for ; Thu, 1 Mar 2012 01:36:49 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB2121F852A for ; Thu, 1 Mar 2012 01:36:49 -0800 (PST) Received: from axiom.nlnetlabs.nl (axiom.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4d46]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q219akAq046985 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 1 Mar 2012 10:36:47 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1330594608; bh=Qd57uZZIqbt7Y/CniOrrKMxt4L6Kyx2dNQR1J9Xvh7Q=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=g6c/MUP1yjKVFFbwJdEB1790CZalomkrzcP6xY9IqyMS3hfp4orzQdfvnG0apiz3r XbO/z22SjZTvzX59Pu4CK8h0VLw3kxu0lKH9d8uOSY/nbsk2feiqvMyd2ad4Xkkcwl +iMT7lCXWfVZ4AFd2ZBT+C6Ki9JWA4biE1j7Jg3A= Message-ID: <4F4F432E.4010304@nlnetlabs.nl> Date: Thu, 01 Mar 2012 10:36:46 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <201202292322.q1TNMIWD028275@new.toad.com> In-Reply-To: <201202292322.q1TNMIWD028275@new.toad.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 01 Mar 2012 10:36:47 +0100 (CET) Subject: Re: [dane] Draft -17 comments 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 Mar 2012 09:36:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dane-ists, On 03/01/2012 12:22 AM, John Gilmore wrote: > Thank you, editors! -17 is a big improvement, editorially, over > -16. Most of my comments are small nits, though there's one > 2-paragraph insertion that I think is worthwhile. I would like to add a single line after section 4. It now has this: If an application receives zero usable certificate associations, it processes TLS in the normal fashion without any input from the TLSA records. If an application receives one or more usable certificate associations, it attempts to match each certificate association with the TLS server's end entity certificate until a successful match is found. I want to add: If there is no match, then the TLS connection is aborted. Or (alternative, has keyword, I do not mind which one is taken) If none match, the application MUST abort the TLS connection. This matches the algorithm in the appendix, and the behaviour if the TLSA DNSSEC fails. Because the 'else' from the 'if one or more usable certificates, attempt to match' is not specified in the normative text. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPT0MuAAoJEJ9vHC1+BF+NbocP/jrmZsKM3SswsX2Qxt54uOBy gIlQGEDvcbpB57ItiF1VeIVB1XGieEdCaPSNFfei/VkpuqDBggVK2YWS5p+WwvIh 2PTvBKW8Lx5Ij8aqlHCTLnjKsthgZERzU8Euh5fKprMvCcUypUtCmk+AW7Wx+/N4 uZlvfI5auZE9qUbuTQseDYQtnJJ+Adv904c0rZ7I/3B8Nn/YrRovhNENv94u3j0y nMuTdwb7DFlQ1npb6ziW9Iuj96btHECJtxtRtkuq8vhAlMu+EKsgWkH05i4aqOeN tFkM4/d7CfiKO1ToMKLokUgHSQ/g16nawWlhuI0/V3rIXSu8pr08T4NCIq7yGoC+ PeJQ0D5VPgUgeD7yX0nC/2ZA6TcmzPMunNI92CLwmWY0OLr7szfDEPeaPJmeywGB mkDUwyEmz7RlplF4qy9ntteUtCusG9C8vv/BkRP7i2dpcPXMLhVogiOx9JIXdEO2 RitXdPUHoy/MoeWJiH1Bbsv++9Y+RBIg3ck4gpcI1nruF+QXq8FNWCeBWd//jp29 CKV1ZrO4o3lgWFRynguiyGrVI6oNtSmboTe6r+kDr91agmIJbrMkpz11yFn6PYPC arUahGRTSDQ3IgwMFQ/0K7gLRFbP1TU2WuDwayJ1B19sIJ7re2KrPqbvItInAuFX Xcbfjm3PLByp8wLTGQpl =o0Fs -----END PGP SIGNATURE----- From paul.hoffman@vpnc.org Thu Mar 1 07:26:35 2012 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 9128F21E81D4 for ; Thu, 1 Mar 2012 07:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.67 X-Spam-Level: X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 Ee1SrzlOWCkp for ; Thu, 1 Mar 2012 07:26:35 -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 0D74E21E8163 for ; Thu, 1 Mar 2012 07:26:35 -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.5/8.14.3) with ESMTP id q21FQXOR005677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 1 Mar 2012 08:26:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F4F432E.4010304@nlnetlabs.nl> Date: Thu, 1 Mar 2012 07:26:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201202292322.q1TNMIWD028275@new.toad.com> <4F4F432E.4010304@nlnetlabs.nl> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] Draft -17 comments 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 Mar 2012 15:26:35 -0000 On Mar 1, 2012, at 1:36 AM, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi Dane-ists, >=20 > On 03/01/2012 12:22 AM, John Gilmore wrote: >> Thank you, editors! -17 is a big improvement, editorially, over >> -16. Most of my comments are small nits, though there's one >> 2-paragraph insertion that I think is worthwhile. >=20 > I would like to add a single line after section 4. >=20 > It now has this: > If an application receives zero usable certificate associations, it > processes TLS in the normal fashion without any input from the TLSA > records. If an application receives one or more usable certificate > associations, it attempts to match each certificate association with > the TLS server's end entity certificate until a successful match is > found. >=20 > I want to add: > If there is no match, then the TLS connection is aborted. > Or (alternative, has keyword, I do not mind which one is taken) > If none match, the application MUST abort the TLS = connection. >=20 > This matches the algorithm in the appendix, and the behaviour if the > TLSA DNSSEC fails. Because the 'else' from the 'if one or more usable > certificates, attempt to match' is not specified in the normative = text. This works for me and matches my mental model of what the WG intended. = Another way to say it would be "If no match is found, the TLS client = MUST abort the TLS connection just as if, in the non-TLSA environment, = the client could not validate the server's certificate". --Paul Hoffman From warren@kumari.net Thu Mar 1 09:12:27 2012 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 E89CF21F8B1B for ; Thu, 1 Mar 2012 09:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.163 X-Spam-Level: X-Spam-Status: No, score=-107.163 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_14=0.6, 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 ZiyTVTAank9b for ; Thu, 1 Mar 2012 09:12:26 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 2089E21F8B08 for ; Thu, 1 Mar 2012 09:12:25 -0800 (PST) Received: from dhcp-172-19-119-93.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id BCE321B4003C; Thu, 1 Mar 2012 12:12:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Thu, 1 Mar 2012 12:12:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8804EE34-25F2-4A9A-9412-7761CF6EEDE6@kumari.net> References: To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Draft -17 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 Mar 2012 17:12:27 -0000 [ Please note that I have sent this without my consulting my co-chair = (as he is off-line at the moment, it being night time there) -- anything = stupid below is entirely my fault. I am explicitly CCing our AD so he = can also provide a smackdown if needed.]=20 Dear WG, This working group has been a great learning opportunity for Ondrej and = myself -- both of us came into this as basically virgin chairs (I = cochair OpSec, but to be honest it has received very little of my = attention, way less than it deserves) and appreciate the groups = understanding as we have learnt. I know that I for one have made some = mistakes, and have often let discussions get way off topic, have not = communicated as clearly as I could have. I appreciate all of y'alls = understanding and assistance over the many (long!) months... The IETF in theory runs on rough consensus, running code (and large = cookies) -- in actual fact it runs on the goodwill of the WG = participants, coming together and being willing to consider each other's = positions and compromise on something that we can all live with. Some of = the topics here have been things that participants are very passionate = about (and so we have had some incidents where that passion has bubbled = over) and in general I have been very pleased with the WG's willingness = to listen to other's views and compromise on a stronger solution. I believe that we have rough consensus on this document and feel that we = are now getting down into the weeds of wordsmithing -- we opened the = major points in the Issues tracker, discussed and arrived at some sort = of consensus, and our authors have incorporated (what the chairs judged = to be) WG consensus. A number of issues were brought up during WGLC and = discussed, and (very quickly) incorporated by the authors. So, I am making one final request of the WG on this document -- we don't = need to achieve (and never will) a state where everyone is perfectly = happy, but please let me know if you are wildly unhappy with the = document (and by "wildly unhappy" I mean "I'm ready to stab you, the = process was horribly mismanaged and I've already written my appeal = letter."). Obviously, what would be even better would be a simple "I'm OK with this = document" / "Yeah, I can live with this..."=20 Again, we are not trying to get to a point where every word is perfect = for everybody (nor reopening WGLC), rather a state that we can live = with. W On Feb 29, 2012, at 10:50 AM, Paul Hoffman wrote: > Greetings again. As you can see, we turned in -17 with what we think = are all the changes asked for by the WG chairs. Please review the = changes at = , and = let the list and chairs know if you think we missed anything that the = chairs asked us to do. >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From owens@nysernet.org Thu Mar 1 09:51:30 2012 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 A3B8A21E80C8 for ; Thu, 1 Mar 2012 09:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.184 X-Spam-Level: X-Spam-Status: No, score=-3.184 tagged_above=-999 required=5 tests=[AWL=1.416, BAYES_00=-2.599, GB_I_LETTER=-2, 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 ZdtGE4oEeEOu for ; Thu, 1 Mar 2012 09:51:30 -0800 (PST) Received: from cookiemonster.nysernet.org (cookiemonster.nysernet.org [IPv6:2620:f:1:1201:21b:63ff:fea4:4d92]) by ietfa.amsl.com (Postfix) with ESMTP id EE9C021E80BF for ; Thu, 1 Mar 2012 09:51:29 -0800 (PST) Received: by cookiemonster.nysernet.org (Postfix, from userid 501) id F1F1BB26750; Thu, 1 Mar 2012 12:51:27 -0500 (EST) Date: Thu, 1 Mar 2012 12:51:27 -0500 From: Bill Owens To: Warren Kumari Message-ID: <20120301175127.GD53552@nysernet.org> References: <8804EE34-25F2-4A9A-9412-7761CF6EEDE6@kumari.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8804EE34-25F2-4A9A-9412-7761CF6EEDE6@kumari.net> User-Agent: Mutt/1.4.2.3i Cc: IETF DANE WG list Subject: Re: [dane] Draft -17 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: owens@nysernet.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 17:51:30 -0000 On Thu, Mar 01, 2012 at 12:12:23PM -0500, Warren Kumari wrote: > So, I am making one final request of the WG on this document -- we don't need to achieve (and never will) a state where everyone is perfectly happy, but please let me know if you are wildly unhappy with the document (and by "wildly unhappy" I mean "I'm ready to stab you, the process was horribly mismanaged and I've already written my appeal letter."). > > Obviously, what would be even better would be a simple "I'm OK with this document" / "Yeah, I can live with this..." > Again, we are not trying to get to a point where every word is perfect for everybody (nor reopening WGLC), rather a state that we can live with. I've sent a note directly to the authors with very minor typo corrections; I am happy with this document. Bill. From ondrej.mikle@nic.cz Thu Mar 1 16:25:04 2012 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 E703621E830F for ; Thu, 1 Mar 2012 16:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] 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 w+x1RwVBBaoO for ; Thu, 1 Mar 2012 16:24:50 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CABEF21E81B2 for ; Thu, 1 Mar 2012 16:24:49 -0800 (PST) Received: from [10.0.0.17] (213.230.broadband9.iol.cz [90.176.230.213]) by mail.nic.cz (Postfix) with ESMTPSA id 095372A2E2C for ; Fri, 2 Mar 2012 01:24:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330647888; bh=5pAJh21c/l8RVR5gZrP3GcOCZ8qz5qFOT12EMWnaOeM=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ezcKo9Lo05q/N6r23QdN7UjVvK3fiz50QdnEdoZMCS0pLCpRnbA3xBZoS8eP6MEsC 7wz+Da110Xf0RYuTO6yiU/m4W/HbjqZOLHATevOvZMp7O6+jaFFpRx3AUEo09PVwkb EODCGvNG/gw0nq29BsqfZFKKWPky0gMwu3gNZGUw= Message-ID: <4F50134F.5060100@nic.cz> Date: Fri, 02 Mar 2012 01:24:47 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dane@ietf.org References: <8804EE34-25F2-4A9A-9412-7761CF6EEDE6@kumari.net> In-Reply-To: <8804EE34-25F2-4A9A-9412-7761CF6EEDE6@kumari.net> X-Enigmail-Version: 1.3.5 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] Draft -17 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 Mar 2012 00:25:05 -0000 Hello WG, On 03/01/2012 06:12 PM, Warren Kumari wrote: > I believe that we have rough consensus on this document and feel that we are now getting down into the weeds of wordsmithing -- we opened the major points in the Issues tracker, discussed and arrived at some sort of consensus, and our authors have incorporated (what the chairs judged to be) WG consensus. A number of issues were brought up during WGLC and discussed, and (very quickly) incorporated by the authors. > > So, I am making one final request of the WG on this document -- we don't need to achieve (and never will) a state where everyone is perfectly happy, but please let me know if you are wildly unhappy with the document (and by "wildly unhappy" I mean "I'm ready to stab you, the process was horribly mismanaged and I've already written my appeal letter."). In my opinion the current consensus on the draft is fine. John Gilmore raised the following issue: > In section A.1.2.2: >> One specific use-case should be noted: creating a TLSA association to >> certificate I1 that directly signed end entity certificate S1 of the >> server. Since the key used to sign S1 is fixed, association to I1 >> must succeed: if a client swaps I1 for I2 (a different certificate), >> its SPKI must match SPKI of I1. Such and association would not >> suffer from a false-negative failure on client's side if the client >> uses a reissued CA certificate I2 in place of I1. > A few issues here. This is very dense and hard to understand; it took > me a few readings. Second, we use "SPKI" without defining it (the > previous graf says SubjectPublicKeyInfo and is where we could hang a > "(SPKI)"). Third, "Such and association" should be "Such an > association". Admittedly, it's not easy to understand. I can rewrite that, for example adding ASCII graphs of those two cases. (I think adding those discrete graphs would be much clearer compared to the wording.) I can also add use cases for the new usage type 3 (not existent at the time of writing of A.1 section). I could write the mentioned update in the upcoming week (March 5-9th). Conclusion: unless someone says such update is superfluous in the following week, I'll write it. Ondrej From ietf@augustcellars.com Sun Mar 4 15:20:50 2012 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 9EDE721F8534 for ; Sun, 4 Mar 2012 15:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.373, 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 DskmXh3VGnJr for ; Sun, 4 Mar 2012 15:20:49 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 97B4B21F8533 for ; Sun, 4 Mar 2012 15:20:49 -0800 (PST) Received: from Tobias (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 15E8F38EF5; Sun, 4 Mar 2012 15:20:49 -0800 (PST) From: "Jim Schaad" To: References: <20120229154724.18071.36972.idtracker@ietfa.amsl.com> In-Reply-To: <20120229154724.18071.36972.idtracker@ietfa.amsl.com> Date: Sun, 4 Mar 2012 15:20:03 -0800 Message-ID: <003c01ccfa5d$548ad930$fda08b90$@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: AQJ6dF6NY30juHEJb9CtgErkH0ncwpT+rsKg Content-Language: en-us Cc: Paul Hoffman Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-17.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, 04 Mar 2012 23:20:50 -0000 Here are some comments on this draft and some comments on the -16 version that I could never get the mailing list to accept. 1. In section 1.1. paragraph 3: "TLS uses certificates to protect keys." TLS uses certificates to bind names to keys, it does nothing about protecting the secret portion of the key discussed in the previous paragraph. I suggest chaining the text to state "TLS uses certificates to bind keys and names." Or possibly just remove the sentence entirely. 2. In section 2.1.1 - item usage 2 -- nit - s/must be used as a trust anchor/must be used as the trust anchor/ The certificate is not added to the set of trust anchors, it is the set of trust anchors. This means that a specific rather than a general indicator should be used. 3. In section 2.1.1 - I do not find the details for usage #3 to be clear. I believe from what I saw on the mailing this that what is being said is that the certificate must match the end entity certificate and that certificate is the trust anchor certificate and is therefore implicitly trusted. The current text does not make that clear to me. I find it difficult to understand the difference between usage 1 and usage 3 based strictly on the text given. Additionally I have a problem with implying that this usage is the "domain-issued certificate", I thought that the same term was used in case 2 where the CA is strictly inside of the domain and the CA issued certificates. I have just re-read the text in RFC 6394 and don't see any way from it to distinguish between the trust-anchor and domain-issued certificate cases. There is definitely nothing that states that domain-issued certificates would be a self-signed certificate rather than one that is placed in a hierarchy. 4. In section 4 - the text is If a host is using TLSA usage type 2 for its certifcate, the corresponding TLS server SHOULD send the certificate that is referenced just like it currently sends intermediate certificates. I find this text slightly confusing. From the previous mailing list traffic, I thought in this case there was an effective one certificate path and therefore no intermediate certificates would exist. I believe you mean to say that it should be sent just like the EE certificate is. s/certifcate/certificate/ 5. In section 5 - "No Downgrade" - The last clause in the paragraph does not agree with the text in section 4 - I would request that the last clause be changed to "TLS will not successfully connect." or "TLS will fail the connection." The text implies no attempt, rather than being aborted after the attempt has started. - I will agree that this is kind of a nit. 6. - Very weak suggestion - you might consider using RFC 6234 as the SHA2 reference rather than the NIST document. 7. In section 7.1 - I find the text in paragraph #2 to be a non-sequitur. I think that this text is general and applies to all of the following sections. As such it more properly belongs in section 7 rather than in section 7.1. If I were to skip reading section 7.1 because I know the RRtype I would miss the RFC required requirement. Potentially the text could be removed as the policy is listed individually for each section; this is just a rationalization text that makes no sense where it is located. 8. In section 8 - The following text is included Client treatment of any information included in the certificate 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. Which domain name administrator are we talking about here? The client's or the server's administrator? 9. In section 8 - I believe that the following text is missing: The client acceptance of an arbitrary certificate retrieved from a TLSA record with a usage type of 2 or 3 as fully trusted may be a matter of local policy. While such trust is limited to the specific domain for which the TLSA query has been made, local policy may deny the trust or further restrict the conditions under which that trust is permitted. 10. In section A.1 - does the last paragraph still apply given that we have added usage 3? Are we still suggesting that usage 2 be used for a single certificate chain or that people should use usage 3? 11. Section A.1.2 - Suggested replacement text In this section, a "false-negative failure" means that a client cannot build a certificate chain that validates with the TLSA data provided by the DNS administrator when a legal chain does exist. A "false-positive failure" means that the client successfully builds a certificate chain that validates with the TLSA data provided and for which the DNS administrator intended that the validation fails. As the text currently stands, I believe that a false-negative not be true if a chain was built that did not use the certificate in the TLSA data. I also wonder if the false-negative case is supposed to apply for the cases that a TLSA data record is marked as unusable for any reason and would thus include the case of DNSSEC indeterminate? 12. Section A.1.3-I suggest adding the following new bullet o The administrator should understand that any CA could, in the future, issue a certificate that contains the same SubjectPublicKeyInfo and therefore new chains can crop up in the future without any warning. From ondrej.mikle@nic.cz Mon Mar 5 08:09:47 2012 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 ECB5221F846A for ; Mon, 5 Mar 2012 08:09:46 -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 tgraIoA5QnWK for ; Mon, 5 Mar 2012 08:09: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 B8D8621F850F for ; Mon, 5 Mar 2012 08:09:40 -0800 (PST) Received: from localhost.localdomain (ip-94-113-3-132.net.upcbroadband.cz [94.113.3.132]) by mail.nic.cz (Postfix) with ESMTPSA id 08CF62A2F3E for ; Mon, 5 Mar 2012 17:09:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330963780; bh=ikjTMaZ3U7n66w0Yv79ohAhgCLkJr5WMc2IX1S+NKBg=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=mfFTPySa+a+GOvxHRXscVh5+2sEE32LcNW/NO81h0Vve6BGOfaac/QvGfJU4tQ/dp yiX2lEqaJIrpux8+vCmX2SZVBolI6sLMFZqfn+EIS68FJve5pa32nKvg/tQSMO7lmt rSBLCb+tnwvkB3fPAPWGcbwgU331C1ein/mzBgiw= Message-ID: <4F54E543.5060207@nic.cz> Date: Mon, 05 Mar 2012 17:09:39 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dane@ietf.org References: <201202292322.q1TNMIWD028275@new.toad.com> In-Reply-To: <201202292322.q1TNMIWD028275@new.toad.com> X-Enigmail-Version: 1.3.5 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] Draft -17 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 16:09:47 -0000 On 03/01/2012 12:22 AM, John Gilmore wrote: > > In section A.1: [snip] > > We do have a section later about this (A.1.2), but it seems to me > that the much bigger question for TLS server operators is which > certificate usage type to use, and which certificate it should identify. > Whether it matches the whole cert, or just the public key; and whether it > hashes, or provides the whole thing, are secondary to that initial > choice that we don't even discuss. A rough guide that should cover most cases (I'm numbering it A.1.4 since Jim Schaad proposed additional subsection A.1.3). It's by no means perfect given how many cases are there, but I think it's not misleading (much). -- A.1.4 Transitioning to DANE-based system from current CA-based system This is a rough guide covering selection of certificate usage for server operators depending on how certificates were deployed on existing server's TLS services. It is by no means exhaustive but should point at the right direction for the majority of common cases. Server operators may have different preferences or policies that won't be covered here due to large amount of possible combinations. o Does TLS service use a well-known trusted CA-issued certificate? o If yes, then: o Does the service use single or at most two certificates? o choose certificate usage 1 (Service certificate constraint) o Otherwise (for cloud or CDN with many end-entity certificates): o choose certificate usage 0 (CA constraint) o If no, then: o Does service use self-signed certificate? o choose certificate usage 3 (Domain-issued certificate) o Otherwise the case is that service certificate is issued by a custom CA or a not-well-known CA o choose certificate usage 2 (Trust anchor assertion) It should be noted that the line between associating to a CA certificate or end-entity certificate is not an absolute. Therefore the above guide should be treated as informative. Associating with end-entity certificate (certificate usages 1 and 3) provides strictest assertion and is not affected by validation path building mechanisms at TLS clients' side. However associating with end-entity certificate might not be always possible (e.g. cloud service with hundreds of end-entity certificates) or desired for operational reasons (e.g. frequently exchanged end-entity certificate). -- > >> Certificate usage 2 is not affected by the different types of chain >> building when the end entity certificate is the same as the trust >> anchor certificate. > > Here's a clearer way to say it, which also points out that usage 3 is > also immune from the troubles discussed: "Certificate usages 2 and 3 > are not affected by the different types of chain building, if the end > entity certificate provided by the TLS server is the same as the > certificate identified by (or provided in) the TLSA record." At the time certificate usage 3 was not yet created. I propose following formulation in the place of the "Certificate usage 2..." sentence: "Association with end-entity certificate is immune from unpredictability in TLS clients' validation path building algorithms. That means there are only two cases affected: certificate usage 0 and certificate usage 2 if association is made to a CA certificate." > > In section A.1.2.2: >> One specific use-case should be noted: creating a TLSA association to >> certificate I1 that directly signed end entity certificate S1 of the >> server. Since the key used to sign S1 is fixed, association to I1 >> must succeed: if a client swaps I1 for I2 (a different certificate), >> its SPKI must match SPKI of I1. Such and association would not >> suffer from a false-negative failure on client's side if the client >> uses a reissued CA certificate I2 in place of I1. > > A few issues here. This is very dense and hard to understand; it took > me a few readings. Second, we use "SPKI" without defining it (the > previous graf says SubjectPublicKeyInfo and is where we could hang a > "(SPKI)"). Third, "Such and association" should be "Such an > association". An attempt to make the S1/I1/I2 case more readable (a replacement for the paragraph "One specific use-case should be noted [...] uses a reissued CA certificate I2 in place of I1."): -- One specific use-case should be noted: creating a TLSA association to CA certificate I1 that directly signed end entity certificate S1 of the server. The case can be illustrated by following graph: +----+ +----+ | I1 | | I2 | +----+ +----+ | | v v +----+ +----+ | S1 | | S1 | +----+ +----+ certificate chain sent by a different validation path server in TLS handshake built by TLS client I2 is a reissued version of CA certificate I1 (e.g. having different hash in signature algorithm). In the above scenario, both certificates I1 and I2 that sign S1 must have identical SubjectPublicKeyInfo, because the key used to sign S1 is fixed. An association to SubjectPublicKeyInfo (selector type 1) will always succeed in such case whereas association with full certificate (selector type 0) might miss due to false-negative failure. -- Ondrej From pieter.lexis@os3.nl Wed Mar 7 02:43:55 2012 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 C3E1A21F86DE for ; Wed, 7 Mar 2012 02:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnBCOwtlXstn for ; Wed, 7 Mar 2012 02:43:55 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id D668E21F86E0 for ; Wed, 7 Mar 2012 02:43:54 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 66D6E17AA25 for ; Wed, 7 Mar 2012 11:43:47 +0100 (CET) Received: from [IPv6:2001:610:158:1020:224:beff:fe39:69b9] (unknown [IPv6:2001:610:158:1020:224:beff:fe39:69b9]) by smtp.os3.nl (Postfix) with ESMTPSA id 1A5B317AA24 for ; Wed, 7 Mar 2012 11:43:47 +0100 (CET) Message-ID: <4F573BE2.7090106@os3.nl> Date: Wed, 07 Mar 2012 11:43:46 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dane@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [dane] Draft -17 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 Mar 2012 10:43:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, On 02/29/2012 04:50 PM, Paul Hoffman wrote: > Greetings again. As you can see, we turned in -17 with what we > think are all the changes asked for by the WG chairs. Please review > the changes at > , > and let the list and chairs know if you think we missed anything > that the chairs asked us to do. I read the latest draft last weekend and I have a few minor issues with it: - ----- First off, the title (in the title bar) of the PDF version don't display the brackets around (DANE) and (TLS). These show up as †DANE‡ and †TLS‡. Could be something with the tools used, don't worry too much about it. - ----- Second, the title on the top of every page says "DNS-Based Auth for TLS". This seems sloppy, could this be changed to "DNS-Based Authentication for TLS"? - ----- Page 6, section 1.3: This document defines a secure method to associate the certificate that is obtained from the TLS server with a domain name using DNS; To be honest, it doesn't define a 'secure method' to do this. It defines a method that uses secure techniques (like DNSSEC) to accomplish its goal (semantics, schantics). - ----- Page 7, section 2.1.1: ...This usage is sometimes referred to as "CA constraint" because it limits which CA can be used to issue certificates for a given host name, port, and protocol. ... I think this come from merging the old section 4 into this one. At this point in the document, no examples of TLSA records have been given. So it would make sense to rephrase this to a more common: ...This usage is sometimes referred to as "CA constraint" because it limits which CA can be used to issue certificates for a service on a host ... And clarify this to be the (port, protocol, hostname) tuple in the later sections (which is done). - ----- Page 9, section 2.1.4: ...The data refers to the certificate in the association, not to the TLS ASN.1 Certificate object. This sentence suddenly talks about an ASN.1 Certificate object. Someone not totally familiar with TLS and X.509 will have a hard time understanding this sentence. I also believe that this sentence isn't needed as it is correctly described in the sentences before it. Perhaps a mention about the certificate data being in DER format should be placed here. - ----- Page 11, section 4: 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, MUST cause the connection to be aborted. The first sentence is a bit superfluous, maybe change this to: o If the DNSSEC validation state of the TLSA RRset is bogus, .... - ----- Page 29, Appendix C: The following are examples of self-signed certificates that have been been generated with various selectors and matching types. They were generated with one piece of software, and validated by an individual using other tools. Is a bit lacking in formation, perhaps something like the following will make it better: The following examples are created from a single self-signed certificate to show the differences between the various selectors and matching types. These examples have been created and verified using different tools. - ----- Appendix B: As an addition to Appendix B, I have created a better pseudo code for the creation of the Certificate Association Data field. // Helper functions select(S, C) { if (S==0) { return as_DER(C) } if (S==1){ return as_DER(C.SubjectPublicKeyInfo) } } hash(M,D) { if (M==0) { return D } if (M==1) { return SHA256(D) } if (M==2) { return SHA512(D) } } // Main function create_assoc_data(Certificate, Selector, MatchingType) { return hash(MatchingType, select(Selector, Certificate)) exit } - ----- Feel free to ignore/comment on/bury any of these suggestions. Regards, Pieter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPVzvfAAoJELPqGO5ebd4jBw4QAIULqHd7+aVUbHrmBoZgTY5x BuCppWsr7krL6av630kdfbIZ+YGnDxj6MO8FlQ+Rb4W6BIGTdIbFx8YWYJHnzKZr qcZgsaYfaks/o4eU+S9x+Mb7HlnZOUTEixkZrOg6pJsjGDo9kuFJgsa32D607x4l 5qPbnwnIvY7wRaejrQiVEe5FG3WpqFNkpTJlYgnV17rmaHBHwLgV2RVZqfJAMe05 911jGh3XY1RTcy62kr8JM2DywxZP75cy9IMK3aVEHPa5G4yeTOy609nzxD5nmPv2 Ix2+sA89ZorwDkc9cw1hjLGetjStOdGnvAKBe/7ar6LslK+eo/WcPGMhWe2UWVHY lOAUK7Y41GwBlwAAqmo1f3nhVAhlslUU8ToU9nzDUyKHE1qk/tvFEIHI2cOBBAN2 17coxgcL16sWGU9yTau4zcK7uBLaOEQWq1vOojA+7DwB03ZDPf7Pz3DeFTzx5AJg uyeWkvu/5MwyK9eTI9xGcNnnAv1kUTQQ8wsMmqparamcHyt2J+rHwHvfNnusUfFW 1zoGStMt1OCV6fykDoMpzZ7bgCsCe6V8MgceTVUAri/WiQYYtV/pWs4Uut2M6jdK DsrWDqGTEr4RWkyfj1e8IZn6I4BKyBLfG8UDxFfygJchJEn97fQb33OkpXKV3mvs jgiNmOTrwgMqqPlJtI2i =CWaB -----END PGP SIGNATURE----- From ondrej.sury@nic.cz Wed Mar 7 04:26:21 2012 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 48CFA21F87AA for ; Wed, 7 Mar 2012 04:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_61=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01XdJbzedc+2 for ; Wed, 7 Mar 2012 04:26:20 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D2DBF21F872B for ; Wed, 7 Mar 2012 04:26:14 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:3cfb:69e7:ff98:9d4b] (unknown [IPv6:2001:1488:ac14:1400:3cfb:69e7:ff98:9d4b]) by mail.nic.cz (Postfix) with ESMTPSA id DF01F2A2E7C; Wed, 7 Mar 2012 13:26:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331123171; bh=MeXHCeFpfVVPPJHbOnm3WrEYZHe8mDZq7e1RwPzZVuo=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cAiqmZ3wLLzPHUs3hzelIkozHOyrhEhTl1CCbHFEbhBdlxZAZWAgywLEguSgph0up GObeQ6Ldp0AP4ZOh3q7JWhjlwjs2NqnGQhkbivp4cY2yeCIvAEih/HhffWW3WszkET 3Jyqc6fBA6kYUk7xbQzQj/yTRrPG4h6ibLjnfvsg= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4F573BE2.7090106@os3.nl> Date: Wed, 7 Mar 2012 13:26:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F573BE2.7090106@os3.nl> To: Pieter Lexis X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Draft -17 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 Mar 2012 12:26:21 -0000 On 7. 3. 2012, at 11:43, Pieter Lexis wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi all, >=20 > On 02/29/2012 04:50 PM, Paul Hoffman wrote: >> Greetings again. As you can see, we turned in -17 with what we >> think are all the changes asked for by the WG chairs. Please review >> the changes at=20 >> , >> and let the list and chairs know if you think we missed anything >> that the chairs asked us to do. >=20 > I read the latest draft last weekend and I have a few minor issues > with it: >=20 > - ----- >=20 > First off, the title (in the title bar) of the PDF version don't > display the brackets around (DANE) and (TLS). These show up as = =E2=80=A0DANE=E2=80=A1 > and =E2=80=A0TLS=E2=80=A1. Could be something with the tools used, = don't worry too > much about it. >=20 > - ----- >=20 > Second, the title on the top of every page says "DNS-Based Auth for > TLS". This seems sloppy, could this be changed to "DNS-Based > Authentication for TLS"? >=20 > - ----- >=20 > Page 6, section 1.3: > This document defines a secure method to associate the certificate > that is obtained from the TLS server with a domain name using DNS; >=20 > To be honest, it doesn't define a 'secure method' to do this. It > defines a method that uses secure techniques (like DNSSEC) to > accomplish its goal (semantics, schantics). I am fine with 'secure method' in the Introduction section. (I am also find with just 'method'.) > - ----- >=20 > Page 7, section 2.1.1: > ...This usage is sometimes referred to as "CA constraint" because it > limits which CA can be used to issue certificates for a given host > name, port, and protocol. ... >=20 > I think this come from merging the old section 4 into this one. At > this point in the document, no examples of TLSA records have been > given. So it would make sense to rephrase this to a more common: >=20 > ...This usage is sometimes referred to as "CA constraint" because it > limits which CA can be used to issue certificates for a service on a > host ... >=20 > And clarify this to be the (port, protocol, hostname) tuple in the > later sections (which is done). Fine with this nit. > - ----- >=20 > Page 9, section 2.1.4: > ...The data refers to the certificate in the association, not to the > TLS ASN.1 Certificate object. >=20 > This sentence suddenly talks about an ASN.1 Certificate object. > Someone not totally familiar with TLS and X.509 will have a hard time > understanding this sentence. I also believe that this sentence isn't > needed as it is correctly described in the sentences before it. > Perhaps a mention about the certificate data being in DER format > should be placed here. That's why we have Normative Reference section. You ought to read (well and understand) documents in Normative References. > - ----- >=20 > Page 11, section 4: > 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, MUST cause the connection > to be aborted. >=20 > The first sentence is a bit superfluous, maybe change this to: >=20 > o If the DNSSEC validation state of the TLSA RRset is bogus, .... RRset doesn't have validation status. > - ----- >=20 > Page 29, Appendix C: >=20 > The following are examples of self-signed certificates that have been > been generated with various selectors and matching types. They were > generated with one piece of software, and validated by an individual > using other tools. >=20 > Is a bit lacking in formation, perhaps something like the following > will make it better: >=20 > The following examples are created from a single self-signed > certificate to show the differences between the various selectors and > matching types. These examples have been created and verified using > different tools. Either is fine for me. > - ----- >=20 > Appendix B: >=20 > As an addition to Appendix B, I have created a better pseudo code for > the creation of the Certificate Association Data field. >=20 > // Helper functions > select(S, C) { > if (S=3D=3D0) { > return as_DER(C) > } > if (S=3D=3D1){ > return as_DER(C.SubjectPublicKeyInfo) > } > } >=20 > hash(M,D) { > if (M=3D=3D0) { > return D > } > if (M=3D=3D1) { > return SHA256(D) > } > if (M=3D=3D2) { > return SHA512(D) > } > } >=20 > // Main function > create_assoc_data(Certificate, Selector, MatchingType) { > return hash(MatchingType, select(Selector, Certificate)) > exit > } LGTM > - ----- >=20 > Feel free to ignore/comment on/bury any of these suggestions. >=20 > Regards, >=20 > Pieter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iQIcBAEBAgAGBQJPVzvfAAoJELPqGO5ebd4jBw4QAIULqHd7+aVUbHrmBoZgTY5x > BuCppWsr7krL6av630kdfbIZ+YGnDxj6MO8FlQ+Rb4W6BIGTdIbFx8YWYJHnzKZr > qcZgsaYfaks/o4eU+S9x+Mb7HlnZOUTEixkZrOg6pJsjGDo9kuFJgsa32D607x4l > 5qPbnwnIvY7wRaejrQiVEe5FG3WpqFNkpTJlYgnV17rmaHBHwLgV2RVZqfJAMe05 > 911jGh3XY1RTcy62kr8JM2DywxZP75cy9IMK3aVEHPa5G4yeTOy609nzxD5nmPv2 > Ix2+sA89ZorwDkc9cw1hjLGetjStOdGnvAKBe/7ar6LslK+eo/WcPGMhWe2UWVHY > lOAUK7Y41GwBlwAAqmo1f3nhVAhlslUU8ToU9nzDUyKHE1qk/tvFEIHI2cOBBAN2 > 17coxgcL16sWGU9yTau4zcK7uBLaOEQWq1vOojA+7DwB03ZDPf7Pz3DeFTzx5AJg > uyeWkvu/5MwyK9eTI9xGcNnnAv1kUTQQ8wsMmqparamcHyt2J+rHwHvfNnusUfFW > 1zoGStMt1OCV6fykDoMpzZ7bgCsCe6V8MgceTVUAri/WiQYYtV/pWs4Uut2M6jdK > DsrWDqGTEr4RWkyfj1e8IZn6I4BKyBLfG8UDxFfygJchJEn97fQb33OkpXKV3mvs > jgiNmOTrwgMqqPlJtI2i > =3DCWaB > -----END PGP SIGNATURE----- > _______________________________________________ > 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 ondrej.sury@nic.cz Wed Mar 7 04:35:02 2012 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 5EA4121F8510 for ; Wed, 7 Mar 2012 04:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.474 X-Spam-Level: X-Spam-Status: No, score=-1.474 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HakAuJv0KOa for ; Wed, 7 Mar 2012 04:35:01 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0C75821F850B for ; Wed, 7 Mar 2012 04:35:01 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:3cfb:69e7:ff98:9d4b] (unknown [IPv6:2001:1488:ac14:1400:3cfb:69e7:ff98:9d4b]) by mail.nic.cz (Postfix) with ESMTPSA id 535D32A0850; Wed, 7 Mar 2012 13:35:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331123700; bh=XdQP2vltO3qvWA5MqmF7xLhCoYzBTNuDfHPMs5YZKBw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=BSFikpNmom/w4uDDmGfIVxKQ4ilxOCwSI9+/slgSQPyBER/smXjXKA0l77gVwCu7A mQdM2Ns1W7cQsRmsL5musL4COQwUniNNfD9YpHtnewZaEFj6W1vci9NbLIcRA+griu W8uT4j3TZKp3yKHo1ZROv5ZKtthSDekAKhNTMlu0= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4F54E543.5060207@nic.cz> Date: Wed, 7 Mar 2012 13:35:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201202292322.q1TNMIWD028275@new.toad.com> <4F54E543.5060207@nic.cz> To: Ondrej Mikle X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Draft -17 comments 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 Mar 2012 12:35:02 -0000 Hi WG, On 5. 3. 2012, at 17:09, Ondrej Mikle wrote: > On 03/01/2012 12:22 AM, John Gilmore wrote: >>=20 >> In section A.1: >=20 > [snip] >=20 >>=20 >> We do have a section later about this (A.1.2), but it seems to me >> that the much bigger question for TLS server operators is which >> certificate usage type to use, and which certificate it should = identify. >> Whether it matches the whole cert, or just the public key; and = whether it >> hashes, or provides the whole thing, are secondary to that initial >> choice that we don't even discuss. >=20 > A rough guide that should cover most cases (I'm numbering it A.1.4 = since Jim > Schaad proposed additional subsection A.1.3). It's by no means perfect = given how > many cases are there, but I think it's not misleading (much). >=20 > -- >=20 > A.1.4 Transitioning to DANE-based system from current CA-based system >=20 > This is a rough guide covering selection of certificate usage for > server operators depending on how certificates were deployed on > existing server's TLS services. It is by no means exhaustive but = should > point at the right direction for the majority of common cases. = Server > operators may have different preferences or policies that won't be > covered here due to large amount of possible combinations. >=20 > o Does TLS service use a well-known trusted CA-issued certificate? > o If yes, then: > o Does the service use single or at most two certificates? > o choose certificate usage 1 (Service certificate constraint) > o Otherwise (for cloud or CDN with many end-entity = certificates): > o choose certificate usage 0 (CA constraint) > o If no, then: > o Does service use self-signed certificate? > o choose certificate usage 3 (Domain-issued certificate) > o Otherwise the case is that service certificate is issued by a > custom CA or a not-well-known CA > o choose certificate usage 2 (Trust anchor assertion) >=20 > It should be noted that the line between associating to a CA > certificate or end-entity certificate is not an absolute. Therefore > the above guide should be treated as informative. >=20 > Associating with end-entity certificate (certificate usages 1 and 3) > provides strictest assertion and is not affected by validation path > building mechanisms at TLS clients' side. However associating with > end-entity certificate might not be always possible (e.g. cloud > service with hundreds of end-entity certificates) or desired for > operational reasons (e.g. frequently exchanged end-entity > certificate). >=20 > -- Do we really include a complete "HOWTO" in the Appendix? What does the = rest of WG think? >>> Certificate usage 2 is not affected by the different types of chain >>> building when the end entity certificate is the same as the trust >>> anchor certificate. >>=20 >> Here's a clearer way to say it, which also points out that usage 3 is >> also immune from the troubles discussed: "Certificate usages 2 and 3 >> are not affected by the different types of chain building, if the end >> entity certificate provided by the TLS server is the same as the >> certificate identified by (or provided in) the TLSA record." >=20 > At the time certificate usage 3 was not yet created. I propose = following > formulation in the place of the "Certificate usage 2..." sentence: >=20 > "Association with end-entity certificate is immune from = unpredictability in TLS > clients' validation path building algorithms. That means there are = only two > cases affected: certificate usage 0 and certificate usage 2 if = association is > made to a CA certificate." I understand the problem, but I don't like this text. >> In section A.1.2.2: >>> One specific use-case should be noted: creating a TLSA association = to >>> certificate I1 that directly signed end entity certificate S1 of the >>> server. Since the key used to sign S1 is fixed, association to I1 >>> must succeed: if a client swaps I1 for I2 (a different certificate), >>> its SPKI must match SPKI of I1. Such and association would not >>> suffer from a false-negative failure on client's side if the client >>> uses a reissued CA certificate I2 in place of I1. >>=20 >> A few issues here. This is very dense and hard to understand; it = took >> me a few readings. Second, we use "SPKI" without defining it (the >> previous graf says SubjectPublicKeyInfo and is where we could hang a >> "(SPKI)"). Third, "Such and association" should be "Such an >> association". >=20 > An attempt to make the S1/I1/I2 case more readable (a replacement for = the > paragraph "One specific use-case should be noted [...] uses a reissued = CA > certificate I2 in place of I1."): >=20 > -- >=20 > One specific use-case should be noted: creating a TLSA association = to > CA certificate I1 that directly signed end entity certificate S1 of > the server. The case can be illustrated by following graph: >=20 > +----+ +----+ > | I1 | | I2 | > +----+ +----+ > | | > v v > +----+ +----+ > | S1 | | S1 | > +----+ +----+ >=20 > certificate chain sent by a different validation path > server in TLS handshake built by TLS client >=20 > I2 is a reissued version of CA certificate I1 (e.g. having different > hash in signature algorithm). >=20 > In the above scenario, both certificates I1 and I2 that sign S1 must > have identical SubjectPublicKeyInfo, because the key used to sign S1 > is fixed. An association to SubjectPublicKeyInfo (selector type 1) > will always succeed in such case whereas association with full > certificate (selector type 0) might miss due to false-negative = failure. LGTM 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 Wed Mar 7 04:54:00 2012 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 9904D21F8716 for ; Wed, 7 Mar 2012 04:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.483 X-Spam-Level: X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LsHfhrgdTCp for ; Wed, 7 Mar 2012 04:53: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 6767B21F8715 for ; Wed, 7 Mar 2012 04:53:59 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:3cfb:69e7:ff98:9d4b] (unknown [IPv6:2001:1488:ac14:1400:3cfb:69e7:ff98:9d4b]) by mail.nic.cz (Postfix) with ESMTPSA id ADAE12A2FAF; Wed, 7 Mar 2012 13:53:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331124838; bh=t2UCeRuybD6kzA9u/m6z2LNhnqhPud3RB+rH/1KuyDc=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=mqXgc9ejgzE2ZEfezazK8CTLB60DDZaQ723GGoB6Rz3tn1qofyhDl0sXuErM+NRhc GPW/jwp9B8R3lPEFCdjHejg9CLQ2pV7buN1w26c+ZmqIY3agPQnngFVnPa80Ic8Fyx +QtUJEvkPnulFXd0cgDaXExzD7iSoijZsw9yGEkw= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <003c01ccfa5d$548ad930$fda08b90$@augustcellars.com> Date: Wed, 7 Mar 2012 13:53:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <61E259DF-E4E2-44C7-880B-1DA1E21933BC@nic.cz> References: <20120229154724.18071.36972.idtracker@ietfa.amsl.com> <003c01ccfa5d$548ad930$fda08b90$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-17.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 12:54:00 -0000 Jim, thanks for extensive review. On 5. 3. 2012, at 0:20, Jim Schaad wrote: > Here are some comments on this draft and some comments on the -16 = version > that I could never get the mailing list to accept. >=20 >=20 > 1. In section 1.1. paragraph 3: "TLS uses certificates to protect = keys." > TLS uses certificates to bind names to keys, it does nothing about > protecting the secret portion of the key discussed in the previous > paragraph. I suggest changing the text to state "TLS uses = certificates to > bind keys and names." Or possibly just remove the sentence entirely. LGTM (both options) > 2. In section 2.1.1 - item usage 2 -- nit - s/must be used as a trust > anchor/must be used as the trust anchor/ The certificate is not added = to the > set of trust anchors, it is the set of trust anchors. This means that = a > specific rather than a general indicator should be used. +1 > 3. In section 2.1.1 - I do not find the details for usage #3 to be = clear. I > believe from what I saw on the mailing this that what is being said is = that > the certificate must match the end entity certificate and that = certificate > is the trust anchor certificate and is therefore implicitly trusted. = The > current text does not make that clear to me. I find it difficult to > understand the difference between usage 1 and usage 3 based strictly = on the > text given. Additionally I have a problem with implying that this = usage is > the "domain-issued certificate", I thought that the same term was used = in > case 2 where the CA is strictly inside of the domain and the CA issued > certificates. I have just re-read the text in RFC 6394 and don't see = any > way from it to distinguish between the trust-anchor and domain-issued > certificate cases. There is definitely nothing that states that > domain-issued certificates would be a self-signed certificate rather = than > one that is placed in a hierarchy. The main difference between 1 and 3 is: #1: The target certificate MUST pass PKIX certification path validation = and MUST match the TLSA record. #3: The target certificate MUST match the TLSA record. I agree that "domain-issued certificate" may be confusing, but I have no = ideas on a better name. > 4. In section 4 - the text is > If a host is using TLSA usage type 2 for its certifcate, the > corresponding TLS server SHOULD send the certificate that is > referenced just like it currently sends intermediate = certificates. >=20 > I find this text slightly confusing. =46rom the previous mailing list > traffic, I thought in this case there was an effective one certificate = path > and therefore no intermediate certificates would exist. =20 Nope. The validation path in case 2 could contain more certificates. > I believe you mean > to say that it should be sent just like the EE certificate is. > s/certifcate/certificate/ >=20 > 5. In section 5 - "No Downgrade" - The last clause in the paragraph = does > not agree with the text in section 4 - I would request that the last = clause > be changed to "TLS will not successfully connect." or "TLS will fail = the > connection." The text implies no attempt, rather than being aborted = after > the attempt has started. - I will agree that this is kind of a nit. LGTM > 6. - Very weak suggestion - you might consider using RFC 6234 as the = SHA2 > reference rather than the NIST document. I don't care. FIPS is OK for me. > 7. In section 7.1 - I find the text in paragraph #2 to be a = non-sequitur. > I think that this text is general and applies to all of the following > sections. As such it more properly belongs in section 7 rather than = in > section 7.1. If I were to skip reading section 7.1 because I know the > RRtype I would miss the RFC required requirement. +1 > Potentially the text > could be removed as the policy is listed individually for each = section; this > is just a rationalization text that makes no sense where it is = located. I would suggest to keep it, because I am sure somebody will ask about = why we have chosen RFC Required in IETF LC, then in reviews and lastly = in IESG. > 8. In section 8 - The following text is included >=20 > Client treatment of any information included in the certificate > 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. >=20 > Which domain name administrator are we talking about here? The > client's or the server's administrator?=20 I think the server's administrator. We should make this clear in the = document. > 9. In section 8 - I believe that the following text is missing: > =09 > The client acceptance of an arbitrary certificate retrieved from = a > TLSA record with a usage type of 2 or 3 as fully trusted may be a = matter of > local policy. While such trust is limited to the specific domain for = which > the TLSA query has been made, local policy may deny the trust or = further > restrict the conditions under which that trust is permitted. LGTM > 10. In section A.1 - does the last paragraph still apply given that = we have > added usage 3? Are we still suggesting that usage 2 be used for a = single > certificate chain or that people should use usage 3? True. Needs to be fixed. See my reply to Ondrej Mikle. > 11. Section A.1.2 - Suggested replacement text > In this section, a "false-negative failure" means that a client cannot > build a certificate chain that validates with the TLSA data provided = by the > DNS administrator when a legal chain does exist. A "false-positive = failure" > means that the client successfully builds a certificate chain that = validates > with the TLSA data provided and for which the DNS administrator = intended > that the validation fails. LGTM, but how does that apply to Usage 3 which have no chain and must = match the cert/SPKI? But could somebody else please also check the new text? > As the text currently stands, I believe that a false-negative not be = true if > a chain was built that did not use the certificate in the TLSA data. = I also > wonder if the false-negative case is supposed to apply for the cases = that a > TLSA data record is marked as unusable for any reason and would thus = include > the case of DNSSEC indeterminate? >=20 > 12. Section A.1.3-I suggest adding the following new bullet >=20 > o The administrator should understand that any CA could, in the = future, > issue a certificate that contains the same SubjectPublicKeyInfo and > therefore new chains can crop up in the future without any warning. LGTM -- 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.mikle@nic.cz Thu Mar 8 08:17:23 2012 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 6A5C121F8639 for ; Thu, 8 Mar 2012 08:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 MAGEsN9r1Aua for ; Thu, 8 Mar 2012 08:17:22 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C013721F852E for ; Thu, 8 Mar 2012 08:17:22 -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 9352A2A2C8F for ; Thu, 8 Mar 2012 17:17:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331223441; bh=+x+VZo4pBpje+fG6NWebEhLbyRRY/cfk1IjPM97V7nU=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=k2uq57Nzeq8BitGkr9fLq68IXb5QJ1foR1LNa2tG9nx0CQYGSKXOaqDwoIObPb1dZ 99RFy8WtnzQxqbGuU3RztyjM6MOlzf6gE4xKx7sPs/sdszBtPSItzglbieX6HUNVYs aT5UEpakLpaXl0u6dw9zVe3qe9qJtTGQERwbLG4I= Message-ID: <4F58DB47.4050701@nic.cz> Date: Thu, 08 Mar 2012 17:16:07 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dane@ietf.org X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] Making certificate usage type 2 "CA-only"? 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 Mar 2012 16:17:23 -0000 Hi all, as there was some confusion in the last "I-D Action: draft-ietf-dane-protocol-17.txt" thread about certificate usage 2, maybe it would be clearer to restrict usage 2 only to CA-certificates? Since we created usage type 3, it could be nice to have "disjunct/orthogonal" certificate usage types. ATM certificate usage 2 can be used for CA-cert as well as EE-cert and thus overlaps a bit with certificate usage 3. I think that usage type 2 is intended for CA certs. It would require following minor modifications in draft: - in section 2.1.1 usage 2, change "certificate" to "CA certificate" on the first line, so it'd become: 2 -- Certificate usage 2 is used to specify a CA certificate, or the public key of such a certificate, that must be used as a trust - in section A.1, the last paragraph starting with "Certificate usage 2 [...]" would become: Certificate usage 2 might be affected by the different types of validation path building as well. - in section B.2, the pseudocode dealing with certificate usage 2 would become (basically almost identical to usage 0 except the "that has R as the trust anchor" part): // pass PKIX certificate validation using TLSA record as the // trust anchor if (R.certUsage == 2) { for each PKIX certification path H that has R as the trust anchor { if (C passes PKIX certification path validation in H) { for each D in H { if ((D is a CA certificate) and Match(R.matchingType, Select(R.selectorType, D), R.cert)) { Finish(ACCEPT) } } } } } BTW I've just noticed that current pseudocode in case of usage 2 only tests against the end-entity certificate C, not against every cert in validation path. Ondrej Mikle From paul.hoffman@vpnc.org Thu Mar 8 19:45:42 2012 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 DAF4B21E801C for ; Thu, 8 Mar 2012 19:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 UmTwP6FbIns3 for ; Thu, 8 Mar 2012 19:45:42 -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 6D61D21E8010 for ; Thu, 8 Mar 2012 19:45:42 -0800 (PST) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q293jc8V090652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Mar 2012 20:45:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: <61E259DF-E4E2-44C7-880B-1DA1E21933BC@nic.cz> Date: Thu, 8 Mar 2012 19:45:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120229154724.18071.36972.idtracker@ietfa.amsl.com> <003c01ccfa5d$548ad930$fda08b90$@augustcellars.com> <61E259DF-E4E2-44C7-880B-1DA1E21933BC@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-17.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 03:45:43 -0000 [[ Commenting only on the Appendix A stuff ]] On Mar 7, 2012, at 4:53 AM, Ond=C5=99ej Sur=C3=BD wrote: > On 5. 3. 2012, at 0:20, Jim Schaad wrote: >=20 >> 10. In section A.1 - does the last paragraph still apply given that = we have >> added usage 3? Are we still suggesting that usage 2 be used for a = single >> certificate chain or that people should use usage 3? >=20 > True. Needs to be fixed. See my reply to Ondrej Mikle. >=20 >> 11. Section A.1.2 - Suggested replacement text >> In this section, a "false-negative failure" means that a client = cannot >> build a certificate chain that validates with the TLSA data provided = by the >> DNS administrator when a legal chain does exist. A "false-positive = failure" >> means that the client successfully builds a certificate chain that = validates >> with the TLSA data provided and for which the DNS administrator = intended >> that the validation fails. >=20 > LGTM, but how does that apply to Usage 3 which have no chain and must = match the cert/SPKI? >=20 > But could somebody else please also check the new text? Appendix A only applies to things that do PKIX validation, and usage = type 3 doesn't. I don't think that changes need to be made to handle = type 3, or maybe we could add at the beginning "This appendix applies to = certificate usage types 0, 1, and 2 only. Using certificate usage type 3 = avoids the operational considerations described in this appendix." --Paul Hoffman From ietf@augustcellars.com Thu Mar 8 21:11:28 2012 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 1269C21F8663 for ; Thu, 8 Mar 2012 21:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.450, 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 GfFQm8EHPaWS for ; Thu, 8 Mar 2012 21:11:27 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 08C7521F8674 for ; Thu, 8 Mar 2012 21:11:23 -0800 (PST) Received: from Tobias (50-39-221-206.bvtn.or.frontiernet.net [50.39.221.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id DF54E2CA28; Thu, 8 Mar 2012 21:11:22 -0800 (PST) From: "Jim Schaad" To: =?UTF-8?Q?'Ondrej_Sur=C3=BD'?= References: <20120229154724.18071.36972.idtracker@ietfa.amsl.com> <003c01ccfa5d$548ad930$fda08b90$@augustcellars.com> <61E259DF-E4E2-44C7-880B-1DA1E21933BC@nic.cz> In-Reply-To: <61E259DF-E4E2-44C7-880B-1DA1E21933BC@nic.cz> Date: Thu, 8 Mar 2012 21:10:32 -0800 Message-ID: <002a01ccfdb2$f6b5b010$e4211030$@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: AQJ6dF6NY30juHEJb9CtgErkH0ncwgHTUbc9AcNiKp6U6cROEA== Content-Language: en-us Cc: 'Paul Hoffman' , dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-17.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 05:11:28 -0000 Sorry for the delay, I have finally found where a pile of e-mail = messages was wandering off to. > -----Original Message----- > From: Ondrej Sur=C3=BD [mailto:ondrej.sury@nic.cz] > Sent: Wednesday, March 07, 2012 4:54 AM > To: Jim Schaad > Cc: dane@ietf.org; Paul Hoffman > Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-17.txt >=20 > Jim, >=20 > thanks for extensive review. >=20 > On 5. 3. 2012, at 0:20, Jim Schaad wrote: >=20 > > 3. In section 2.1.1 - I do not find the details for usage #3 to be > > clear. I believe from what I saw on the mailing this that what is > > being said is that the certificate must match the end entity > > certificate and that certificate is the trust anchor certificate and > > is therefore implicitly trusted. The current text does not make = that > > clear to me. I find it difficult to understand the difference = between > > usage 1 and usage 3 based strictly on the text given. Additionally I > > have a problem with implying that this usage is the "domain-issued > > certificate", I thought that the same term was used in case 2 where > > the CA is strictly inside of the domain and the CA issued > > certificates. I have just re-read the text in RFC 6394 and don't = see > > any way from it to distinguish between the trust-anchor and > > domain-issued certificate cases. There is definitely nothing that > > states that domain-issued certificates would be a self-signed = certificate > rather than one that is placed in a hierarchy. >=20 > The main difference between 1 and 3 is: > #1: The target certificate MUST pass PKIX certification path = validation and > MUST match the TLSA record. > #3: The target certificate MUST match the TLSA record. That still does not make it clear that the difference is that #3 says = you must match and it is absolutely trusted iff it matches. >=20 > I agree that "domain-issued certificate" may be confusing, but I have = no > ideas on a better name. >=20 > > 4. In section 4 - the text is > > If a host is using TLSA usage type 2 for its certifcate, the > > corresponding TLS server SHOULD send the certificate that is > > referenced just like it currently sends intermediate = certificates. > > > > I find this text slightly confusing. From the previous mailing list > > traffic, I thought in this case there was an effective one = certificate > > path and therefore no intermediate certificates would exist. >=20 > Nope. The validation path in case 2 could contain more certificates. My confusion - I read this as usage type 3 not usage type 2. >=20 > > I believe you mean > > to say that it should be sent just like the EE certificate is. > > s/certifcate/certificate/ > > >=20 > > 8. In section 8 - The following text is included > > > > Client treatment of any information included in the certificate = 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. > > > > Which domain name administrator are we talking about here? The > > client's or the server's administrator? >=20 > I think the server's administrator. We should make this clear in the > document. > > 10. In section A.1 - does the last paragraph still apply given that = we have > > added usage 3? Are we still suggesting that usage 2 be used for a = single > > certificate chain or that people should use usage 3? >=20 > True. Needs to be fixed. See my reply to Ondrej Mikle. >=20 > > 11. Section A.1.2 - Suggested replacement text > > In this section, a "false-negative failure" means that a client = cannot > > build a certificate chain that validates with the TLSA data provided > > by the DNS administrator when a legal chain does exist. A = "false-positive > failure" > > means that the client successfully builds a certificate chain that > > validates with the TLSA data provided and for which the DNS > > administrator intended that the validation fails. >=20 > LGTM, but how does that apply to Usage 3 which have no chain and must > match the cert/SPKI? Since you do not build a chain in this case - there is no possible = false-positive or false-negative failure from chain building. >=20 > But could somebody else please also check the new text? >=20 > > As the text currently stands, I believe that a false-negative not be > > true if a chain was built that did not use the certificate in the = TLSA > > data. I also wonder if the false-negative case is supposed to apply > > for the cases that a TLSA data record is marked as unusable for any > > reason and would thus include the case of DNSSEC indeterminate? > > > > 12. Section A.1.3-I suggest adding the following new bullet > > > > o The administrator should understand that any CA could, in the > > future, issue a certificate that contains the same > > SubjectPublicKeyInfo and therefore new chains can crop up in the = future > without any warning. Oops - this should have been section A.1.2.2 - sorry >=20 >=20 > LGTM >=20 > -- > 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 Fri Mar 9 02:17:52 2012 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 BE19721F8639 for ; Fri, 9 Mar 2012 02:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hp0xemYyz1oS for ; Fri, 9 Mar 2012 02:17:52 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E462421F862A for ; Fri, 9 Mar 2012 02:17:49 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:2078:11bb:9c7a:ac3e] (unknown [IPv6:2001:1488:ac14:1400:2078:11bb:9c7a:ac3e]) by mail.nic.cz (Postfix) with ESMTPSA id 0E7232A301B; Fri, 9 Mar 2012 11:17:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331288268; bh=w1FUVsjygOeVXx704XGff/FCm4YXA84kwiyEkESIhVE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=K8kUDWXzSt62UO+NogJV9WbneuYK1xZEgWCycIdzm//sQJ7uQ6wteR4HU5sFb0kDD 6u2uvz8SWY3qLFYq68w/aBidp2UujZ1TikDEZxDvcYELjomXhhYeZJMbgoZF+4Q4li xsDIOVEOfeuQyool6Bt/0kjin3AoCXP+fuAWAiRE= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201202292322.q1TNMIWD028275@new.toad.com> Date: Fri, 9 Mar 2012 11:17:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <104DA3BC-FB05-447C-99C1-6D2C92B0B8AE@nic.cz> References: <201202292322.q1TNMIWD028275@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , IETF DANE WG list Subject: [dane] DNS Caching leftovers X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 10:17:52 -0000 On 1. 3. 2012, at 0:22, John Gilmore wrote: > In section 5: >> Roll-over -- Section 4 states that applications must not cache TLSA=09= >> records beyond their TTL expiration. This ensures that clients=20 >> will not latch onto assertions made by expired TLSA records, and=20 >> will be able to transition between using one DANE mechanism to=20 >> another. >=20 > Section 4 no longer says that about TTL cacheing, so this will need > modification. Perhaps refer now to section 8.1? But that describes > security considerations, not requirements on implementations. >=20 > I'd also suggest replacing the last phrase with "will be able to > transition from using one DANE public key or certificate usage type to > another." Good catch. Let's rephrase the first sentence to something like: Roll-over -- TLSA records are processed in the normal manner within the scope of DNS protocol including the TTL expiration of the records. This ensures that clients will not latch onto assertions made by expired TLSA records, and will be able to transition from using one DANE public key or certificate usage type to another. Somebody with more English skill and higher caffeine levels in blood please rephrase that. I would also suggest to remove text in parentheses in Section 4, = paragraph 4, stripping it down to: An implementation of this protocol makes a DNS query for TLSA = records, validates these records using DNSSEC, and uses the resulting TLSA = records and validation status to modify its responses to the TLS server. 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 Fri Mar 9 02:33:51 2012 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 88E9721F85AE for ; Fri, 9 Mar 2012 02:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY5E3Q-xqkzK for ; Fri, 9 Mar 2012 02:33:51 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9B921F8598 for ; Fri, 9 Mar 2012 02:33:50 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:2078:11bb:9c7a:ac3e] (unknown [IPv6:2001:1488:ac14:1400:2078:11bb:9c7a:ac3e]) by mail.nic.cz (Postfix) with ESMTPSA id E22D12A30A2; Fri, 9 Mar 2012 11:33:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331289229; bh=vaCYpYh13SZSgb/5/+jNsTRt4fb1UwAilhmKoboVqKw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZPlIc0fubuqSbNQn/XbvZW9Ij1sTWXn0fCRvKVrwzj16cejzsco5OyVpr9iSQI6aZ eWt3bX4XGKANWjC1bZBgz7U+3Jkx8cxIRq9BTfuJop0Eub9v+K82jVg4VpQcIyTLRz 5l9wj9UMrjehpukdmIiT7gNp/B9HdHfmzXk2Xybw= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201202292322.q1TNMIWD028275@new.toad.com> Date: Fri, 9 Mar 2012 11:33:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <982BE9BF-5317-4C2F-9A03-0EC8AD119596@nic.cz> References: <201202292322.q1TNMIWD028275@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Draft -17 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 10:33:51 -0000 John, thanks for extensive review. On 1. 3. 2012, at 0:22, John Gilmore wrote: > Thank you, editors! -17 is a big improvement, editorially, over -16. > Most of my comments are small nits, though there's one 2-paragraph > insertion that I think is worthwhile. [deleted the nits and parts which I responded to in separate emails] > In section 6: >> A system creating TLSA records that conforms to this specification >> MUST be able to create TLSA records containing certificate usages 0, >> 1, 2, and 3. A system creating TLSA records that conforms to this >> specification MUST be able to create TLSA records with selectors 0 >> (full certificate) and 1 (SubjectPublicKeyInfo). A system creating >> TLSA records that conforms to this specification MUST be able to >> create TLSA records using matching type 0 (no hash used) and matching >> type 1 (SHA-256), and SHOULD be able to create TLSA records using >> matching type 2 (SHA-512). >=20 > I thought we had agreed to pull this paragraph. Yes, I think so: http://www.ietf.org/mail-archive/web/dane/current/msg04412.html >> A better design for >> authenticating DNS would be to have the same level of authentication >> used for all DNS additions and changes for a particular owner name. >=20 > I'd replace "owner name" with "domain name", since owner name is not > defined anywhere, 'Owner' name is well defined term in DNS > while everyone knows what a domain name is. But 'domain name' is works for me as well. > In section A.1: >=20 >> When creating TLSA records care must be taken to avoid >> misconfigurations. Section 4 of this document states that a TLSA >> RRset whose validation state is secure MUST be used. This means that >> the existence of such a RRset effectively disables other forms of >> name and path validation. A misconfigured TLSA RRset will >> effectively disable access to the TLS server for all conforming >> clients, and this document does not provide any means of making a >> gradual transition to using TLSA. >=20 > I agree that this paragraph needs to be in the document. I think it > belongs in the security considerations section rather than in an > appendix. >=20 > Also, what is a "conforming client"? To what does it conform? > Heaven forefend that it conform to a "p-word"! >=20 > Here there's an important paragraph or 2 missing, just before "When > creating TLSA records with certificate usage type 0 (CA Certificate) > or type 2 (Trust Anchor)...". Before we spend a few pages saying > why it can be tricky to use TLSA in many ways, let's describe a > straightforward, non-tricky way to transition to using TLSA: Here I think this doesn't belong to this document. We just want to have the warning in the document. Your provided text belongs to the website(s) and howtos for the tools to be created. Nobody will look for this advice in the protocol document. [...snip...] >> When creating TLSA records with certificate usage type 0 (CA >> Certificate) or type 2 (Trust Anchor), one needs to understand the >> implications when choosing between selector type 0 (full certificate) >> and 1 (SubjectPublicKeyInfo). A careful choice is required because >> different methods for building trust chains are used by different TLS >> clients. The following outlines the cases that one should be aware >> of and discusses the implications of the choice of selector type. >=20 > I'd rewrite to say (particularly after inserting the above graf): > TLSA server operators who create TLSA records with certificate types > 0, 1, or 2 must take more care, because of the variability in how TLS > clients build trust chains. When creating TLSA records with > certificate usage type 0 (CA Certificate) or type 2 (Trust Anchor), > one needs to understand the implications. The following outlines the > cases that TLS server operators should be aware of. I am sorry, but I see no difference in these two paragraphs in terms of = clarity. But maybe I am in this WG for too long. Rest replied elsewhere (at least I hope I have responded to this in my = response to Ondrej Mikle). >> Certificate usage 2 is not affected by the different types of chain >> building when the end entity certificate is the same as the trust >> anchor certificate. >=20 > Here's a clearer way to say it, which also points out that usage 3 is > also immune from the troubles discussed: "Certificate usages 2 and 3 > are not affected by the different types of chain building, if the end > entity certificate provided by the TLS server is the same as the > certificate identified by (or provided in) the TLSA record." This might be solved in thread: 'Making certificate usage type 2 = "CA-only"?' [I think I have responded to rest of your comments elsewhere, if not = please feel free to point which sections needs more attention.] 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 Fri Mar 9 02:40:21 2012 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 75B0621F8603 for ; Fri, 9 Mar 2012 02:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.506 X-Spam-Level: X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uu+EI0P-b3yG for ; Fri, 9 Mar 2012 02:40: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 EEA2F21F85E4 for ; Fri, 9 Mar 2012 02:40:20 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:2078:11bb:9c7a:ac3e] (unknown [IPv6:2001:1488:ac14:1400:2078:11bb:9c7a:ac3e]) by mail.nic.cz (Postfix) with ESMTPSA id 488EE2A01AE; Fri, 9 Mar 2012 11:40:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331289620; bh=0Ku48JA/qNxewh3vLEEEyNLiBZKH1Mtf+55wvVBgIP4=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=XO57+EixMvTu8EtVRGoZCyEBga4dxASI6IZLWe4cJSYQuC54FV9NRFfd45kpRPJod OCQEr+aBxz9fDgxlmNt78RidLTFfq6HwwHB5dOruEt+dFo+tXZTI5SaMe2rpCTm1SC NUVScok9w0ioHNCKakdNVx/Sas6v3yqD/a5xQJJI= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2012 11:40:20 +0100 Message-Id: To: IETF DANE WG list , Paul Hoffman Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] Nit in 8.1. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 10:40:21 -0000 s/this rule this rule/this rule/ -- 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 Fri Mar 9 02:42:16 2012 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 9E6F321F85F3 for ; Fri, 9 Mar 2012 02:42:16 -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.187, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fd3vCG2eUUtd for ; Fri, 9 Mar 2012 02:42: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 11CB921F85D9 for ; Fri, 9 Mar 2012 02:42:16 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:2078:11bb:9c7a:ac3e] (unknown [IPv6:2001:1488:ac14:1400:2078:11bb:9c7a:ac3e]) by mail.nic.cz (Postfix) with ESMTPSA id 5BB032A087B; Fri, 9 Mar 2012 11:42:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331289735; bh=qzfpsjmBCa6sMJqT5fosGN02eulPKklzq65DEpwnvUU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=oHjXV5GNkUNlZ2tjGqIMTjTOAtEyU6QA2JwtfLz8BCWnanHpI98DIuNxmXx7v7dGT PikysdxkP47jUYNKdFcNsoPeHmWJFZQP4SYeSOJBCXS4g2jK0lrkAgqFM2BqH8Mwqz vWznrS61FvWa16FP/xwf/gUIVpQ8N1IAvIrVQs3g= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201202292322.q1TNMIWD028275@new.toad.com> Date: Fri, 9 Mar 2012 11:42:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <42DC9D20-6FB2-41AA-9828-B27B84653003@nic.cz> References: <201202292322.q1TNMIWD028275@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , IETF DANE WG list Subject: [dane] DNS Caching in 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: Fri, 09 Mar 2012 10:42:16 -0000 On 1. 3. 2012, at 0:22, John Gilmore wrote: > In section 8.1: >> Implementations need to >> be cautious in assuming the continuing validity of an TLSA records/ >> DNS name association. >=20 > "An TLSA records" sounds bad, even though I know it ultimately refers > to "an association". Perhaps you mean "Implementations need to be > cautious in assuming the continuing validity of the association > between TLSA records and a domain name." But that is almost a > tautology, caused by the confusing "association" language. Every DNS > resource record produces an association between the domain name and > the contents of the record. That association is always only good for > a brief time, specified in the TTL. So what are we really trying to > say here? Maybe it is tautology, but we need to say it in Security Consideration sections. Your wording is slightly better, but I am fine with both. I'll leave it to the editors if they accept the change. >> If implementations cache the results of domain name lookups in order >> to achieve a performance improvement, they MUST observe the TTL >> information reported by DNS. Implementations that fail to follow >> this rule this rule could be spoofed when a previously-accessed >> server's TLSA record changes, such as during a certificate rollover. >=20 > I don't see how this can cause an implementation to be "spoofed". If > clients cache beyond the TTL, they'll use the old TLSA records, and > may be unable to access a TLS server that uses a new certificate. But > that's denial of service, not spoofing. The only way I can see to be > spoofed is if the TLS server's previous private-key credentials had > been exposed (and then this is why the TLS server's certificate has > changed and why the corresponding TLSA records were changed). In that > case, someone who obtained the server's previous private-key > credentials, and who can also act as a man-in-the-middle of the TLS > connection, can spoof clients who use the old TLSA records. But > that's a much more detailed and less likely scenario than the one > described. I think you have exactly describe the scenario of spoofing. It is less likely scenario than DoS, but we are talking about security risks. And/or we could add ' or access will be denied' after spoof. 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 Fri Mar 9 02:47:52 2012 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 89CE321F8616 for ; Fri, 9 Mar 2012 02:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.519 X-Spam-Level: X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U86lpuik6P5y for ; Fri, 9 Mar 2012 02:47:52 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B797D21F860B for ; Fri, 9 Mar 2012 02:47:51 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:2078:11bb:9c7a:ac3e] (unknown [IPv6:2001:1488:ac14:1400:2078:11bb:9c7a:ac3e]) by mail.nic.cz (Postfix) with ESMTPSA id C89632A30A2 for ; Fri, 9 Mar 2012 11:47:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331290070; bh=30tG7+t4WC58MqHfjWjPyGxlUGIp02u3zxxMd3WYrWU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=KsXOcdf69Oig3sETMZUz8/MzTGKQTPnpQqz1NiqT03OCqteuU5P8xV4dEcGZki/L9 udH5zt9oxZ0h+mhfTeYKTkDD0iTVHcwJht715R8HXBOh1bsGWlX/C80NgiKgsUKV1N zna6wKfenYZKhaM6QeeTkEIV+adFKujEJPPmehnQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1257) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4F58DB47.4050701@nic.cz> Date: Fri, 9 Mar 2012 11:47:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F58DB47.4050701@nic.cz> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Making certificate usage type 2 "CA-only"? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 10:47:52 -0000 Hi WG, could you please respond to this. I think it's a reasonable suggestion, because now Type 2 and Type 3 overlap, but it might have a big impact on the protocol, so it needs at least some thinking how it will affect the protocol. O. On 8. 3. 2012, at 17:16, Ondrej Mikle wrote: > Hi all, >=20 > as there was some confusion in the last "I-D Action: > draft-ietf-dane-protocol-17.txt" thread about certificate usage 2, = maybe > it would be clearer to restrict usage 2 only to CA-certificates? >=20 > Since we created usage type 3, it could be nice to have > "disjunct/orthogonal" certificate usage types. ATM certificate usage 2 > can be used for CA-cert as well as EE-cert and thus overlaps a bit = with > certificate usage 3. I think that usage type 2 is intended for CA = certs. >=20 >=20 > It would require following minor modifications in draft: >=20 > - in section 2.1.1 usage 2, change "certificate" to "CA certificate" = on > the first line, so it'd become: >=20 > 2 -- Certificate usage 2 is used to specify a CA certificate, or > the public key of such a certificate, that must be used as a = trust >=20 > - in section A.1, the last paragraph starting with "Certificate usage = 2 > [...]" would become: >=20 > Certificate usage 2 might be affected by the different types of > validation path building as well. >=20 > - in section B.2, the pseudocode dealing with certificate usage 2 = would > become (basically almost identical to usage 0 except the "that has R = as > the trust anchor" part): >=20 > // pass PKIX certificate validation using TLSA record as the > // trust anchor > if (R.certUsage =3D=3D 2) { > for each PKIX certification path H that has R as the > trust anchor { > if (C passes PKIX certification path validation in H) { > for each D in H { > if ((D is a CA certificate) and > Match(R.matchingType, Select(R.selectorType, D), > R.cert)) { > Finish(ACCEPT) > } > } > } > } > } >=20 >=20 > BTW I've just noticed that current pseudocode in case of usage 2 only > tests against the end-entity certificate C, not against every cert in > validation path. >=20 > Ondrej Mikle > _______________________________________________ > 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 ietf@augustcellars.com Fri Mar 9 09:32:54 2012 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 92E6E21F86CB for ; Fri, 9 Mar 2012 09:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.450, 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 2nsHhfH3wOq5 for ; Fri, 9 Mar 2012 09:32:52 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA45521F86C9 for ; Fri, 9 Mar 2012 09:32:52 -0800 (PST) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id A244F2CA2F; Fri, 9 Mar 2012 09:32:52 -0800 (PST) From: "Jim Schaad" To: =?UTF-8?Q?'Ondrej_Sur=C3=BD'?= , "'IETF DANE WG list'" References: <4F58DB47.4050701@nic.cz> In-Reply-To: Date: Fri, 9 Mar 2012 09:32:06 -0800 Message-ID: <006901ccfe1a$8ca3eda0$a5ebc8e0$@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: AQFEs1jkDbaK4NNxHN51IpwvHtiB6gHc3J1ul2PnKhA= Content-Language: en-us Subject: Re: [dane] Making certificate usage type 2 "CA-only"? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 17:32:54 -0000 I am strongly in favor of doing something so that the cases are clearly = distinguishable. I think it might be more a case of one-certificate chain vs > one = certificate in chain as text for distinguishing. Jim ] > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of > Ondrej Sur=C3=BD > Sent: Friday, March 09, 2012 2:48 AM > To: IETF DANE WG list > Subject: Re: [dane] Making certificate usage type 2 "CA-only"? >=20 > Hi WG, >=20 > could you please respond to this. I think it's a reasonable = suggestion, > because now Type 2 and Type 3 overlap, but it might have a big impact = on the > protocol, so it needs at least some thinking how it will affect the = protocol. >=20 > O. >=20 > On 8. 3. 2012, at 17:16, Ondrej Mikle wrote: >=20 > > Hi all, > > > > as there was some confusion in the last "I-D Action: > > draft-ietf-dane-protocol-17.txt" thread about certificate usage 2, > > maybe it would be clearer to restrict usage 2 only to = CA-certificates? > > > > Since we created usage type 3, it could be nice to have > > "disjunct/orthogonal" certificate usage types. ATM certificate usage = 2 > > can be used for CA-cert as well as EE-cert and thus overlaps a bit > > with certificate usage 3. I think that usage type 2 is intended for = CA certs. > > > > > > It would require following minor modifications in draft: > > > > - in section 2.1.1 usage 2, change "certificate" to "CA certificate" > > on the first line, so it'd become: > > > > 2 -- Certificate usage 2 is used to specify a CA certificate, = or > > the public key of such a certificate, that must be used as a > > trust > > > > - in section A.1, the last paragraph starting with "Certificate = usage > > 2 [...]" would become: > > > > Certificate usage 2 might be affected by the different types of > > validation path building as well. > > > > - in section B.2, the pseudocode dealing with certificate usage 2 > > would become (basically almost identical to usage 0 except the "that > > has R as the trust anchor" part): > > > > // pass PKIX certificate validation using TLSA record as the > > // trust anchor > > if (R.certUsage =3D=3D 2) { > > for each PKIX certification path H that has R as the > > trust anchor { > > if (C passes PKIX certification path validation in H) { > > for each D in H { > > if ((D is a CA certificate) and > > Match(R.matchingType, Select(R.selectorType, D), > > R.cert)) { > > Finish(ACCEPT) > > } > > } > > } > > } > > } > > > > > > BTW I've just noticed that current pseudocode in case of usage 2 = only > > tests against the end-entity certificate C, not against every cert = in > > validation path. > > > > Ondrej Mikle > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane >=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 internet-drafts@ietf.org Fri Mar 9 09:46:59 2012 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 A421A21F86CB; Fri, 9 Mar 2012 09:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 P59dZLvV3cI8; Fri, 9 Mar 2012 09:46:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3282621F8694; Fri, 9 Mar 2012 09:46:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120309174659.21795.2520.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2012 09:46:59 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-18.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 17:46:59 -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 : The DNS-Based Authentication of Named Entities (DANE) Pr= otocol for Transport Layer Security (TLS) Author(s) : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-protocol-18.txt Pages : 32 Date : 2012-03-09 Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrator of a domain name to certify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-18.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-18.txt From paul.hoffman@vpnc.org Fri Mar 9 09:49:46 2012 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 D1E9321F85F2 for ; Fri, 9 Mar 2012 09:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.698 X-Spam-Level: X-Spam-Status: No, score=-102.698 tagged_above=-999 required=5 tests=[AWL=-0.099, 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 Vb1B1Jc0jdy9 for ; Fri, 9 Mar 2012 09:49:46 -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 67BF921F8456 for ; Fri, 9 Mar 2012 09:49:46 -0800 (PST) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q29HnjSB020047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 9 Mar 2012 10:49:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2012 09:49:44 -0800 Message-Id: To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dane] Draft -18 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 17:49:46 -0000 ... has everything Jakob and I believe we were instructed to do by the = chairs. The chairs will also decide what to do about the issue under = discussion with the definition of usage type 2, but we wanted to get = everyone a clean draft to look at. --Paul Hoffman From paul.hoffman@vpnc.org Fri Mar 9 10:53:08 2012 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 9E5B121E8093 for ; Fri, 9 Mar 2012 10:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.697 X-Spam-Level: X-Spam-Status: No, score=-102.697 tagged_above=-999 required=5 tests=[AWL=-0.098, 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 ztdW-e-Brvaa for ; Fri, 9 Mar 2012 10:53:08 -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 273A021E808D for ; Fri, 9 Mar 2012 10:53:08 -0800 (PST) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q29Ir7U4022558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 9 Mar 2012 11:53:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <20120309184424.5853.82819.idtracker@ietfa.amsl.com> Date: Fri, 9 Mar 2012 10:53:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <72C87898-41D6-45B0-B4F8-EEACED13BA66@vpnc.org> References: <20120309184424.5853.82819.idtracker@ietfa.amsl.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] New Version Notification for draft-hoffman-dane-smime-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 18:53:08 -0000 We have updated the S/MIME draft based on some new interest from a few = folks. We cleaned up one technical detail (look for "Base32"), and added = a privacy-related security consideration. We'll work on this more after the TLSA document is finished, but if = others are also interested, please get in touch with Jakob and I. --Paul Hoffman On Mar 9, 2012, at 10:44 AM, internet-drafts@ietf.org wrote: > A new version of I-D, draft-hoffman-dane-smime-03.txt has been = successfully submitted by Paul Hoffman and posted to the IETF = repository. >=20 > Filename: draft-hoffman-dane-smime > Revision: 03 > Title: Using Secure DNS to Associate Certificates with = Domain Names For S/MIME > Creation date: 2012-03-09 > WG ID: Individual Submission > Number of pages: 6 >=20 > Abstract: > S/MIME uses certificates for authenticating and encrypting messages. > Users want their mail user agents to securely associate a = certificate > with the sender of an encrypted and/or signed message. DNSSEC > provides a mechanism for a zone operator to sign DNS information > directly. This way, bindings of certificates to users within a > domain are asserted not by external entities, but by the entities > that operate the DNS. This document describes how to use secure DNS > to associate an S/MIME user's certificate with the intended = domain > name. From cloos@jhcloos.com Fri Mar 9 13:37:25 2012 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 96CC721E8088 for ; Fri, 9 Mar 2012 13:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.392, 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 Kx1m8Ndun6GO for ; Fri, 9 Mar 2012 13:37:25 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id E260821E8032 for ; Fri, 9 Mar 2012 13:37:24 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 952E540107; Fri, 9 Mar 2012 21:36:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1331329042; bh=eI+wfc1i9fgjgp5SGEgeOFeehlrRb1EPb6fK+g6Cg8Y=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=nvgBQDW+Uye6bZlpnZ4HKii3y7234KtfBrOOiRa+NdtlgxKHTCOpBFV9kSsieSPTs 5QiI7I4cShaQtX/v8+ZuShdoe+GFd3WcTH+z4gx6AvA+QwxczStVXA4vDJi5eKxS4o KgL99Fh00HdmaiB1x2SJXSX44CevZAbOckz8b4XY= Received: by carbon.jhcloos.org (Postfix, from userid 500) id F209036004D; Fri, 9 Mar 2012 21:34:17 +0000 (UTC) From: James Cloos To: IETF DANE WG list In-Reply-To: (=?utf-8?Q?=22O?= =?utf-8?Q?nd=C5=99ej_Sur=C3=BD=22's?= message of "Fri, 9 Mar 2012 11:47:50 +0100") References: <4F58DB47.4050701@nic.cz> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 09 Mar 2012 16:34:16 -0500 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:120309:dane@ietf.org::IZ06sdgkvlhTCc5H:000ZkEtX X-Hashcash: 1:30:120309:ondrej.sury@nic.cz::YU1io93QWbz+rVB8:000000000000000000000000000000000000000000Aly4G Subject: Re: [dane] Making certificate usage type 2 "CA-only"? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 21:37:25 -0000 >>>>> "OS" == OndÅ™ej Surý writes: OS> could you please respond to this. I think it's a reasonable suggestion, OS> because now Type 2 and Type 3 overlap, but it might have a big impact on OS> the protocol, so it needs at least some thinking how it will affect the OS> protocol. Given the addition of type 3, it is reasonable to restrict type 2 from applying to an EE cert. But it still should be possible to list either a root cert or an intermediate cert in a type 2 RR. I'm too exhausted right not to suggest prose for that. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From cloos@jhcloos.com Fri Mar 9 14:03:29 2012 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 1235021E80D5 for ; Fri, 9 Mar 2012 14:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.382, 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 cXzqbZ1ArUjV for ; Fri, 9 Mar 2012 14:03:28 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id D5EE521E80C2 for ; Fri, 9 Mar 2012 14:03:22 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 4F9C7401BB; Fri, 9 Mar 2012 22:02:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1331330602; bh=2faq+81P6rL5cWV4XrmeFFHc6JBN7FNmQw3h64oMwck=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=HHoufWOOZydHEzQxs8LhNEJmTUqmzEPUQ4vDgnAHlBI/Co4tINgZpS1APs5lFXorF EIu1yLqVZlW2A/0AbeLSfOOIon5V3mSXMLxxywxQJQ2cg9abQipaPCzCm/EyD1QxFq 5A2cb/FcrScA/+JAw6fZSYlOOoTih8gk7tGZoCv0= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 297D036004C; Fri, 9 Mar 2012 21:50:17 +0000 (UTC) From: James Cloos To: Paul Hoffman In-Reply-To: <72C87898-41D6-45B0-B4F8-EEACED13BA66@vpnc.org> (Paul Hoffman's message of "Fri, 9 Mar 2012 10:53:06 -0800") References: <20120309184424.5853.82819.idtracker@ietfa.amsl.com> <72C87898-41D6-45B0-B4F8-EEACED13BA66@vpnc.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 09 Mar 2012 16:50:17 -0500 Message-ID: Lines: 9 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:120309:paul.hoffman@vpnc.org::b1EwcXCuvZ+NEDY6:00000000000000000000000000000000000000093j13 X-Hashcash: 1:30:120309:dane@ietf.org::qObQfw4l5KEh7ajp:000jUKG0 Cc: IETF DANE WG list Subject: Re: [dane] New Version Notification for draft-hoffman-dane-smime-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:03:29 -0000 My local cache hasn't got -03 yet, but from a quick look at 02, there should be some text on how to deal with non-ascii username strings (even if only to say that they are encoded just like any other non-ascii dns name). might make a good example. ☺ -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From paul.hoffman@vpnc.org Fri Mar 9 14:24:32 2012 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 6CDF221F85F4 for ; Fri, 9 Mar 2012 14:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.696 X-Spam-Level: X-Spam-Status: No, score=-102.696 tagged_above=-999 required=5 tests=[AWL=-0.097, 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 yzcmfBP8aCeM for ; Fri, 9 Mar 2012 14:24:32 -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 C23A221F85F2 for ; Fri, 9 Mar 2012 14:24:15 -0800 (PST) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q29MOCrT030507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Mar 2012 15:24:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: Date: Fri, 9 Mar 2012 14:24:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <56D0CC34-2CC2-47E1-A155-3B43EC49CFD7@vpnc.org> References: <20120309184424.5853.82819.idtracker@ietfa.amsl.com> <72C87898-41D6-45B0-B4F8-EEACED13BA66@vpnc.org> To: James Cloos X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] New Version Notification for draft-hoffman-dane-smime-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:24:32 -0000 On Mar 9, 2012, at 1:50 PM, James Cloos wrote: > My local cache hasn't got -03 yet, but from a quick look at 02, > there should be some text on how to deal with non-ascii username > strings (even if only to say that they are encoded just like any > other non-ascii dns name). might make a > good example. =E2=98=BA Already covered in -03. When you read the draft, if you think we need to = add more text about this, let us know. --Paul Hoffman From rbarnes@bbn.com Sat Mar 10 06:59:24 2012 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 26B5A21F85C5 for ; Sat, 10 Mar 2012 06:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.537 X-Spam-Level: X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 zPTAJQUd6k2q for ; Sat, 10 Mar 2012 06:59:23 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 436CD21F85B6 for ; Sat, 10 Mar 2012 06:59:23 -0800 (PST) Received: from [128.89.253.57] (port=57772) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S6NlK-000Ezi-3Z; Sat, 10 Mar 2012 09:59:14 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Sat, 10 Mar 2012 09:59:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <504075FB-AB95-46E2-B06B-508ED106EB39@bbn.com> References: <4F58DB47.4050701@nic.cz> To: James Cloos X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Making certificate usage type 2 "CA-only"? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 14:59:24 -0000 > OS> could you please respond to this. I think it's a reasonable = suggestion, > OS> because now Type 2 and Type 3 overlap, but it might have a big = impact on > OS> the protocol, so it needs at least some thinking how it will = affect the > OS> protocol. >=20 > Given the addition of type 3, it is reasonable to restrict type 2 from > applying to an EE cert. >=20 > But it still should be possible to list either a root cert or an > intermediate cert in a type 2 RR. Asserting a trust anchor makes this true trivially, since path = validation stops when you hit a trust actor, even if it's in the middle = of a provided chain. --Richard= From paul.hoffman@vpnc.org Sat Mar 10 07:39:32 2012 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 6634421F8621 for ; Sat, 10 Mar 2012 07:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.696 X-Spam-Level: X-Spam-Status: No, score=-102.696 tagged_above=-999 required=5 tests=[AWL=-0.097, 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 9ys-MJbr4p4f for ; Sat, 10 Mar 2012 07:39:32 -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 E788521F8613 for ; Sat, 10 Mar 2012 07:39:31 -0800 (PST) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2AFdTMJ056967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 10 Mar 2012 08:39:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <504075FB-AB95-46E2-B06B-508ED106EB39@bbn.com> Date: Sat, 10 Mar 2012 07:39:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2B08AB0F-81A3-4CC8-A632-9D757A7CDDE4@vpnc.org> References: <4F58DB47.4050701@nic.cz> <504075FB-AB95-46E2-B06B-508ED106EB39@bbn.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] Making certificate usage type 2 "CA-only"? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 15:39:32 -0000 It would *really* help Jakob and I if people who have opinions would = also post proposed text changes. I suspect it will help other people in = the WG as well... --Paul Hoffman From paul@nohats.ca Sat Mar 10 20:21:55 2012 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 4B2BF21F8633 for ; Sat, 10 Mar 2012 20:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.576 X-Spam-Level: X-Spam-Status: No, score=-0.576 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, 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 dYjXGA4ukPxE for ; Sat, 10 Mar 2012 20:21:54 -0800 (PST) Received: from letoams.cypherpunks.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 92C1E21F8631 for ; Sat, 10 Mar 2012 20:21:53 -0800 (PST) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 8B19D82449; Sat, 10 Mar 2012 23:21:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 7E7DF8198B; Sat, 10 Mar 2012 23:21:51 -0500 (EST) Date: Sat, 10 Mar 2012 23:21:51 -0500 (EST) From: Paul Wouters To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= In-Reply-To: <104DA3BC-FB05-447C-99C1-6D2C92B0B8AE@nic.cz> Message-ID: References: <201202292322.q1TNMIWD028275@new.toad.com> <104DA3BC-FB05-447C-99C1-6D2C92B0B8AE@nic.cz> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Cc: IETF DANE WG list Subject: Re: [dane] DNS Caching leftovers X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 04:21:55 -0000 On Fri, 9 Mar 2012, OndÅ™ej Surý wrote: > I would also suggest to remove text in parentheses in Section 4, paragraph 4, stripping it down to: > > An implementation of this protocol makes a DNS query for TLSA records, > validates these records using DNSSEC, and uses the resulting TLSA records > and validation status to modify its responses to the TLS server. modify its behaviour towards the TLS server? As it might decide not to respond at all, or not even initiate. Paul From wouter@nlnetlabs.nl Mon Mar 12 03:54:26 2012 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 49E8B21F8694 for ; Mon, 12 Mar 2012 03:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 1NZOf+mL9Z0z for ; Mon, 12 Mar 2012 03:54:25 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0961B21F8681 for ; Mon, 12 Mar 2012 03:54:24 -0700 (PDT) Received: from axiom.nlnetlabs.nl (axiom.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4d46]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q2CAsMrg017099 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 12 Mar 2012 11:54:23 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1331549664; bh=khiA0vO5AWGbed85+lBRdZF6HiULr/81wSvdm5o4Tss=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Jka3P3S9XCl20hgAzRrNitJEuCQVdLQmqlGME1RTan564ThwDQyFRVbItFrf5juZk p4VIHfWeDyGBCSbDeVs+PvWGvz3yyONm2pNSZrTRwg8i/TRwzcLLc/x4evpTM2hH4n 0PDfzicbJHdGLFHkRxX/5n1BOr0qxUB4UBZa2SEI= Message-ID: <4F5DD5DE.10705@nlnetlabs.nl> Date: Mon, 12 Mar 2012 11:54:22 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <4F58DB47.4050701@nic.cz> <504075FB-AB95-46E2-B06B-508ED106EB39@bbn.com> <2B08AB0F-81A3-4CC8-A632-9D757A7CDDE4@vpnc.org> In-Reply-To: <2B08AB0F-81A3-4CC8-A632-9D757A7CDDE4@vpnc.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 12 Mar 2012 11:54:23 +0100 (CET) Subject: Re: [dane] Making certificate usage type 2 "CA-only"? 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 Mar 2012 10:54:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/10/2012 04:39 PM, Paul Hoffman wrote: > It would *really* help Jakob and I if people who have opinions > would also post proposed text changes. I suspect it will help other > people in the WG as well... > This is what I understand from the text: Usetype 2. cert is trusted. PKIX path validation MUST be done. cert MAY be root-CA, intermediate-CA, EE-cert. Usetype 3. cert is trusted. PKIX path validation MUST NOT be done. cert MUST be the EE-cert. Thus, PKIX constraints on the cert in type 2. No PKIX constraints on the cert in type 3? (I mean the checks: if you do PKIX path validation with one certificate whose key is trusted, then there are still a number of additional checks, those checks I mean here.) If you use public keys, it is the same, from security perspective. Rereading, I am unsure if usetype 2, the PKIX Path MUST contain the cert from TLSA, or if it MAY contain the cert from TLSA. (usetype 1 is CA-constraint, this one 'adds a trust anchor you may not have'; so I think it 'may', but then 'a' was changed to 'the' in this text). So, this is a table with the spectrum of possibilities here (sorry for ascii art) header: Certis DoPKIXPath pathvalidation certMUST header2 pkixTA validation mustcontaincert equalEE usetype0: no yes yes no usetype1: no yes no yes usetype2: yes yes no no usetype3: no no no yes short comments on rows: usetype0: constrain CA-given (root/intermediate/EE) to X. usetype1: constrain CA-given EE to X usetype2: add trust-anchor X, do PKIX-validation. usetype3: fix EE to X, no PKIX stuff. short comments on columns: certisPKIXTA: does TLSA cert add a new PKIX trust anchor? DoPKIXPathvalidation: if the PKIX path validation must be passed. pathvalidationmustcontaincert: the valid pkix path must contain the TLSA cert. If no, this means pkix must load the trusted CAs list. certMUSTequalEE: TLSA must match EE. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPXdXeAAoJEJ9vHC1+BF+Nw7sP/19PZlF/EsUpJtjCwIvza3wf Vf3ocMI6uL9eua8X6V85PjVO2kr5knnq5y21JIzIP+EJrGVxm4mKIZh2qeCs7PDG tgNWWT2GsiqRDvaFc3OR5c2HqUMhXFeZ88rDylh2vVX9ljsutGD9+WrtUUEZOwNJ X8pAJkVTBnIsFbeSj68zADQoyZVzKs7Y8PEx/aaivnuxhM3hKLKIj7syE4KnE+rj /P7XlYgPW2TvozhxkXBunfmaWcQy2udzhQro8BmZ5mkTk6O5qtrVflnxuHqCV4sR KWsSfcMZiDgzvCyspohUdLvUM07PMptXjxSoFSoGvSIJITcDiPbZ/YFBuIJjf4cM MQQV179uMXijitOueKbdY7tZptAWF4zqqu2PIhLPFU42Z3hAvIZWz3apUIBeL7AT +tKbPnCqd7TFJabF5xSvtJAKkaBd0JcEAxkgYFZKIDq8jDHDSUX5yNGK3cMyMglu sMhKYA7zrjrBeyn2Nfjs6+TDrGYg5qVGv4fM6Bdvbumfq9k/CzusMbqF13QnnrQJ wnd7XlYH5Z0Y+4s/ite+uggJnqGhDe9PUDK8ffOiZR8/gvG1fCgEq2B3Wu8qQpvW OnzkytDCB46cu4fXYIGC87MQGfUsog0wp730Zpgzi4Qdr6OUOkduDIownzv5uOCW Sa69uLfZ2V/gG8CYIHRi =C9TL -----END PGP SIGNATURE----- From ondrej.mikle@nic.cz Mon Mar 12 04:44:42 2012 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 094B621F865A for ; Mon, 12 Mar 2012 04:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=0.929, 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 rTmZlAVdb6LY for ; Mon, 12 Mar 2012 04:44:41 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7F321F8655 for ; Mon, 12 Mar 2012 04:44:41 -0700 (PDT) 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 8D6F32A0082 for ; Mon, 12 Mar 2012 12:44:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1331552680; bh=irAKPulufpTr3p948I8MfQorI3YtlVlQylO27CA7CH0=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=UU92uBIfr/y1mr6Si1NiySp8cZ7v5Y19cBu5QzWUAf9EyylFbN0kDY3uiv6ul9OXr tO715Ybm7L/K6JnfZm/RxBSicEb+MzIt1I1b3UV8wkWEIySCQJVZNxrRxl4GwdxNoq xHVwmR5njiqjMdEx3UgT+54JS8gtYYGUhmazhrJo= Message-ID: <4F5DE15D.5060204@nic.cz> Date: Mon, 12 Mar 2012 12:43:25 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dane@ietf.org References: <4F58DB47.4050701@nic.cz> <504075FB-AB95-46E2-B06B-508ED106EB39@bbn.com> <2B08AB0F-81A3-4CC8-A632-9D757A7CDDE4@vpnc.org> <4F5DD5DE.10705@nlnetlabs.nl> In-Reply-To: <4F5DD5DE.10705@nlnetlabs.nl> X-Enigmail-Version: 1.3.5 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] Making certificate usage type 2 "CA-only"? 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 Mar 2012 11:44:42 -0000 On 03/12/2012 11:54 AM, W.C.A. Wijngaards wrote: > > Rereading, I am unsure if usetype 2, the PKIX Path MUST contain the > cert from TLSA, or if it MAY contain the cert from TLSA. (usetype 1 > is CA-constraint, this one 'adds a trust anchor you may not have'; so > I think it 'may', but then 'a' was changed to 'the' in this text). You're right, for usage type 2 the text does not specify whether the cert from TLSA MUST be in validation path (neither do older revisions like -17 and -16). Or possibly it's somehow implied (though I don't see how). So far I've understood it that it is required. Without the requirement of having the cert from TLSA in validation chain for usage 2 it would just add a TA, but wouldn't provide any constraint (meaning arbitrary PKIX-validated chain would be accepted). Thus I propose adding one sentence to section 2.1.1, at the end of paragraph covering "2 -- Certificate usage 2": "Certificate from TLSA record must be present in validation path in order for such association to succeed." Looking back at pseudocode in section B.2 from revision -14 I think that's how it was originally intended - part for usage type 2 reads "for each PKIX validation chain H that has R as the trust anchor". > header: Certis DoPKIXPath pathvalidation certMUST > header2 pkixTA validation mustcontaincert equalEE > > usetype0: no yes yes no > usetype1: no yes no yes > usetype2: yes yes no no > usetype3: no no no yes So in the table above "pathvalidation mustcontaincert" would have "yes" for "usetype2". I'd also argue that "pathvalidation mustcontaincert" should be "yes" for "usetype1" (such EE cert must be part of validation path). Ondrej From leifj@mnt.se Mon Mar 12 08:38:55 2012 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 02D6C21F8600 for ; Mon, 12 Mar 2012 08:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 s1Pu8qbbynYh for ; Mon, 12 Mar 2012 08:38:52 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 986BE21F8469 for ; Mon, 12 Mar 2012 08:38:51 -0700 (PDT) Received: from [10.0.1.91] (70-91-87-57-BusName-metrodr.md.hfc.comcastbusiness.net [70.91.87.57]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2CFckhH013801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Mar 2012 16:38:50 +0100 (CET) Message-ID: <4F5E1885.6020000@mnt.se> Date: Mon, 12 Mar 2012 16:38:45 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dane@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Draft -18 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 Mar 2012 15:38:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/09/2012 06:49 PM, Paul Hoffman wrote: > ... has everything Jakob and I believe we were instructed to do by > the chairs. The chairs will also decide what to do about the issue > under discussion with the definition of usage type 2, but we wanted > to get everyone a clean draft to look at. > I've reviewed -18. I find it good enough to publish. Let us please ship this version and move on to other stuff! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9eGIUACgkQ8Jx8FtbMZne7uQCaAw22MB8iVoZNI636DogOd+NN yMQAoJMh9ApCFccFij36OabhSEUZ6ATA =SrjH -----END PGP SIGNATURE----- From peter.sylvester@edelweb.fr Mon Mar 12 09:41:48 2012 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 1BC4721E8045 for ; Mon, 12 Mar 2012 09:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSBN5WQgSIG6 for ; Mon, 12 Mar 2012 09:41:47 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8E621E8020 for ; Mon, 12 Mar 2012 09:41:45 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 0C9317E47 for ; Mon, 12 Mar 2012 17:41:44 +0100 (CET) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 43A4D79727B for ; Mon, 12 Mar 2012 17:06:50 +0100 (CET) Received: from [192.168.18.180] (unknown [192.168.18.180]) by smtps.on-x.com (Postfix) with ESMTPSA id D0A7A236367 for ; Mon, 12 Mar 2012 12:39:41 -0400 (EDT) Message-ID: <4F5E2748.70807@edelweb.fr> Date: Mon, 12 Mar 2012 17:41:44 +0100 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dane@ietf.org References: <4F5E1885.6020000@mnt.se> In-Reply-To: <4F5E1885.6020000@mnt.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] Draft -18 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 Mar 2012 16:41:48 -0000 I have some comments on the wording of the introdcuctory sections: The abstract Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrator of a domain name to certify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. - There are other methods than certified public keys that can be used for mutual authentication combined with encryption key establishment. Wouldn't it be more correct to replace the first sentence in the abstract by something like "Encrypted communication on the Internet often uses Transport Level Security (TLS). Authentication in TLS, when based on certified public keys, often depends on third parties." The second: "Improving a situation" may sound like a judgement? Isn't it sufficient to state something like: "This document describes a method that enables an administrator of a domain name to certify the keys used in that domain's TLS servers." In the background between the two paragraphs The security properties of encryption systems depend strongly on the keys that they use. If secret keys are revealed, or if published keys can be replaced by bogus keys, these systems provide little or no security. TLS uses certificates to bind keys and names. there seems to be a gap? - Nothing is says why binding keys and names is related to publishing keys or whatever. - The paragraph before talks about encryption keys, in TLS the ones used for data encryption are not the ones that are certified. See proposal for the abstract and add something like: In order to establish a shared encryption key for data exchanges, TLS may use various methods, one consists of transporting such keys to the intended partner using encryption with public keys. This method requires that the public key is securely associated with some identity or name of the intended partner. TLS uses public key certificates ... In the sentence CCAs protect their secret key vigorously, while supplying their public key to the software vendors who build TLS clients. the first part could be removed I think and the second is not complete. They provide there root keys to anyone who wants them I guess. And they also supply their name. For convenience, the binding of a name is provided in general as a self signed certificate. TLS client software uses a set of these CA keys as "trust anchors" and the associated names. This solution has gradually broken down because some CAs have become untrustworthy. Untrustworthy for doing what? "to establish correct associations of names and keys." 1.2: A TLS client begins a connection by exchanging messages with a TLS server. It looks up the server's name using the DNS to get Internet Protocol (IP) address associated with the name. A client established a connection using an IP address. This IP address may have been obtained by using a DNS to resolve a name of the server. Well... The first response from the server in TLS may contain a certificate. Good. see above my remarks. Currently, the client must extract the domain name from the certificate The client must match the server name against the identities present in the certificat. regards Peter Sylvester From warren@kumari.net Mon Mar 12 13:47:04 2012 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 775F911E80F6; Mon, 12 Mar 2012 13:47:04 -0700 (PDT) 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 67cd4xMviLkC; Mon, 12 Mar 2012 13:47:03 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 66F7421F897D; Mon, 12 Mar 2012 13:47:02 -0700 (PDT) Received: from [10.196.208.139] (unknown [199.91.193.1]) by vimes.kumari.net (Postfix) with ESMTPSA id 8AFFE1B41B5B; Mon, 12 Mar 2012 16:47:01 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 14:47:00 -0600 Message-Id: <2ECA88E1-87EE-40C6-A177-5E996133DA48@kumari.net> To: iesg-secretary@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: [dane] Publication requested for draft-ietf-dane-protocol-18 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 Mar 2012 20:47:04 -0000 This is a publication request for = http://tools.ietf.org/html/draft-ietf-dane-protocol-18 Attached please find the Document Shepherd writeup. -------------------------------- (1) What type of RFC is being requested... This document is requested to be published as Proposed Standard. The title page header identifies: "Intended status: Standards Track". The description in RFC 2026 Section 4.1.1 (Proposed Standard) covers this draft, and so it is the correct "type". (2) The IESG approval announcement includes a Document Announcement Write-Up... Technical Summary Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrator of a domain name to publish the keys used in the=20 DNS, secured with DNSSEC. Working Group Summary The working group made extensive use of the issue tracker:=20 listing, opening, discussing and then calling consensus on each issue. This gave everyone the opportunity to participate and be heard. There have been approximately 2,000 messages=20 discussing this (and closely related) documents. Document Quality There is a tool (Swede - https://github.com/pieterlexis/swede) that generates TLSA records, and a proof-of-concept implementation of DANE for NSS (https://mattmccutchen.net/cryptid/#nss-dane). A number of vendors have mentioned that they are planning on=20 implementing the specification. I do not think that it would be fair (or possible) to single out any specific reviewers -- we have had a large number of very active reviewers / participants and they have all been very diligent (and sometimes vocal :-)) in providing feedback. Personnel Warren Kumari is acting as the Document Shepherd.=20 Stephen Farrell is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd is also one of the WG Co-chairs, and has been involved in reviewing, calling consensus, etc. He has reviewed the document and believes that it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?=20 No. This document has received lots of review. We have been fortunate in having folk from many other working groups participating, and believe that we are good for both breadth and depth. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. This document requests a new DNS RR type (TLSA). A request for expert review for the RRTYPE has been submitted. http://www.ietf.org/mail-archive/web/dnsext/current/msg12303.html (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?=20 None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes -- authors have been polled and state that they have no IPR to disclose. =20 (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed (yay!). (9) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? =20= In the chairs opinion there is strong to very strong consensus. As with any complex document that has had a lot of discussion, a number of folk have points that they are not 100% happy with. These points don't=20= overlap very much though. =20 (10) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)=20 (11) Identify any ID nits the Document Shepherd has found in this document... ID Nits found 1 nit: Missing Reference: 'This' is mentioned on line 654, but not defined This is *not* an issue, it is simply a reference to this document (but mentioned for completeness). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. It meets the requirements by not having any! (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement... No. (15) Are there downward normative references references... No. (16) Will publication of this document change the status of any existing RFCs? No. (17) Describe the Document Shepherd's review of the IANA considerations section, ... The document creates 3 new registries. They clearly state the requirements to get an allocation, contain a clear list of the current allocations, and have reasonable names. (18) List any new IANA registries that require Expert Review... None. (19) No formal language. --------------------------------------------------- -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From stephen.farrell@cs.tcd.ie Mon Mar 12 13:58:26 2012 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 23EF721F8A17 for ; Mon, 12 Mar 2012 13:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoVxOxkOJ2E9 for ; Mon, 12 Mar 2012 13:58:25 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8A821F8A16 for ; Mon, 12 Mar 2012 13:58:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 9A52D171C8D; Mon, 12 Mar 2012 20:58:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1331585903; bh=2aAN/Hz7JVkjuD Mg33+DSaj8sdkkn3ee+Iu7aFyj/J4=; b=K5qcWbgBjtvBlzFkGbnRYJwhwmlk0z xPbF0Ksg4HRWgQxtKx+HExiha8CZzTTO4gkg4JUVFv6YHkWT5NFRSXxlYW4EOgl1 lEIsFj3uQBBcovO+Pe5emtHcTpl+viH+R3jCe+BsTFO8ccTNmRranuLkWZ+354W2 U7+lF+WLLdrgcA9fm+lIFQNSVcXDKsBrvqGFxhPiPw1xahGF2kYtImHZLt2EOXkK yhv6syRjhgqZUQKx1lALS9aWMEFM7Tg5kmtlpv+CpqXe3mD5/9JxQA08UgPPe/dA 9kDnAGajbNdjKua7XFTZ1GuwJyYJxKjjoGAfMCvV0JEBUuRf8kfg380A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id s1hk2FgUX3kr; Mon, 12 Mar 2012 20:58:23 +0000 (GMT) Received: from [10.228.107.24] (unknown [194.230.159.88]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 1D9EB171C8C; Mon, 12 Mar 2012 20:58:19 +0000 (GMT) Message-ID: <4F5E6367.2050800@cs.tcd.ie> Date: Mon, 12 Mar 2012 20:58:15 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Warren Kumari References: <2ECA88E1-87EE-40C6-A177-5E996133DA48@kumari.net> In-Reply-To: <2ECA88E1-87EE-40C6-A177-5E996133DA48@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF DANE WG list Subject: Re: [dane] Publication requested for draft-ietf-dane-protocol-18 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 Mar 2012 20:58:26 -0000 Thanks folks, I'll do the AD-review thing in the next few days. S On 03/12/2012 08:47 PM, Warren Kumari wrote: > This is a publication request for http://tools.ietf.org/html/draft-ietf-dane-protocol-18 > > Attached please find the Document Shepherd writeup. > > > -------------------------------- > (1) What type of RFC is being requested... > > > This document is requested to be published as Proposed Standard. > The title page header identifies: "Intended status: Standards Track". > The description in RFC 2026 Section 4.1.1 (Proposed Standard) covers > this draft, and so it is the correct "type". > > (2) The IESG approval announcement includes a Document Announcement > Write-Up... > > Technical Summary > > Encrypted communication on the Internet often uses Transport Level > Security (TLS), which depends on third parties to certify the keys > used. This document improves on that situation by enabling the > administrator of a domain name to publish the keys used in the > DNS, secured with DNSSEC. > > > Working Group Summary > > The working group made extensive use of the issue tracker: > listing, opening, discussing and then calling consensus on > each issue. This gave everyone the opportunity to participate > and be heard. There have been approximately 2,000 messages > discussing this (and closely related) documents. > > Document Quality > > There is a tool (Swede - https://github.com/pieterlexis/swede) > that generates TLSA records, and a proof-of-concept implementation > of DANE for NSS (https://mattmccutchen.net/cryptid/#nss-dane). > A number of vendors have mentioned that they are planning on > implementing the specification. > > I do not think that it would be fair (or possible) to single > out any specific reviewers -- we have had a large number of very > active reviewers / participants and they have all been very diligent > (and sometimes vocal :-)) in providing feedback. > > Personnel > > Warren Kumari is acting as the Document Shepherd. > Stephen Farrell is the Responsible Area Director. > > (3) Briefly describe the review of this document that was performed by > the Document Shepherd. If this version of the document is not ready > for publication, please explain why the document is being forwarded to > the IESG. > > The Document Shepherd is also one of the WG Co-chairs, and has been > involved in reviewing, calling consensus, etc. He has reviewed the > document and believes that it is ready for publication. > > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? > > No. This document has received lots of review. We have been > fortunate in having folk from many other working groups participating, > and believe that we are good for both breadth and depth. > > > (5) Do portions of the document need review from a particular or from > broader perspective, e.g., security, operational complexity, AAA, DNS, > DHCP, XML, or internationalization? If so, describe the review that > took place. > > This document requests a new DNS RR type (TLSA). A > request for expert review for the RRTYPE has been submitted. > http://www.ietf.org/mail-archive/web/dnsext/current/msg12303.html > > > (6) Describe any specific concerns or issues that the Document Shepherd > has with this document that the Responsible Area Director and/or the > IESG should be aware of? > > None. > > > (7) Has each author confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP 78 > and BCP 79 have already been filed. If not, explain why. > > Yes -- authors have been polled and state that they have no IPR to > disclose. > > (8) Has an IPR disclosure been filed that references this document? > If so, summarize any WG discussion and conclusion regarding the IPR > disclosures. > > No IPR disclosures have been filed (yay!). > > > (9) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with it? > > In the chairs opinion there is strong to very strong consensus. As > with any complex document that has had a lot of discussion, a number of > folk have points that they are not 100% happy with. These points don't > overlap very much though. > > > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in separate > email messages to the Responsible Area Director. (It should be in a > separate email because this questionnaire is publicly available.) > > (11) Identify any ID nits the Document Shepherd has found in this > document... > > ID Nits found 1 nit: > Missing Reference: 'This' is mentioned on line 654, but not defined > > This is *not* an issue, it is simply a reference to this document (but > mentioned for completeness). > > (12) Describe how the document meets any required formal review > criteria, such as the MIB Doctor, media type, and URI type reviews. > > It meets the requirements by not having any! > > (13) Have all references within this document been identified as > either normative or informative? > > Yes. > > (14) Are there normative references to documents that are not ready for > advancement... > > No. > > > (15) Are there downward normative references references... > > No. > > > (16) Will publication of this document change the status of any > existing RFCs? > > No. > > (17) Describe the Document Shepherd's review of the IANA considerations > section, ... > > The document creates 3 new registries. They clearly state the > requirements to get an allocation, contain a clear list of the current > allocations, and have reasonable names. > > > (18) List any new IANA registries that require Expert Review... > > None. > > > (19) No formal language. > > > --------------------------------------------------- > > > -- > Don't be impressed with unintelligible stuff said condescendingly. > -- Radia Perlman. > > > > > > From cloos@jhcloos.com Mon Mar 12 14:35:44 2012 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 7A0E721F89EC for ; Mon, 12 Mar 2012 14:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.372, 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 iq3d98WMb6mW for ; Mon, 12 Mar 2012 14:35:43 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id BE2CC21F895C for ; Mon, 12 Mar 2012 14:35:43 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id A521640107; Mon, 12 Mar 2012 21:35:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1331588142; bh=3BebVBt0F38QgPGyB6jKcaOsAcOoiRS2RL0f6UeXbfk=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=Ru3PBZnl53o163Jf0jnsL4XX51LS32flaabRvKaXBffRDDrcckK5gWgFCQ5MzWUYL 1HicPDYrYbtyw4J9wPxRZdE0/rsLueDQU+ps0v2PhYsrXNZ+AdR3iycmQlmSkKjm9B ZJ0jtRpekMzJPiOx5NArvGHwW0aqer+Nqq3Liv7Q= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 6D63A36004E; Mon, 12 Mar 2012 21:34:59 +0000 (UTC) From: James Cloos To: dane@ietf.org User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 12 Mar 2012 17:34:59 -0400 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120312:dane@ietf.org::ZN9RSXeOQdCu7AIL:00035D1R Subject: [dane] TLSA RRTYPE allocation? 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 Mar 2012 21:35:44 -0000 Has the request for an RRTYPE allocation for TLSA been made? If not, can we get it done before the end of the wg last call? It can take quite a while to get support into the server versions which are included in the major distributions. Getting the final rrtype into the servers' src asap could make a huge difference in when anyone can start relying on TLSA. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From paul.hoffman@vpnc.org Mon Mar 12 14:40:52 2012 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 9639711E816B for ; Mon, 12 Mar 2012 14:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.694 X-Spam-Level: X-Spam-Status: No, score=-102.694 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 to+dD8mwR8yU for ; Mon, 12 Mar 2012 14:40:52 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E35BD11E816A for ; Mon, 12 Mar 2012 14:40:51 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2CLeo5P057400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Mar 2012 14:40:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 12 Mar 2012 14:40:50 -0700 Content-Transfer-Encoding: 7bit Message-Id: <5EBEBAC0-6351-4655-ACB2-226B74BDA784@vpnc.org> References: To: James Cloos X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] TLSA RRTYPE allocation? 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 Mar 2012 21:40:52 -0000 On Mar 12, 2012, at 2:34 PM, James Cloos wrote: > Has the request for an RRTYPE allocation for TLSA been made? Warren just sent it in a few hours ago. --Paul Hoffman From cloos@jhcloos.com Mon Mar 12 16:15:08 2012 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 D1C2D21E8025 for ; Mon, 12 Mar 2012 16:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.363, 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 eXepYjrw8iNm for ; Mon, 12 Mar 2012 16:15:07 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id CBBE021F8A9D for ; Mon, 12 Mar 2012 16:14:59 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 3C7B0401B9; Mon, 12 Mar 2012 23:14:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1331594099; bh=RQwCxYbSiPnl2H6idS9n4cYDIfqGa3PtBLWbibY+LTU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=H/WCdn4T6MaB3rDPHr9SvyRwaiGzaBuo83FhJr4ucmJeTkniemPbAzN7JtycRyxhi kInkz7bWTOBPwtehZuswLnfJOzcymv16f3LjWBwCPxrJxglWhQaDh0fIZlwgQNUPLw s9Zk2PratzeU3zurcknaBB9z9ibi3Dte1oqIISSk= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 95D6B36004D; Mon, 12 Mar 2012 23:12:42 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <5EBEBAC0-6351-4655-ACB2-226B74BDA784@vpnc.org> (Paul Hoffman's message of "Mon, 12 Mar 2012 14:40:50 -0700") References: <5EBEBAC0-6351-4655-ACB2-226B74BDA784@vpnc.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 12 Mar 2012 19:12:42 -0400 Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:120312:dane@ietf.org::dWY2XnkCWy1P4waK:000WvpRS X-Hashcash: 1:30:120312:paul.hoffman@vpnc.org::tRIIIahMN1J0/6fL:0000000000000000000000000000000000000009Jt8r Cc: Paul Hoffman Subject: Re: [dane] TLSA RRTYPE allocation? 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 Mar 2012 23:15:08 -0000 >>>>> "PH" == Paul Hoffman writes: JC> Has the request for an RRTYPE allocation for TLSA been made? PH> Warren just sent it in a few hours ago. Très bien. Dank. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From warren@kumari.net Mon Mar 12 21:56:32 2012 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 9DE4921F881B for ; Mon, 12 Mar 2012 21:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 dRHp1QOyjtQi for ; Mon, 12 Mar 2012 21:56:30 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 975E921F881A for ; Mon, 12 Mar 2012 21:56:30 -0700 (PDT) Received: from [192.168.1.3] (unknown [201.204.76.162]) by vimes.kumari.net (Postfix) with ESMTPSA id B7DC01B407FB; Tue, 13 Mar 2012 00:56:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Warren Kumari In-Reply-To: Date: Mon, 12 Mar 2012 22:56:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5EBEBAC0-6351-4655-ACB2-226B74BDA784@vpnc.org> To: James Cloos X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] TLSA RRTYPE allocation? 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 Mar 2012 04:56:32 -0000 On Mar 12, 2012, at 5:12 PM, James Cloos wrote: >>>>>> "PH" =3D=3D Paul Hoffman writes: >=20 > JC> Has the request for an RRTYPE allocation for TLSA been made? >=20 > PH> Warren just sent it in a few hours ago. And, just for completeness, here is the 3 week review notice on DNSEXT: http://www.ietf.org/mail-archive/web/dnsext/current/msg12317.html W >=20 > Tr=E8s bien. >=20 > Dank. >=20 > -JimC > --=20 > James Cloos OpenPGP: 1024D/ED7DAEA6 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From mrex@sap.com Tue Mar 13 18:57:27 2012 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 68B7E21F84BD for ; Tue, 13 Mar 2012 18:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.451 X-Spam-Level: X-Spam-Status: No, score=-9.451 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=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 EqTtiGd3j8Mi for ; Tue, 13 Mar 2012 18:57:27 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A86BA21F84B6 for ; Tue, 13 Mar 2012 18:57:26 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q2E1vJoT013149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Mar 2012 02:57:24 +0100 (MET) From: Martin Rex Message-Id: <201203140157.q2E1vJvH029202@fs4113.wdf.sap.corp> To: wouter@nlnetlabs.nl (W.C.A. Wijngaards) Date: Wed, 14 Mar 2012 02:57:19 +0100 (MET) In-Reply-To: <4F5DD5DE.10705@nlnetlabs.nl> from "W.C.A. Wijngaards" at Mar 12, 12 11:54:22 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] Making certificate usage type 2 "CA-only"? 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: Wed, 14 Mar 2012 01:57:27 -0000 W.C.A. Wijngaards wrote: > > So, this is a table with the spectrum of possibilities here (sorry for > ascii art) > > header: Certis DoPKIXPath pathvalidation certMUST > header2 pkixTA validation mustcontaincert equalEE > > usetype0: no yes yes no > usetype1: no yes no yes > usetype2: yes yes no no > usetype3: no no no yes usetype3: no no no DON'T CARE There should *NOT* be any change on the certificate about whether it looks like an EE cert or not for usatype3. It could be an X.509v1 self-signed cert, and X.509v3 cert with BasicConstraints cA=TRUE or an X.509v3 cert with BasicConstraints cA=FALSE -- all of these are in widespread use (and which one is created depends on the PKI toolkit). -Martin From simon@arlott.org Mon Mar 19 14:27:49 2012 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 E845F21E803F for ; Mon, 19 Mar 2012 14:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_43=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnVYN6aJ1ewf for ; Mon, 19 Mar 2012 14:27:49 -0700 (PDT) Received: from proxima.lp0.eu (proxima.lp0.eu [IPv6:2001:8b0:ffea:0:205:b4ff:fe12:530]) by ietfa.amsl.com (Postfix) with ESMTP id 03BBF21E803E for ; Mon, 19 Mar 2012 14:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=arlott.org; s=exim; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=UAq2A5RrYWvmcBjsdduQ3iR5a5dl3iyZom9spxvHwUM=; b=VMTnGIf6Jn1XyHht7SOka+o3sEqcTy5ncbxEKG08ds7rIfYi7d4Npg9wNpwrVZCw79RVGJbxjf8DuWzpJUMZ2h745sFBGLOW0Tr4+5FGSfOI5vf+pBitYjMbJCKfzp74; Received: from redrum.lp0.eu ([2001:8b0:ffea:0:2e0:81ff:fe4d:2bec]:37962 ident=simon) by proxima.lp0.eu ([2001:8b0:ffea:0:205:b4ff:fe12:530]:465) with esmtpsav (TLSv1:CAMELLIA256-SHA:256/CN=Simon Arlott) id 1S9k7D-0000gH-Lu; Mon, 19 Mar 2012 21:27:44 +0000 Message-ID: <4F67A4CF.1080106@simon.arlott.org.uk> Date: Mon, 19 Mar 2012 21:27:43 +0000 From: Simon Arlott User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110823 Thunderbird/5.0 MIME-Version: 1.0 To: IETF DANE WG list References: <201202132324.q1DNOVWD009987@new.toad.com> <5cb76a8f-e2e8-4865-bab2-c131c25b6a72@email.android.com> <849C2DF1-C68B-42FB-AA4A-2E26E1B932AC@nic.cz> <4F48AC0F.4050600@os3.nl> <20120225113748.GA3851@LK-Perkele-VI.localdomain> In-Reply-To: <20120225113748.GA3851@LK-Perkele-VI.localdomain> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010200020001020500090606" Cc: paul.hoffman@vpnc.org Subject: Re: [dane] Hash specs, and examples in sec. 2.3 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 Mar 2012 21:27:50 -0000 This is a cryptographically signed message in MIME format. --------------ms010200020001020500090606 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 25/02/12 11:37, Ilari Liusvaara wrote: > On Sat, Feb 25, 2012 at 10:38:23AM +0100, Pieter Lexis wrote: >=20 > Did some verification on these. >=20 >> These record were created using swede, so don't use it to verify the >> correctness of them :). >=20 > Well, I used some custom tool (hex to binary converter), sha256sum, > sha512sum and dumpasn1. I've checked the example in draft 18 using python unhexlify, and the certificate looks ok to me. I get the same SHA256/512 hashes (after removing the extra \n from my decoded output, which openssl doesn't complain about). $ sha256sum cert.der efddf0d915c7bdc5782c0881e1b2a95ad099fbdd06d7b1f77982d9364338d955 cert.de= r I also get the same subject public key info: $ openssl x509 -pubkey -inform DER -in cert.der | openssl rsa -pubin | \ head -n -1 | tail -n +2 | base64 -d > subj2.der writing RSA key $ sha256sum subj.der subj2.der=20 8755cdaa8fe24ef16cc0f2c918063185e433faaf1415664911d9e30a924138c4 subj.de= r 8755cdaa8fe24ef16cc0f2c918063185e433faaf1415664911d9e30a924138c4 subj2.d= er The content is the same as the SubjectPublicKeyInfo in the certificate: $ openssl asn1parse -inform DER -in cert.der -i 286:d=3D2 hl=3D4 l=3D 418 cons: SEQUENCE =20 290:d=3D3 hl=3D2 l=3D 13 cons: SEQUENCE =20 292:d=3D4 hl=3D2 l=3D 9 prim: OBJECT :rsaEncryption 303:d=3D4 hl=3D2 l=3D 0 prim: NULL =20 305:d=3D3 hl=3D4 l=3D 399 prim: BIT STRING =20 $ openssl asn1parse -inform DER -in subj.der -i 0:d=3D0 hl=3D4 l=3D 418 cons: SEQUENCE =20 4:d=3D1 hl=3D2 l=3D 13 cons: SEQUENCE =20 6:d=3D2 hl=3D2 l=3D 9 prim: OBJECT :rsaEncryption 17:d=3D2 hl=3D2 l=3D 0 prim: NULL =20 19:d=3D1 hl=3D4 l=3D 399 prim: BIT STRING and it matches the RFC3280 definition: SubjectPublicKeyInfo ::=3D SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } AlgorithmIdentifier ::=3D SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } However, the "parameters" value is optional. I can remove the NULL and the "openssl rsa" command still parses it ok. RFC3280 6.1.4 appears to allow this: If the subjectPublicKeyInfo field of the certificate contains an algorithm field with null parameters or parameters are omitted, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Would it be necessary to make it clear that the SubjectPublicKeyInfo raw data must be the ASN.1 SEQUENCE extracted from the certificate, and not a reconstructed equivalent form? $ openssl asn1parse -inform DER -in subj3.der -i 0:d=3D0 hl=3D4 l=3D 416 cons: SEQUENCE =20 4:d=3D1 hl=3D2 l=3D 11 cons: SEQUENCE =20 6:d=3D2 hl=3D2 l=3D 9 prim: OBJECT :rsaEncryption 17:d=3D1 hl=3D4 l=3D 399 prim: BIT STRING --=20 Simon Arlott --------------ms010200020001020500090606 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFLzCC BSswggMToAMCAQICAwonrjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTA0 MjkxOTM0MzBaFw0xMzA0MjgxOTM0MzBaMDgxFTATBgNVBAMTDFNpbW9uIEFybG90dDEfMB0G CSqGSIb3DQEJARYQc2ltb25AYXJsb3R0Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALIIK63ZkK5EhTZGUa5tevs/o/KTweoehTe9btmhWX7X4xce1TG6f14ofHL9VHR2 ID1qmau8phtyiu+B2XtFf5Ac8PdKPlsWT9qfkF9IC98rdY9b6v/uqyMRU4ADnFS8NmRI4QlZ JfFVynjpIJ4GOQxmbo5WHpDmfhxY5uDZPPbLaDniFQIh2Fc0vt7lqXAXuXKsB08uEzaidrEp 2qimmzY5QMc51ZEHtIyIujEDWYnldwNX/9rKzLoyQikR6707y5nI0fTkIfLbuQsjS1D8NKSU RZEhO6DszajpKy4CpePnADo5xiEroNLhbEtWfIX2A0EBtxQD252+Pa7U3XMCvGECAwEAAaOB /DCB+TAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2Vy dGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzBA BgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMG CWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNh Y2VydC5vcmcwGwYDVR0RBBQwEoEQc2ltb25AYXJsb3R0Lm9yZzANBgkqhkiG9w0BAQUFAAOC AgEAG2JdvUFhtFS9RHT96gGjDIqcL2ftYZEbkt1e16xw5RBbzi0QIzaITptxPQMufsvdgQnm nZrPXDW9MdFvxpsVJlkB4aOK9mhfTkQ+67H+8lM5GQzR6SZjepc9H+rlgr+b0hRkqtQTDJOq ebUzAWEacphSr0Ywa+/8jQExX7qQxudYlOA01raQUABsa/CqJG4ZfOnA/OkBWcB+i4wSetjW WAqM1eclAFvfpJqfMwbQ5K8Jpeq0vj+7HvpH0NfK5BqP/bhBP83Lxa7+Vd+AqtvXoPa7SGZL 8O0zcCUCra8PUYZSv8W8hRcSwFJdNXCQVmkpapgi2+3u0dxLNpsbK3czEEReDpVX36DZoLCD 2Ta1QawKKRPLK2lWsKipa3rrC1F3P+16a5NJQcOLV7T8/TIP7JYdH4OkLvj3JIz1z72yQEVD wAaEKMoAstA6m18DpH3IlBU7cFDcqiMEHRtLqLreGPsGFHTahnJqPddnSazUFMfkw/FLnFrE 3EMijz6eiVHu5DO9z/9osc0d8Qxsh9Wml7jMC2+kTr2zZKk+YNnTkWRiqaR7aHGFlDw1SoaJ +RDY8LCeeVh/XfA+hNC4/+gmYYkxKK91Kwwgbd1UZciabJrzR/fo7PS45ie0zrSFZNQCQ0q5 j1dc+mDlVJUPq8/AIkNZbxK8sJ/1ltjGm7PxeSkxggOUMIIDkAIBATCBgDB5MRAwDgYDVQQK EwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNB IENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0 Lm9yZwIDCieuMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMDMxOTIxMjc0M1owIwYJKoZIhvcNAQkEMRYEFBctaQMRWYtkCBlf rWomykeIMGL9MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB kQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMKJ64wgZMGCyqGSIb3DQEJEAIL MYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0 Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJ ARYSc3VwcG9ydEBjYWNlcnQub3JnAgMKJ64wDQYJKoZIhvcNAQEBBQAEggEAdt/Mrmvo6juQ 8fRVjAQZ3fEHleM/Z5TfTywokhWzBCSoTtphKneT43oy7XvVUu1xq5qy72XnIudcoCGSCR+D l2uSvKXQLPIc16eZhO29MANfVyP/4xuM3kiAMUasQWAF8ujt1AOwqaOvdaivlox7uvPqfaEu lG5ND3f7YXjzCSKF3cf9d974qflmL/1urXE/c99Kg4erPPvJN1yl9Q6PuVVitTlMSdSn5iC6 HSqJHJUWs1tc+PkbgkO8FZqi7FEo50g0jj11yoCKfYZynmBowaP4xrbEdb1+K6+DNduJv10L AtdDqlyoO9c9Ey31DpBkSMRu9L74vi1wkfbuyraeQwAAAAAAAA== --------------ms010200020001020500090606-- From paul.hoffman@vpnc.org Mon Mar 19 17:36:58 2012 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 C1A4A21F88D5 for ; Mon, 19 Mar 2012 17:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.681 X-Spam-Level: X-Spam-Status: No, score=-102.681 tagged_above=-999 required=5 tests=[AWL=-0.082, 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 NAd87sHiHxv3 for ; Mon, 19 Mar 2012 17:36:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6040721F88D4 for ; Mon, 19 Mar 2012 17:36:58 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2K0ag1Z085418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2012 17:36:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F67A4CF.1080106@simon.arlott.org.uk> Date: Mon, 19 Mar 2012 17:36:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <78D57B2D-7DC1-445C-974D-0C134EE8DC92@vpnc.org> References: <201202132324.q1DNOVWD009987@new.toad.com> <5cb76a8f-e2e8-4865-bab2-c131c25b6a72@email.android.com> <849C2DF1-C68B-42FB-AA4A-2E26E1B932AC@nic.cz> <4F48AC0F.4050600@os3.nl> <20120225113748.GA3851@LK-Perkele-VI.localdomain> <4F67A4CF.1080106@simon.arlott.org.uk> To: Simon Arlott X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Hash specs, and examples in sec. 2.3 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 Mar 2012 00:36:58 -0000 On Mar 19, 2012, at 2:27 PM, Simon Arlott wrote: > Would it be necessary to make it clear that the SubjectPublicKeyInfo > raw data must be the ASN.1 SEQUENCE extracted from the certificate, = and > not a reconstructed equivalent form? That's a false dichotomy. You cannot reconstruct an "equivalent form" = for anything that has optional parameters. --Paul Hoffman From stephen.farrell@cs.tcd.ie Tue Mar 20 05:28:44 2012 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 9555421F85E0 for ; Tue, 20 Mar 2012 05:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LIST=2.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 Paf2y7TxCO4s for ; Tue, 20 Mar 2012 05:28:25 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD4421F8643 for ; Tue, 20 Mar 2012 05:28:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A504E153B68 for ; Tue, 20 Mar 2012 12:28:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1332246504; bh=A8IWIpTDdJS4Kirn0PM71ZqS rS2YNF0nj4I2WP94AHg=; b=TthgDhbPdh8RbpGHitk6mtxe/JYtCzRlLczGjAkY QeGQvYJ0ptzVuxQ2+xQKNkvaOTO4u95df5fgReV93KD3+KNqJoJMxbEA/6ENPTD4 87SZ42aY4soQqEWBYy1KsfNoFbnLYxuKRvlSQpwABUA1Iw+EA6gKTDmHLSd+DepN 61tWXJ51mjSOlS1eFhbsfZb6R8VP84nngjsAxkQDywOdeLwqans+LLkBAyy5Yzzk UJBsGz5aXWhVlVxlgvfvXz3JfpMZ/WJ9LbbQwlK5m0+HzcFX+sYiEm60FkHepifs vC1ZHnNTwABoYXMKwH8gc2FKdjb8OTK6F0/yb6qIwV95pQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id PyKfyIKfTB0s for ; Tue, 20 Mar 2012 12:28:24 +0000 (GMT) Received: from [10.87.48.7] (unknown [86.44.79.158]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0D108153B66 for ; Tue, 20 Mar 2012 12:28:24 +0000 (GMT) Message-ID: <4F6877E7.5030905@cs.tcd.ie> Date: Tue, 20 Mar 2012 12:28:23 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dane Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dane] AD review of draft-ietf-dane-protocol-18 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 Mar 2012 12:28:44 -0000 Hi all, First, good job all! My AD review is below. I've a number of questions and a bunch of nitty comments. The latter are ok to handle before, during or after IETF LC as the WG prefer, but I'd like to see answers to the former before starting IETF LC. Note: I'm not saying I'm insisting on any particular answer for any of those questions, I just want to check whether the WG are ok with -18 or want some change for those. Cheers, S. Questions to which I'd like to see answers: 1. What does this, in 1.3, mean? "This document does not specify how DNSSEC validation occurs because there are many different proposals for how a client might get validated DNSSEC results." We've just said that DNSSEC signatures MUST be validated and referenced DNSSEC RFCs, so what "different proposals" do you mean and why have they no references? 2. Is usage 0 clear enough? For example, a CA cert that's not a trust anchor will have a basicConstraints extension with cA set, but a trust anchor need not have that, so should usage 0 mean "CA certificate or trust anchor" or is it just worth noting that the associated certificate in this usage can be either? 3. In another context the fact that sha-384 is part of the US' suite-B (see e.g. RFC 5430) was brought up recently. Should there be a code-point for sha-384? I don't care, but I don't recall if that was considered in the WG discussion. 4. 2.1.4 says nothing about the length of this field. Although that can be figured out in all cases either because its fixed or because its specified in the DER encoding of a full cert or SPKI, I wonder would all readers know that. Could be well worth adding a bit of text about that, even though I can't think of a way to get that wrong that wouldn't be immediately obvious. 5. If the PKI underlying TLS has fallen into disrepute, (as -18 says) how is it that a DANE-client chosen validator to which DNSSEC has been offloaded will be any better since that validator can be as disreputable as a PKI with the same effects? Arguably, allowing a DANE client to depend on such a beast is worse that the current PKI, since the chances we'll hear about a hacked validator are much lower than for a higher profile CA. (I don't have a concrete suggestion here other than to really require DNSSEC at the DANE client, but I do want to see an answer to the question above.) 6. Section 4, last para: if the application gets N usable certificate associations, none of which match the TLS server then what? Should the client treat that like zero received (i.e. continue normal TLS) or like one bogus TLSA record, which'd mean barfing the TLS handshake? 7. Section 8, 2nd para - usage #3 is particularly vulnerable here right? I think that'd be worth calling out, or am I wrong? Misc. comments, all ok to handle as part of IETF LC: - abstract: why doesn't this say that we're putting public keys or hashes thereof in the DNS? - abstract: is is ok to say "...enabling the administrator of a domain name to certify the keys..."? Would it be better to say "...enabling the administrators of domain names to specify the keys..."? - 1.1, 1st para maybe s/privacy/security/ - 1.1, 2nd para maybe s/published/public/ - 1.1, 5th para, I don't think "broken down" is right here, better would be to say something like "Real problems have become apparent because some CAs have become untrustworthy." Reason to change is that PKI is arguably not broken, depending how you interpret the term PKI, so better to say something correct and less controversial - 1.1, 5th para, a bad CA doesn't compromise "any other certificate" but rather the name-public key binding. (The presumably pre-existing good certificate is still the same and not compromised.) - 1.1, 5th para, I don't think the entire CA model is considered disreputable, but mainly the fact that any CA can issue for any web site, so maybe s/brought/brought aspects of/ - 1.2, 1st para, typo, s/get Internet/get an Internet/ - 1.2, 4th para, 2nd sentence needs fixing. - 1.3, 1st para, a trust anchor doesn't identify a certificate, maybe just delete the mention of anchors in the parenthesis and then add a sentence that a trust anchor plus a domain name can also be a certificate association. - 1.3, 1st para says a DNS query can return >1 association which is fine but with the port-specific queries used here is there really a case where different server s/w might be listening on the same port? I guess there might be but it seems too much of a corner case. That's not a corner case for queries on different ports of course, so that example may be misleading. - 1.3 already has 2119 language before 1.4 introduces that, maybe best to move 1.4 earlier - 2.1, The term selector is already used related to public keys and DNS by DKIM. Not sure its worth changing this or even adding a sentence saying this is different from the DKIM case, but the editors/WG might want to think about it. - 2.1.1, Usage 1: are there any corner cases where a CA cert can be used with this usage? I suspect not. Would it be worth saying that explicitly as well? - 2.1.3, The SHOULD says "use the same hash." There are lots of rsaWithSHA1 certs out there, but there's no SHA-1 matching field. Is that an example of when the matching type and cert signature is not going to be the same function. Worth a mention? - 2.3 has the "_443._tcp" parts in the DNS names but the handling of ports and protocols weren't mentioned so far, maybe worth adding something in the intro so the reader gets this more easily or move the examples later? - section 4, 3rd para, is "run under TLS" right? Normally we'd say "HTTP over TLS" not under. - Section 4, 5th para, is it really "a host" that "uses" TLSA records? Probably doesn't matter but maybe administrator (who chooses or uses) could be kept distinct from the host (that does the TLS handshake). - section 4: Can a DANE client that uses a validator, e.g. via IPsec, ever get a bogus validation state? Does that need a mention? - section 5 could be made into an appendix easily and would disrupt the flow less that way maybe - section 8, 2nd para, maybe s/issued anyway/issued by some CA anyway/ might be better - section 8, do we have a reference for SSL proxies that's not just a product data sheet? Be nice to add if it exists. (I doubt it'll be an RFC, but I'd bet there's a paper to be found on the topic.) - A1.1, s/from original chain/from the original chain/ - A2.1.3, how would that interact with certificate content? It'd be good to note that the cert in that TLSA record can't usefully be a wildcard cert for *.example.com maybe. From paul.hoffman@vpnc.org Tue Mar 20 06:47:59 2012 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 ADDE021F8693 for ; Tue, 20 Mar 2012 06:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.68 X-Spam-Level: X-Spam-Status: No, score=-102.68 tagged_above=-999 required=5 tests=[AWL=-0.081, 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 MgjPV3X9Isey for ; Tue, 20 Mar 2012 06:47:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EA06721F867A for ; Tue, 20 Mar 2012 06:47:58 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2KDljD5012853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Mar 2012 06:47:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F6877E7.5030905@cs.tcd.ie> Date: Tue, 20 Mar 2012 06:47:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F6877E7.5030905@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1257) Cc: dane Subject: Re: [dane] AD review of draft-ietf-dane-protocol-18 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 Mar 2012 13:47:59 -0000 Given that the questions are wide-ranging, and Jakob and I are going to = need clear guidance if the answers lead to changes, I'm going to = pre-emptively split them into separate threads. --Paul Hoffman From paul.hoffman@vpnc.org Tue Mar 20 06:48:43 2012 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 EF00621F85D1 for ; Tue, 20 Mar 2012 06:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.68 X-Spam-Level: X-Spam-Status: No, score=-102.68 tagged_above=-999 required=5 tests=[AWL=-0.081, 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 bNAt6kWCci0b for ; Tue, 20 Mar 2012 06:48:43 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8E21C21F85C9 for ; Tue, 20 Mar 2012 06:48:43 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2KDljD6012853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 Mar 2012 06:48:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F6877E7.5030905@cs.tcd.ie> Date: Tue, 20 Mar 2012 06:48:43 -0700 Content-Transfer-Encoding: 7bit Message-Id: <49B930F7-FCAD-44D0-8413-BE61A62D3661@vpnc.org> References: <4F6877E7.5030905@cs.tcd.ie> To: dane WG list X-Mailer: Apple Mail (2.1257) Subject: [dane] 1: Q for 1.3 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 Mar 2012 13:48:44 -0000 On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: > 1. What does this, in 1.3, mean? "This document does not specify how > DNSSEC validation occurs because there are many different proposals for > how a client might get validated DNSSEC results." We've just said that > DNSSEC signatures MUST be validated and referenced DNSSEC RFCs, so what > "different proposals" do you mean and why have they no references? From paul.hoffman@vpnc.org Tue Mar 20 06:49:24 2012 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 2722A21F871A for ; Tue, 20 Mar 2012 06:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.68 X-Spam-Level: X-Spam-Status: No, score=-102.68 tagged_above=-999 required=5 tests=[AWL=-0.081, 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 VIdIY-7Bp4uu for ; Tue, 20 Mar 2012 06:49:23 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B18C221F870F for ; Tue, 20 Mar 2012 06:49:23 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2KDljD7012853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 Mar 2012 06:49:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F6877E7.5030905@cs.tcd.ie> Date: Tue, 20 Mar 2012 06:49:23 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8BCF7F66-5767-45CB-A7B5-E15450568DA5@vpnc.org> References: <4F6877E7.5030905@cs.tcd.ie> To: dane X-Mailer: Apple Mail (2.1257) Subject: [dane] 2: Usage 0 clarity 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 Mar 2012 13:49:24 -0000 On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: > 2. Is usage 0 clear enough? For example, a CA cert that's not a trust > anchor will have a basicConstraints extension with cA set, but a trust > anchor need not have that, so should usage 0 mean "CA certificate or > trust anchor" or is it just worth noting that the associated certificate > in this usage can be either? From paul.hoffman@vpnc.org Tue Mar 20 06:50:07 2012 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 3046621F8734 for ; Tue, 20 Mar 2012 06:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.641 X-Spam-Level: X-Spam-Status: No, score=-101.641 tagged_above=-999 required=5 tests=[AWL=-1.119, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077, 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 k5QQ87YEgLPw for ; Tue, 20 Mar 2012 06:50:06 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AEA9F21F8618 for ; Tue, 20 Mar 2012 06:50:06 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2KDljD8012853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 Mar 2012 06:50:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F6877E7.5030905@cs.tcd.ie> Date: Tue, 20 Mar 2012 06:50:06 -0700 Content-Transfer-Encoding: 7bit Message-Id: <039A072B-931A-45F4-B646-6B581EF16800@vpnc.org> References: <4F6877E7.5030905@cs.tcd.ie> To: dane list X-Mailer: Apple Mail (2.1257) Subject: [dane] 3: SHA-384 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 Mar 2012 13:50:07 -0000 On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: > 3. In another context the fact that sha-384 is part of the US' suite-B > (see e.g. RFC 5430) was brought up recently. Should there be a > code-point for sha-384? I don't care, but I don't recall if that was > considered in the WG discussion. From paul.hoffman@vpnc.org Tue Mar 20 06:51:11 2012 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 17C2D21F8715 for ; Tue, 20 Mar 2012 06:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.675 X-Spam-Level: X-Spam-Status: No, score=-102.675 tagged_above=-999 required=5 tests=[AWL=-0.076, 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 pvCJQ9EtXcJv for ; Tue, 20 Mar 2012 06:51:10 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 927EA21F867D for ; Tue, 20 Mar 2012 06:51:10 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2KDp9u0013011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 Mar 2012 06:51:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F6877E7.5030905@cs.tcd.ie> Date: Tue, 20 Mar 2012 06:51:09 -0700 Content-Transfer-Encoding: 7bit Message-Id: <6BB8878E-8CEE-48EE-8D4C-43C1A118A11B@vpnc.org> References: <4F6877E7.5030905@cs.tcd.ie> To: dane list X-Mailer: Apple Mail (2.1257) Subject: [dane] 4: Length of certificate association data field 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 Mar 2012 13:51:11 -0000 On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: > 4. 2.1.4 says nothing about the length of this field. Although that can > be figured out in all cases either because its fixed or because its > specified in the DER encoding of a full cert or SPKI, I wonder would all > readers know that. Could be well worth adding a bit of text about that, > even though I can't think of a way to get that wrong that wouldn't be > immediately obvious. From paul.hoffman@vpnc.org Tue Mar 20 06:52:21 2012 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 7720221F8747 for ; Tue, 20 Mar 2012 06:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.675 X-Spam-Level: X-Spam-Status: No, score=-102.675 tagged_above=-999 required=5 tests=[AWL=-0.076, 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 gcQQoAM9kOVI for ; Tue, 20 Mar 2012 06:52:14 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF2E21F8743 for ; Tue, 20 Mar 2012 06:52:14 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2KDqD3m013066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 Mar 2012 06:52:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F6877E7.5030905@cs.tcd.ie> Date: Tue, 20 Mar 2012 06:52:13 -0700 Content-Transfer-Encoding: 7bit Message-Id: <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> References: <4F6877E7.5030905@cs.tcd.ie> To: dane list X-Mailer: Apple Mail (2.1257) Subject: [dane] 5: PKI disrepute 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 Mar 2012 13:52:21 -0000 On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: > 5. If the PKI underlying TLS has fallen into disrepute, (as -18 says) > how is it that a DANE-client chosen validator to which DNSSEC has been > offloaded will be any better since that validator can be as > disreputable as a PKI with the same effects? > > Arguably, allowing a DANE client to depend on such a beast is worse > that the current PKI, since the chances we'll hear about a hacked > validator are much lower than for a higher profile CA. (I don't > have a concrete suggestion here other than to really require DNSSEC at > the DANE client, but I do want to see an answer to the question > above.) From paul.hoffman@vpnc.org Tue Mar 20 06:52:55 2012 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 DB83021F8773 for ; Tue, 20 Mar 2012 06:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.674 X-Spam-Level: X-Spam-Status: No, score=-102.674 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 aZIvOgKNU0MR for ; Tue, 20 Mar 2012 06:52:55 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7481C21F8743 for ; Tue, 20 Mar 2012 06:52:55 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2KDqD3n013066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 Mar 2012 06:52:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F6877E7.5030905@cs.tcd.ie> Date: Tue, 20 Mar 2012 06:52:55 -0700 Content-Transfer-Encoding: 7bit Message-Id: <261E1F5D-DEEE-4453-8679-D5F3B00852E8@vpnc.org> References: <4F6877E7.5030905@cs.tcd.ie> To: dane list X-Mailer: Apple Mail (2.1257) Subject: [dane] 6: No matching associations 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 Mar 2012 13:52:56 -0000 On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: > 6. Section 4, last para: if the application gets N usable certificate > associations, none of which match the TLS server then what? Should the > client treat that like zero received (i.e. continue normal TLS) or like > one bogus TLSA record, which'd mean barfing the TLS handshake? From paul.hoffman@vpnc.org Tue Mar 20 06:54:19 2012 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 92F3A21F8658 for ; Tue, 20 Mar 2012 06:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.674 X-Spam-Level: X-Spam-Status: No, score=-102.674 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 gqqGdabUZZrI for ; Tue, 20 Mar 2012 06:54:19 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2D18621F8643 for ; Tue, 20 Mar 2012 06:54:19 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2KDsIgt013147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 Mar 2012 06:54:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F6877E7.5030905@cs.tcd.ie> Date: Tue, 20 Mar 2012 06:54:18 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <4F6877E7.5030905@cs.tcd.ie> To: dane list X-Mailer: Apple Mail (2.1257) Subject: [dane] 7: Extra vulnerability of #3 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 Mar 2012 13:54:19 -0000 On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: > 7. Section 8, 2nd para - usage #3 is particularly vulnerable here > right? I think that'd be worth calling out, or am I wrong? From hallam@gmail.com Tue Mar 20 07:24:40 2012 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 3144F21F85D5 for ; Tue, 20 Mar 2012 07:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 pNAQpqrvacJp for ; Tue, 20 Mar 2012 07:24:39 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7A721F85D1 for ; Tue, 20 Mar 2012 07:24:39 -0700 (PDT) Received: by ggmi1 with SMTP id i1so101533ggm.31 for ; Tue, 20 Mar 2012 07:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gqghla1AkOEsresfVrjtNzz8JErTbCixdu9K/y9ethY=; b=onRvPkDw6i5nm+hzWW9ZIbYwtCCaJfFmPyaJsV2nJE+tNvLuDcDXVnKbCNaELtg5Cc WECwIrPjBVUVV03W/EKfBns6scOwvSoeJfYIZ2tiSEs+eAWJvEnHbYtu9oqC63iggdST S9v2fvdTAuZp5M5BlUO3w+agGhLG8y/Kz8HFOUQHToKPbboem0Ixg2s4yd62AXuRpeIP MoTtSXpi8ynkD8qDH1qDojVZI1h2oQ7l9L1ij3LAYERjDPM8AOgSq7vzoHmsRWBWLr5z P2jGqTcuwUQ/eHWc8MsQPHEWOryJiYhM6GccQ1PkA1tRyC55TfoPCrrNT46c2eH4kem/ /gNg== MIME-Version: 1.0 Received: by 10.236.174.1 with SMTP id w1mr10953929yhl.125.1332253478871; Tue, 20 Mar 2012 07:24:38 -0700 (PDT) Received: by 10.146.96.17 with HTTP; Tue, 20 Mar 2012 07:24:38 -0700 (PDT) In-Reply-To: <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> Date: Tue, 20 Mar 2012 10:24:38 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: dane list Subject: Re: [dane] 5: PKI disrepute 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 Mar 2012 14:24:40 -0000 IETF standard track not a forum for making contentious ideological statements. If the specification tries to do so it is not going to achieve IETF consensus. I don't see why it is necessary or useful to make any statement of this sort at all. On Tue, Mar 20, 2012 at 9:52 AM, Paul Hoffman wrote: > On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: > >> 5. If the PKI underlying TLS has fallen into disrepute, (as -18 says) >> how is it that a DANE-client chosen validator to which DNSSEC has been >> offloaded will be any better since that validator can be as >> disreputable as a PKI with the same effects? >> >> Arguably, allowing a DANE client to depend on such a beast is worse >> that the current PKI, since the chances we'll hear about a hacked >> validator are much lower than for a higher profile CA. (I don't >> have a concrete suggestion here other than to really require DNSSEC at >> the DANE client, but I do want to see an answer to the question >> above.) > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Website: http://hallambaker.com/ From ietf@augustcellars.com Tue Mar 20 07:56:21 2012 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 1943021F8501 for ; Tue, 20 Mar 2012 07:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 w3VHtC2BSKsn for ; Tue, 20 Mar 2012 07:56:20 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6A221F84FE for ; Tue, 20 Mar 2012 07:56:20 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 323352C9EE; Tue, 20 Mar 2012 07:56:18 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" , "'dane list'" References: <4F6877E7.5030905@cs.tcd.ie> <6BB8878E-8CEE-48EE-8D4C-43C1A118A11B@vpnc.org> In-Reply-To: <6BB8878E-8CEE-48EE-8D4C-43C1A118A11B@vpnc.org> Date: Tue, 20 Mar 2012 07:55:27 -0700 Message-ID: <020f01cd06a9$7f548e60$7dfdab20$@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: AQLdEkJTdlG4Ptyjkg0KDRjvaKCa5QHEE8UWlEUNB4A= Content-Language: en-us Subject: Re: [dane] 4: Length of certificate association data field 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 Mar 2012 14:56:21 -0000 The length of the field is well known because it is every left in the TLSA RDATA record. The more interesting question is what happens if there are extra bytes on the end of the data block. This should probably be an error. But the length of the data field is computed from the TLSA RDATA record and not from the contents of the record. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Tuesday, March 20, 2012 6:51 AM > To: dane list > Subject: [dane] 4: Length of certificate association data field > > On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: > > 4. 2.1.4 says nothing about the length of this field. Although that > > can be figured out in all cases either because its fixed or because > > its specified in the DER encoding of a full cert or SPKI, I wonder > > would all readers know that. Could be well worth adding a bit of text > > about that, even though I can't think of a way to get that wrong that > > wouldn't be immediately obvious. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ietf@augustcellars.com Tue Mar 20 08:00:20 2012 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 8118C21F85ED for ; Tue, 20 Mar 2012 08:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 TCEY8ObjTu5m for ; Tue, 20 Mar 2012 08:00:18 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id ACB9621F85D2 for ; Tue, 20 Mar 2012 08:00:18 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 9C51C38EFC; Tue, 20 Mar 2012 08:00:17 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" , "'dane list'" References: <4F6877E7.5030905@cs.tcd.ie> <261E1F5D-DEEE-4453-8679-D5F3B00852E8@vpnc.org> In-Reply-To: <261E1F5D-DEEE-4453-8679-D5F3B00852E8@vpnc.org> Date: Tue, 20 Mar 2012 07:59:26 -0700 Message-ID: <021001cd06aa$0d809530$2881bf90$@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: AQLdEkJTdlG4Ptyjkg0KDRjvaKCa5QDqCZRklEvfBkA= Content-Language: en-us Subject: Re: [dane] 6: No matching associations 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 Mar 2012 15:00:20 -0000 Fair enough comment. Suggested text If an application fails to match any certificate association, then the TLS session is aborted or never started. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Tuesday, March 20, 2012 6:53 AM > To: dane list > Subject: [dane] 6: No matching associations > > On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: > > > 6. Section 4, last para: if the application gets N usable certificate > > associations, none of which match the TLS server then what? Should the > > client treat that like zero received (i.e. continue normal TLS) or > > like one bogus TLSA record, which'd mean barfing the TLS handshake? > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From stephen.farrell@cs.tcd.ie Tue Mar 20 08:31:22 2012 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 A2BCD21F85AA for ; Tue, 20 Mar 2012 08:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSEX3hQVntsa for ; Tue, 20 Mar 2012 08:31:22 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B3D7F21F84FB for ; Tue, 20 Mar 2012 08:31:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D0B56153B67; Tue, 20 Mar 2012 15:31:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1332257480; bh=NKnI9yytDE21mb pb0fHijIO3dUtfBkmydVe+XHissIk=; b=z5pYQM5qhuPgiwe51TAWjNE5C1Wlyw Jxe9IY7uswF2qS3K/KH2va3PgcYRMZkK68yenM/w9DM0oxWI6TUgJbo2ODqmixdZ xVH3w0GnqOKbjjYjuT+DTkVWN8CATObyzcmMD5sW+Ssal9pfN+U+/dlSIzUCyqjH WZZH5yeAHc1ZwRmBm+VcFJLMK7KLSKNxe+vSakk0m2rQ5n0JdPcLZiMv/tSaQQ3a 0N4ezRe0gP+cLtbce4cfj+96kzOgHdzpw0ErFUHo5cESAqs96Pn4sanC9RtM62T2 Va/BegTzsZ6EmmuD4DueXoKgmewmqd+4gutGX4O4+6GJFxql0ckzWOXw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 6Zbb0vB0w-XV; Tue, 20 Mar 2012 15:31:20 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 79EF0153B66; Tue, 20 Mar 2012 15:31:19 +0000 (GMT) Message-ID: <4F68A2C8.3010003@cs.tcd.ie> Date: Tue, 20 Mar 2012 15:31:20 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Paul Hoffman References: <4F6877E7.5030905@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dane Subject: Re: [dane] AD review of draft-ietf-dane-protocol-18 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 Mar 2012 15:31:22 -0000 On 03/20/2012 01:47 PM, Paul Hoffman wrote: > Given that the questions are wide-ranging, and Jakob and I are going to need clear guidance if the answers lead to changes, I'm going to pre-emptively split them into separate threads. Thanks Paul. Just to be clear: I'm almost certainly ok with whatever the WG want in terms of answers to these, and a pointer to the conclusion of the previous list discussion is a fine answer if I've asked something that was already considered. (I.e. if my little brain has forgotten, which is quite possible:-) S. From stephen.farrell@cs.tcd.ie Tue Mar 20 08:32:09 2012 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 CCFBD21F85B8 for ; Tue, 20 Mar 2012 08:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpf5-U5ETJro for ; Tue, 20 Mar 2012 08:32:09 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7DC21F854D for ; Tue, 20 Mar 2012 08:32:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 87342153B67; Tue, 20 Mar 2012 15:32:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1332257528; bh=7EeL94nsKigT2C ghoOSVXGRgpGp6266gOmtbThTGCXw=; b=QwMqPNtIxqjVCSXAHXalMSWQAYy/Ex 29G6kbvfyMkQbki6xmjha858k0jA2RRb/8klgZ+gqgZdMnUPnPGkFltJ6+786xbr fWye9++nQwhYBstwLaBHOk4BrRDzH8H1KHCbgZYeLhKv16gPi7xT2U5R9wP8apai 49eg96nudFl7EDANYfGvww23zAPNnNtJNEsCyH5HdYovAYv+G03VgnK1/rBLIETf LinrJOGxLI2F9JC6ELPc/S1bcZlC79wFtBdS5PLhB6X6SypF/4OvVyfyPYmszpVy xlF4T1I/sf6Cg30xY1bNFwXen0Sq9/N46babrrYQNl/tbcFB2GBfItYA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 9BU+5tPqt4NH; Tue, 20 Mar 2012 15:32:08 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 28D53153B66; Tue, 20 Mar 2012 15:32:07 +0000 (GMT) Message-ID: <4F68A2F8.90509@cs.tcd.ie> Date: Tue, 20 Mar 2012 15:32:08 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jim Schaad References: <4F6877E7.5030905@cs.tcd.ie> <6BB8878E-8CEE-48EE-8D4C-43C1A118A11B@vpnc.org> <020f01cd06a9$7f548e60$7dfdab20$@augustcellars.com> In-Reply-To: <020f01cd06a9$7f548e60$7dfdab20$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Paul Hoffman' , 'dane list' Subject: Re: [dane] 4: Length of certificate association data field 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 Mar 2012 15:32:09 -0000 Hi Jim, On 03/20/2012 02:55 PM, Jim Schaad wrote: > The length of the field is well known because it is every left in the TLSA > RDATA record. The more interesting question is what happens if there are > extra bytes on the end of the data block. This should probably be an error. > But the length of the data field is computed from the TLSA RDATA record and > not from the contents of the record. Right, I guess there are two things here really, a) are there any decoding errors we want to call out and the corresponding action to take, and, separately, b) do we want to give any more guidance to help the programmer get it right more easily when creating or decoding records. S. > > Jim > > >> -----Original Message----- >> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of >> Paul Hoffman >> Sent: Tuesday, March 20, 2012 6:51 AM >> To: dane list >> Subject: [dane] 4: Length of certificate association data field >> >> On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: >>> 4. 2.1.4 says nothing about the length of this field. Although that >>> can be figured out in all cases either because its fixed or because >>> its specified in the DER encoding of a full cert or SPKI, I wonder >>> would all readers know that. Could be well worth adding a bit of text >>> about that, even though I can't think of a way to get that wrong that >>> wouldn't be immediately obvious. >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From paul.hoffman@vpnc.org Tue Mar 20 08:36:04 2012 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 A56E121F85CC for ; Tue, 20 Mar 2012 08:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.674 X-Spam-Level: X-Spam-Status: No, score=-102.674 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 3NIsEybhZdPC for ; Tue, 20 Mar 2012 08:36:04 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 374A621F858F for ; Tue, 20 Mar 2012 08:36:04 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2KFa0WL017433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 Mar 2012 08:36:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <020f01cd06a9$7f548e60$7dfdab20$@augustcellars.com> Date: Tue, 20 Mar 2012 08:36:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F6877E7.5030905@cs.tcd.ie> <6BB8878E-8CEE-48EE-8D4C-43C1A118A11B@vpnc.org> <020f01cd06a9$7f548e60$7dfdab20$@augustcellars.com> To: dane list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] 4: Length of certificate association data field 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 Mar 2012 15:36:04 -0000 On Mar 20, 2012, at 7:55 AM, Jim Schaad wrote: > The length of the field is well known because it is every left in the = TLSA > RDATA record. The more interesting question is what happens if there = are > extra bytes on the end of the data block. This should probably be an = error. > But the length of the data field is computed from the TLSA RDATA = record and > not from the contents of the record. Agree. I'm pretty sure this is an error that would be caught in the = software signing the zone. I don't see what we can say in 2.1.4 that = would not just be confusing, but am open to suggestions. --Paul Hoffman From paul.hoffman@vpnc.org Tue Mar 20 08:39:23 2012 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 ED5AF21F856D for ; Tue, 20 Mar 2012 08:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.673 X-Spam-Level: X-Spam-Status: No, score=-102.673 tagged_above=-999 required=5 tests=[AWL=-0.074, 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 L-zMERekbl52 for ; Tue, 20 Mar 2012 08:39:23 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB9921F8422 for ; Tue, 20 Mar 2012 08:39:23 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2KFdMIu017575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 Mar 2012 08:39:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <021001cd06aa$0d809530$2881bf90$@augustcellars.com> Date: Tue, 20 Mar 2012 08:39:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F6877E7.5030905@cs.tcd.ie> <261E1F5D-DEEE-4453-8679-D5F3B00852E8@vpnc.org> <021001cd06aa$0d809530$2881bf90$@augustcellars.com> To: dane list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] 6: No matching associations 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 Mar 2012 15:39:24 -0000 On Mar 20, 2012, at 7:59 AM, Jim Schaad wrote: > Fair enough comment. > Suggested text >=20 > If an application fails to match any certificate association, then the = TLS > session is aborted or never started. I think that is OK, but would rather be clearer: During the TLS handshake, if none of the certificate associations = matches the certificate given by the TLS server, the TLS client MUST = abort the handshake. --Paul Hoffman From ben@digicert.com Tue Mar 20 08:50:59 2012 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 7378921F85F3 for ; Tue, 20 Mar 2012 08:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9dyTnizSQ7G for ; Tue, 20 Mar 2012 08:50:58 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9CE21F85ED for ; Tue, 20 Mar 2012 08:50:58 -0700 (PDT) Received: from BenLaptop (unknown [64.78.193.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id E74A68FA11B for ; Tue, 20 Mar 2012 09:50:57 -0600 (MDT) From: "Ben Wilson" To: "'dane list'" References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> In-Reply-To: Date: Tue, 20 Mar 2012 09:50:58 -0600 Organization: DigiCert Message-ID: <004201cd06b1$3e463920$bad2ab60$@com> X-Mailer: Microsoft Office Outlook 12.0 MIME-Version: 1.0 Thread-Index: Ac0GpTFLH+tmmiK8QAm2UvClcycBlQAB7Low Content-Language: en-us Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003D_01CD067E.F2AAD3E0" Subject: Re: [dane] 5: PKI disrepute X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 15:50:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_003D_01CD067E.F2AAD3E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree. In paragraph 1.1's statement of the problem, the solution has not "gradually broken down". The issue is that there are any number of attack vectors out there on the internet. Real-world occurrences have not brought "the CA model into disrepute." That is just unsubstantiated posturing to sell an argument. Unless This kind of editorializing should not be used to slant what would otherwise be a neutral specification. As Stephen Farrell points out, when you attack any particular trust anchor, you essentially attack all trust anchors and all who have made trust decisions for you (clients, servers, ICANN, whomever). The problems of last year were not caused by single points of failure or a single "weak link". Revocation checking and system behavior are multi-faceted and DANE alone is not a silver bullet. The only way to improve TLS security is for people in different areas of interest to work toward a collaborative, holistic solution. -----Original Message----- From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker Sent: Tuesday, March 20, 2012 8:25 AM To: Paul Hoffman Cc: dane list Subject: Re: [dane] 5: PKI disrepute IETF standard track not a forum for making contentious ideological statements. If the specification tries to do so it is not going to achieve IETF consensus. I don't see why it is necessary or useful to make any statement of this sort at all. On Tue, Mar 20, 2012 at 9:52 AM, Paul Hoffman wrote: > On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: > >> 5. If the PKI underlying TLS has fallen into disrepute, (as -18 says) >> how is it that a DANE-client chosen validator to which DNSSEC has >> been offloaded will be any better since that validator can be as >> disreputable as a PKI with the same effects? >> >> Arguably, allowing a DANE client to depend on such a beast is worse >> that the current PKI, since the chances we'll hear about a hacked >> validator are much lower than for a higher profile CA. (I don't have >> a concrete suggestion here other than to really require DNSSEC at the >> DANE client, but I do want to see an answer to the question >> above.) > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Website: http://hallambaker.com/ _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane ------=_NextPart_000_003D_01CD067E.F2AAD3E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRTTCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggbCMIIFqqADAgECAhAKBN8h dF1NK4zqM3IFAFDpMA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0yMTExMTAwMDAwMDBaMGIxCzAJBgNV BAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x ITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAOiCLZn5ysJClaWAc0Bw0p5WVFypxNJBBo/JM/xNRZFcgZ/tLJz4FlnfnrUkFcKY ubR3SdyJxArar8tea+2tsHEx6886QAxGTZPsi3o2CAOrDDT+GEmC/sfHMUiAfB6iD5IOUMnGh+s2 P9gww/+m9/uizW9zI/6sVgWQ8DIhFonGcIj5BZd9o8dD3QLoOz3tsUGj7T++25VIxO4es/K8DCuZ 0MZdEkKB4YNugnM/JksUkK5ZZgrEjb7SzgaurYRvSISbT0C58Uzyr5j79s5AXVz2qPEvr+yJIvJr GGWxwXOt1/HYzx4KdFxCuGh+t9V3CidWfA9ipD8yFGCV/QcEogkCAwEAAaOCA28wggNrMA4GA1Ud DwEB/wQEAwIBhjA7BgNVHSUENDAyBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEF BQcDBAYIKwYBBQUHAwgwggHGBgNVHSAEggG9MIIBuTCCAbUGC2CGSAGG/WwBAwAEMIIBpDA6Bggr BgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABh AG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEA bgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBu AHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAA YQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBl AGYAZQByAGUAbgBjAGUALjAPBgNVHRMBAf8EBTADAQH/MH0GCCsGAQUFBwEBBHEwbzAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vd3d3LmRp Z2ljZXJ0LmNvbS9DQUNlcnRzL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNydDCBgQYDVR0fBHow eDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENB LmNybDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9v dENBLmNybDAdBgNVHQ4EFgQUFQASKxOYspkH7R7for5XDStnAs0wHwYDVR0jBBgwFoAUReuir/SS y4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAIRhTkEeuHYEKrW274/yVYW5XVb+Cpjm 5L1lin1AKdP8sV1F/Tq4KlszSyRczbm05HOtYV12rXQzimbVI69MH3JuRdl1QLuiO8+NSS/AQbDi KaNROENQmRSsMwY1Yol9d6lSB+VsIFe2gbpvvLPClO12AoDZfM6FqBzsx0NKS7FXz3LO3/UlPMsi T/2fUtE3ywi7OD7g1T5veQmtW3wxs3c1w+Rj+WgKmAfnRjh3hNI+l7wKoKisJU9EbpHh0lqva+8w HI2jREKzEIsj+tfmNXQ3rM/rq1gfyYgj/zbUB+o0akfqnZVsnilPU+3jK5UgTirPlmB6+CyA8JVS zimWgWIwggbIMIIFsKADAgECAhAG3a9d4klHJqh+PyETvXo6MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMDA1MjAwMDAwMDBaFw0x MzA4MTYyMzU5NTlaMHYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQIEwRVdGFoMQ8wDQYDVQQHEwZMaW5k b24xETAPBgNVBAoTCERpZ2lDZXJ0MR8wHQYJKoZIhvcNAQkBFhBiZW5AZGlnaWNlcnQuY29tMRMw EQYDVQQDEwpCZW4gV2lsc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArwRfbeSk glaSOZjpLHbeC10lZRntHvHOK0Y2q42FFCx9V4q+3T+m9F1z5NIq2PnyRDS1DUEhJS46OvlsHhN4 gKihQyvJHND3xCVrtKQrBERfpi3JKpmX6+Nz4m5bRf3kDHRoeNh7XekP7MseZsZO6bA1/Fs2Lb+P UR47+0haaXWxoP+cwui9Za4KE93TDgLLgTG/djoGyXQ4Qh6FtMDDUxvaQECKg//px3vQNWAGqsvP wL6RZoh8umhtPAPz/DCsazQA200XHcPHPzGx8xEeQTXjQWSaF/yiA7Uz+Gd7Y7NAlRUBEthrXnIg OWnmtxEMgVF+NNFcNoRNSrd08d4ClwIDAQABo4IDZDCCA2AwHwYDVR0jBBgwFoAUFQASKxOYspkH 7R7for5XDStnAs0wHQYDVR0OBBYEFJQrTCsMjaRP5JSSbO9e0xo0G1QjMBsGA1UdEQQUMBKBEGJl bkBkaWdpY2VydC5jb20wewYIKwYBBQUHAQEEbzBtMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5k aWdpY2VydC5jb20wRQYIKwYBBQUHMAKGOWh0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMv RGlnaUNlcnRBc3N1cmVkSURDQS0xLmNydDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADB9 BgNVHR8EdjB0MDigNqA0hjJodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVk SURDQS0xLmNybDA4oDagNIYyaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwggHGBgNVHSAEggG9MIIBuTCCAbUGC2CGSAGG/WwBAwABMIIBpDA6BggrBgEF BQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQG CCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0 AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4A YwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBk ACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQA IAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQBy AGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYA ZQByAGUAbgBjAGUALjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQEF BQADggEBAAOjIx3Whcz2znVMHQBUhErjthxpY1csZDl1uE6TTh11SUpB3keCpVwBEL+R+yAUynu4 tdUbWFsAO30SaNWXNMn2iznqhwaqz4TD29p+MQRQzr0rUcNq+8kzQHgJnKyFh2tKLs+rCfTl2jeX Yp+1cwhOhmBH/chJnW+6Js6sNGmiOeNU+jVs8tob77kvE+APqMkloBoZzVeJMp7zvTNeG25ahpzu 7tYXRJhrB+z8srhVSj8Baf0QMTxEIJxi+/rohjSTNz0ixAsLH3e7ka0oxlrMrxCOjQrMzasqtuqV JlVDvcK1hNDv4Ih6EjDllEEOwLraIlXW5jo3V5kXjUjLXZ4xggPKMIIDxgIBATB2MGIxCzAJBgNV BAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x ITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQBt2vXeJJRyaofj8hE716OjAJBgUr DgMCGgUAoIICKTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAz MjAxNTUwNTdaMCMGCSqGSIb3DQEJBDEWBBSgTNPqPX+ZTNbq3kMsC4MEL9Qg1TCBhQYJKwYBBAGC NxAEMXgwdjBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENBLTECEAbdr13i SUcmqH4/IRO9ejowgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTECEAbdr13iSUcmqH4/IRO9ejowgbcGCSqGSIb3DQEJDzGBqTCBpjAL BglghkgBZQMEAQIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhow CwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCgYIKoZIhvcNAgUwDQYJKoZI hvcNAQEBBQAEggEAGnELl7CUoL48jQ9/e72gJDMmvxHBRP4oYkFD7gW4iiaTTSzbKBDhfqL/HOH6 6MgJkDDUbWGpLEnAeufM1c8ehoRB0I7jkVvfLxxva33AZarrX/Okd6qapu5M4SaUzQaSNSUqxHnJ u+oN92SQ4nK+WfPQBGjqv0vdJePx06SmVXoJK+SPBaKidyL2SDFdEi5p2pUj0HN85PHka2Wg36O4 f1IJtMu7at3i6rftIHGOynGHSJo1GYwVGkgT1iJT5vxu6FuKNHfz/rQUe22SwV/BhZrfS95IXJk0 nrR3vMvnBziTYavYO/SXzQGWhsl37CwXnIzqFCmjoeO8t/r3KvdZlwAAAAAAAA== ------=_NextPart_000_003D_01CD067E.F2AAD3E0-- From paul.hoffman@vpnc.org Tue Mar 20 09:17:00 2012 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 F3C8A21F8625 for ; Tue, 20 Mar 2012 09:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.673 X-Spam-Level: X-Spam-Status: No, score=-102.673 tagged_above=-999 required=5 tests=[AWL=-0.074, 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 IaA2ReSplNgi for ; Tue, 20 Mar 2012 09:16:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD3621F8624 for ; Tue, 20 Mar 2012 09:16:59 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2KGGtZT019072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Mar 2012 09:16:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> Date: Tue, 20 Mar 2012 09:16:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> To: Stephen Farrell X-Mailer: Apple Mail (2.1257) Cc: dane list Subject: Re: [dane] 5: PKI disrepute 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 Mar 2012 16:17:00 -0000 > On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: >=20 >> 5. If the PKI underlying TLS has fallen into disrepute, (as -18 says) >> how is it that a DANE-client chosen validator to which DNSSEC has = been >> offloaded will be any better since that validator can be as >> disreputable as a PKI with the same effects? >>=20 >> Arguably, allowing a DANE client to depend on such a beast is worse >> that the current PKI, since the chances we'll hear about a hacked >> validator are much lower than for a higher profile CA. (I don't >> have a concrete suggestion here other than to really require DNSSEC = at >> the DANE client, but I do want to see an answer to the question >> above.) Stephen: can you clarify your question? The first two respondents have = objected to the document's statement about the PKIX-based PKI being in = disrepute, but I don't see that as being the thing you are questioning. = My reading is that you are questioning a DANE client trusting an = external validator, not the second, DNSSEC-based PKI. Which did you = intend, or did you intend something else? --Paul Hoffman From stephen.farrell@cs.tcd.ie Tue Mar 20 09:46:59 2012 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 97FCE21F8678 for ; Tue, 20 Mar 2012 09:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHgSK3U0A3qS for ; Tue, 20 Mar 2012 09:46:59 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A59A621F86DB for ; Tue, 20 Mar 2012 09:46:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E6C4F153B67; Tue, 20 Mar 2012 16:46:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1332262017; bh=WtYpu8+8SDePvM Ao1On0NrfpGBYw40xK7wz77/snRJQ=; b=okI8zw/AqolgjvCaJNPCsnZxplunha POye0vGa1VTTjvEIXQkUBZQiNZaptFHAUrCh+PU5kgNW8GjB1FGaC2iD+sFVdErC UeRFXFtIEG2+oPbwzb7uPXzWBFQSNWqN9CQKZfsnTaU/HafAJPaAkL/OXfCOwjxP bP1DQMZZRRB4LiPRT7ifqJQnmlXPjAi5Eeqaf/CQID8PX1OfLFTJN0qbO0oXAWej F3LafGCZRn+Y6ePT0ocrrkfWfR4AVz89aAZwSzje/aDwVAisnqmgZr0iL+y9ArPw wG0opKyCpSAiu/wZwvXwYVu4ngl56gQtw1BuI2+8wPSzOiZ+W1dW0FiA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id IHG2OkttSbRE; Tue, 20 Mar 2012 16:46:57 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 8393A153B66; Tue, 20 Mar 2012 16:46:57 +0000 (GMT) Message-ID: <4F68B481.9090204@cs.tcd.ie> Date: Tue, 20 Mar 2012 16:46:57 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Paul Hoffman References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dane list Subject: Re: [dane] 5: PKI disrepute 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 Mar 2012 16:46:59 -0000 On 03/20/2012 04:16 PM, Paul Hoffman wrote: >> On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: >> >>> 5. If the PKI underlying TLS has fallen into disrepute, (as -18 says) >>> how is it that a DANE-client chosen validator to which DNSSEC has been >>> offloaded will be any better since that validator can be as >>> disreputable as a PKI with the same effects? >>> >>> Arguably, allowing a DANE client to depend on such a beast is worse >>> that the current PKI, since the chances we'll hear about a hacked >>> validator are much lower than for a higher profile CA. (I don't >>> have a concrete suggestion here other than to really require DNSSEC at >>> the DANE client, but I do want to see an answer to the question >>> above.) > > > Stephen: can you clarify your question? Sure. > The first two respondents have objected to the document's statement about the PKIX-based PKI being in disrepute, but I don't see that as being the thing you are questioning. My reading is that you are questioning a DANE client trusting an external validator, not the second, DNSSEC-based PKI. Which did you intend, or did you intend something else? > It was probably a mistake for me to use disrepute here. (I had a separate comment on the editorial aspect I think.) Its a question about comparing the risk today for TLS clients vs. the risk for DANE clients using external DNSSEC validators. It seems to me that a DANE client trusting an external DNSSEC validator is as vulnerable as a current TLS client trusting a set of CAs in that any CA or any external validator can assert any key for any domain. If that's true, and if we're less likely to hear about DNSSEC validators being hacked (compared to public CA compromises) then a DANE client with an external validator could be worse off than a current TLS client depending on the current public CAs. The counter-argument is probably that a random DNSSEC validator is a less interesting target than a public CA which may affect the probability of a problem occurring that affects a given DANE client. OTOH, public CAs ought to have more defenses compared to that random DNSSEC validator, and some external DNSSEC validators will be attractive targets, so its not clear to me how the overall risk for a client pans out, when comparing the status quo (today's TLS client) vs. a DANE client with an external DNSSEC validator. But the impact on the client is the same, its vulnerable to being presented with the wrong key for any domain and accepting that. So my question might be better phrased as: is the above correct, and if so, is text needed to call that out in the draft? Hope that helps, S. > --Paul Hoffman > > From paul.hoffman@vpnc.org Tue Mar 20 10:13:52 2012 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 95A6A21F84D8 for ; Tue, 20 Mar 2012 10:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.673 X-Spam-Level: X-Spam-Status: No, score=-102.673 tagged_above=-999 required=5 tests=[AWL=-0.074, 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 A5RPUybNa194 for ; Tue, 20 Mar 2012 10:13:52 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 01A5E21F84E1 for ; Tue, 20 Mar 2012 10:13:51 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2KHDpWm021429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 Mar 2012 10:13:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F68B481.9090204@cs.tcd.ie> Date: Tue, 20 Mar 2012 10:13:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> To: dane list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] 5: PKI disrepute 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 Mar 2012 17:13:52 -0000 On Mar 20, 2012, at 9:46 AM, Stephen Farrell wrote: > It was probably a mistake for me to use disrepute > here. (I had a separate comment on the editorial > aspect I think.) Its a question about comparing > the risk today for TLS clients vs. the risk for > DANE clients using external DNSSEC validators. >=20 > It seems to me that a DANE client trusting an external > DNSSEC validator is as vulnerable as a current TLS > client trusting a set of CAs in that any CA or any > external validator can assert any key for any domain. >=20 > If that's true, and if we're less likely to hear about > DNSSEC validators being hacked (compared to public CA > compromises) then a DANE client with an external > validator could be worse off than a current TLS client > depending on the current public CAs. >=20 > The counter-argument is probably that a random DNSSEC > validator is a less interesting target than a public > CA which may affect the probability of a problem > occurring that affects a given DANE client. OTOH, > public CAs ought to have more defenses compared to > that random DNSSEC validator, and some external > DNSSEC validators will be attractive targets, so > its not clear to me how the overall risk for a > client pans out, when comparing the status quo > (today's TLS client) vs. a DANE client with an > external DNSSEC validator. >=20 > But the impact on the client is the same, its > vulnerable to being presented with the wrong key > for any domain and accepting that. >=20 > So my question might be better phrased as: is the > above correct, and if so, is text needed to call > that out in the draft? >=20 I would say "yes", this seems like a reasonable security consideration = that isn't covered in the security considerations in the DNSSEC specs. --Paul Hoffman From fenton@bluepopcorn.net Tue Mar 20 15:24:19 2012 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 6587621F84EE for ; Tue, 20 Mar 2012 15:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 Y4d1akooLVCJ for ; Tue, 20 Mar 2012 15:24:18 -0700 (PDT) Received: from kernel.bluepopcorn.net (ipv6.bluepopcorn.net [IPv6:2001:470:1f05:bfe:21a:70ff:fe11:c889]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE2121F84B3 for ; Tue, 20 Mar 2012 15:24:18 -0700 (PDT) Received: from ibm-msamboy.propel.com (63-201-144-200.propel.com [63.201.144.200]) (authenticated bits=0) by kernel.bluepopcorn.net (8.14.5/8.14.4) with ESMTP id q2KMOAoq023597 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 20 Mar 2012 15:24:11 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=buttered; t=1332282251; bh=GOFRyW+1NzrlMczI5fbkfzJOIC7xrrE8t6PjQ8o5i7M=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Jps+xjcmJPKZpLAIJstU1Es4nFO2/E+sipC11JgjbVtW77bnuENs8sczUgK4Bpin9 GPMetUOTqd2clSxgbQwCBrUW0orVK85ZGFl4+g3sT9W+36kgJvv7wu5DBhmWFYo Message-ID: <4F69038C.10507@bluepopcorn.net> Date: Tue, 20 Mar 2012 15:24:12 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Stephen Farrell References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> In-Reply-To: <4F68B481.9090204@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , dane list Subject: Re: [dane] 5: PKI disrepute 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 Mar 2012 22:24:19 -0000 On 3/20/12 9:46 AM, Stephen Farrell wrote: > It seems to me that a DANE client trusting an external > DNSSEC validator is as vulnerable as a current TLS > client trusting a set of CAs in that any CA or any > external validator can assert any key for any domain. > > If that's true, and if we're less likely to hear about > DNSSEC validators being hacked (compared to public CA > compromises) then a DANE client with an external > validator could be worse off than a current TLS client > depending on the current public CAs. But a given DANE client is likely to trust only one (or a small number) of DNSSEC validators, as compared with the 100+ root CAs that usually need to be trusted. Or looking at it another way, compromise of a given DNSSEC validator is likely to impact a smaller number of clients than compromise of a given root CA. And a client has the choice whether to use an external DNSSEC validator at all, which isn't really practical with public CAs. I would say that both of these factors mitigate the risk. -Jim From stephen.farrell@cs.tcd.ie Tue Mar 20 15:57:35 2012 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 5298B21F8629 for ; Tue, 20 Mar 2012 15:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 gMmvnPIHIg7t for ; Tue, 20 Mar 2012 15:57:34 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id E56F321F85A8 for ; Tue, 20 Mar 2012 15:57:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 74FD8153B68; Tue, 20 Mar 2012 22:57:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1332284248; bh=HqiISeChcHaAk/ H8H9NkdbUf3m/JT8TRK44PBHrFUgM=; b=E7nFEysnIJxqquQ9kN7/EWntytZpgp ryPfGdUObQkTMC5IQG9NXutQtycNP6wMcVKj91XhrtgGvMJKr4LsaebXMJ+ZQtLI l7V6046WkX3PxKgcFexVgQhTh8lKHqJVbHH9Yy4dO12KUm/MaVeLdl5zIj3fPbmM YTEQfDdriSByk7uPM4pl4lj478i4Mrtl6C6d8/gML7BtORyM5ZtQXz5NeGcxd0ru I6gK2fNNfjdEE0UdgAy2ngT6rXZQlyzjT06LCrsSwuIizaIyW7H3wjPmz0KFII/5 +0RfcGWsK5vQcOdJGnkb0oJKCSQ+VRSrEs+yQAZe+FiNeiL6+B2+A8bA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id P+jB0bAN3nmm; Tue, 20 Mar 2012 22:57:28 +0000 (GMT) Received: from [10.87.48.7] (unknown [86.44.79.158]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 56E36153B67; Tue, 20 Mar 2012 22:57:27 +0000 (GMT) Message-ID: <4F690B56.1070504@cs.tcd.ie> Date: Tue, 20 Mar 2012 22:57:26 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jim Fenton References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> In-Reply-To: <4F69038C.10507@bluepopcorn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , dane list Subject: Re: [dane] 5: PKI disrepute 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 Mar 2012 22:57:35 -0000 Hi Jim, On 03/20/2012 10:24 PM, Jim Fenton wrote: > On 3/20/12 9:46 AM, Stephen Farrell wrote: >> It seems to me that a DANE client trusting an external >> DNSSEC validator is as vulnerable as a current TLS >> client trusting a set of CAs in that any CA or any >> external validator can assert any key for any domain. >> >> If that's true, and if we're less likely to hear about >> DNSSEC validators being hacked (compared to public CA >> compromises) then a DANE client with an external >> validator could be worse off than a current TLS client >> depending on the current public CAs. > > But a given DANE client is likely to trust only one (or a small number) Hopefully. I do wonder though how long it'll be until someone wants to define a DHCP option to give me a zeroconfig way to get the IP address of a "trusted" validator though;-) > of DNSSEC validators, as compared with the 100+ root CAs that usually > need to be trusted. Well, the "need" there is down to client implementation only and nothing to do with PKI protocols. The same could happen for DANE, but one would hope we've learned something. > Or looking at it another way, compromise of a given > DNSSEC validator is likely to impact a smaller number of clients than > compromise of a given root CA. > > And a client has the choice whether to use an external DNSSEC validator > at all, which isn't really practical with public CAs. > > I would say that both of these factors mitigate the risk. I agree. And what you say (with quibbles as noted above) is worth mentioning as it does factor into the risk analysis. S. > -Jim > > From gnu@toad.com Tue Mar 20 17:13:53 2012 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 A40E921F8513 for ; Tue, 20 Mar 2012 17:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[AWL=0.207, 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 fqjMKPXZCWNr for ; Tue, 20 Mar 2012 17:13:53 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 3665F21F850F for ; Tue, 20 Mar 2012 17:13:53 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q2L0DqWD030711 for ; Tue, 20 Mar 2012 16:13:52 -0800 Message-Id: <201203210013.q2L0DqWD030711@new.toad.com> To: dane Date: Tue, 20 Mar 2012 16:13:52 -0800 From: John Gilmore Subject: [dane] Typo in -18: nane 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 Mar 2012 00:13:53 -0000 Last graf of section 8: "domain nane" -> "domain name". John From gnu@toad.com Tue Mar 20 17:59:37 2012 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 61AE021E804A for ; Tue, 20 Mar 2012 17:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.291 X-Spam-Level: X-Spam-Status: No, score=0.291 tagged_above=-999 required=5 tests=[AWL=0.194, 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 Y7WnHEAUmPpV for ; Tue, 20 Mar 2012 17:59:37 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id E637A21E8049 for ; Tue, 20 Mar 2012 17:59:36 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q2L0xaWD032433; Tue, 20 Mar 2012 16:59:36 -0800 Message-Id: <201203210059.q2L0xaWD032433@new.toad.com> To: Paul Hoffman In-reply-to: <039A072B-931A-45F4-B646-6B581EF16800@vpnc.org> References: <4F6877E7.5030905@cs.tcd.ie> <039A072B-931A-45F4-B646-6B581EF16800@vpnc.org> Comments: In-reply-to Paul Hoffman message dated "Tue, 20 Mar 2012 06:50:06 -0700." Date: Tue, 20 Mar 2012 16:59:36 -0800 From: John Gilmore Cc: dane list Subject: Re: [dane] 3: SHA-384 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 Mar 2012 00:59:37 -0000 > > 3. In another context the fact that sha-384 is part of the US' suite-B > > (see e.g. RFC 5430) was brought up recently. Should there be a > > code-point for sha-384? I don't care, but I don't recall if that was > > considered in the WG discussion. TLSA does not need a code point for sha-384. The only use that TLSA makes of the specified hash function is for matching the hash in the TLSA record with the certificate or its SubjectPublicKeyInfo. This matching is independent of the use of hashes within the TLS protocol itself (where sha-384 is mandatory among products designed for US government TOP SECRET use under NSA's "Suite B" program). The presence of TLSA record(s) do not interfere with the use of sha-384 in TLS itself. A Suite B server operator who wishes to use TLSA to associate their domain name with a certificate or a public key, without using an unapproved hash function, need only supply the entire SubjectPublicKeyInfo, or the entire certificate, in their TLSA record. They can simply avoid the use of hashes in their TLSA records. This option is fully supported by the draft as it stands, and provides better security than any hash they could have picked. In addition, I suspect that NSA would, upon reflection, also approve the use of SHA-512 in cases where SHA-384 is not available, such as this one. (If they wouldn't, then we'd like to know why they trust SHA-384 but don't trust SHA-512!) We do recommend in 2.1.3 that if the host operator uses a hash in the TLSA record, the record "SHOULD" use the same hash that was used in the signature in the certificate, to assist clients that support a small number of hash algorithms. This SHOULD does not come into play if the operator does not use a hash, as recommended above. Also, it's a SHOULD, not a MUST, and given the ready availability of free software that implements it, most clients that support any SHA-xxx algorithm will support all three SHA-256, -384, and -512 algorithms. John From stephen.farrell@cs.tcd.ie Tue Mar 20 18:06:06 2012 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 C813421E804A for ; Tue, 20 Mar 2012 18:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.237 X-Spam-Level: X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=0.363, 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 ipv+docHWTjV for ; Tue, 20 Mar 2012 18:06:06 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B96F821E8049 for ; Tue, 20 Mar 2012 18:06:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 92305153B7E; Wed, 21 Mar 2012 01:06:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1332291959; bh=zCo37uMqpm1XZ9 4L9qsi4O+EYcMVWtqEZWK6qf8/n50=; b=vaABHO7ffzMUyxHfjw6GLM46IgVITF BreL1OVHWueOenxBKjW/pL1Y68DK+FT1WllNHXE4qlb+VIXLT0qUllrp3avZnh7f lRmhbnjbVB8mTVjSzkH9HUirrWbDzlq3xJHKGUtC9uTXRd8bWdNRoMIWrJU7e4kM uAEv/C5JHkx0U6cZK+DWpMt94aCSt8xuCEx0RkMjZdOO0EYH0ebhIWte+402z/uC M6tcKVx8FSKDkQVFT2SVeWAXL3wElmeyMW+jy2vFxz5TiLphNytv0KwLrkQAROYd dl5m1npKZ0dlkmPgHN0QRyf3u5lZ3wkS3mND/AmEX2903fuHrc5G0jRw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id XQ-KtSNpAcvu; Wed, 21 Mar 2012 01:05:59 +0000 (GMT) Received: from [10.87.48.7] (unknown [86.44.79.158]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id CBA27153B68; Wed, 21 Mar 2012 01:05:57 +0000 (GMT) Message-ID: <4F692974.3080607@cs.tcd.ie> Date: Wed, 21 Mar 2012 01:05:56 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John Gilmore References: <4F6877E7.5030905@cs.tcd.ie> <039A072B-931A-45F4-B646-6B581EF16800@vpnc.org> <201203210059.q2L0xaWD032433@new.toad.com> In-Reply-To: <201203210059.q2L0xaWD032433@new.toad.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , dane list Subject: Re: [dane] 3: SHA-384 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 Mar 2012 01:06:06 -0000 On 03/21/2012 12:59 AM, John Gilmore wrote: >>> 3. In another context the fact that sha-384 is part of the US' suite-B >>> (see e.g. RFC 5430) was brought up recently. Should there be a >>> code-point for sha-384? I don't care, but I don't recall if that was >>> considered in the WG discussion. > > TLSA does not need a code point for sha-384. FWIW, I've no problem with the argument below. S > The only use that TLSA > makes of the specified hash function is for matching the hash in the > TLSA record with the certificate or its SubjectPublicKeyInfo. This > matching is independent of the use of hashes within the TLS protocol > itself (where sha-384 is mandatory among products designed for US > government TOP SECRET use under NSA's "Suite B" program). The > presence of TLSA record(s) do not interfere with the use of sha-384 in > TLS itself. > > A Suite B server operator who wishes to use TLSA to associate their > domain name with a certificate or a public key, without using an > unapproved hash function, need only supply the entire > SubjectPublicKeyInfo, or the entire certificate, in their TLSA record. > They can simply avoid the use of hashes in their TLSA records. > This option is fully supported by the draft as it stands, and > provides better security than any hash they could have picked. > > In addition, I suspect that NSA would, upon reflection, also approve > the use of SHA-512 in cases where SHA-384 is not available, such as > this one. (If they wouldn't, then we'd like to know why they trust > SHA-384 but don't trust SHA-512!) > > We do recommend in 2.1.3 that if the host operator uses a hash in the > TLSA record, the record "SHOULD" use the same hash that was used in > the signature in the certificate, to assist clients that support a > small number of hash algorithms. This SHOULD does not come into play > if the operator does not use a hash, as recommended above. Also, > it's a SHOULD, not a MUST, and given the ready availability of free > software that implements it, most clients that support any SHA-xxx > algorithm will support all three SHA-256, -384, and -512 algorithms. > > John > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From gnu@toad.com Tue Mar 20 18:35:28 2012 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 EFD3821E8020 for ; Tue, 20 Mar 2012 18:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[AWL=0.182, 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 2emSazW0fsMo for ; Tue, 20 Mar 2012 18:35:28 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id DA24121F862F for ; Tue, 20 Mar 2012 18:35:14 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q2L1ZEWD001880; Tue, 20 Mar 2012 17:35:14 -0800 Message-Id: <201203210135.q2L1ZEWD001880@new.toad.com> To: dane list , gnu@toad.com Date: Tue, 20 Mar 2012 17:35:14 -0800 From: John Gilmore Subject: [dane] Security consideration "local policy" distrusting usages 2 and 3 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 Mar 2012 01:35:29 -0000 In the last paragraph of Section 8 of -18, we have this new text: The client's full trust of a certificate retrieved from a TLSA record with a certificate usage type of 2 or 3 may be a matter of local policy. While such trust is limited to the specific domain nane for which the TLSA query was made, local policy may deny the trust or further restrict the conditions under which that trust is permitted. Text similar to this was proposed by Jim Schaad on March 4th. Ondrej responded LGTM ("Looks Good To Me"). I missed this proposed change at that time. I don't see why usage types 2 and 3 are specifically called out here as untrustworthy. It seems to me that local policy can override anything we say in an RFC, anytime, anywhere. Local policy may break interoperability, of course, but that's usually intentional (e.g. the locals don't trust some particular domain name or key, so don't WANT to interoperate with it). We specify this in Section 4: 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. But this new graf in Section 8 isn't about local policy about specific names or keys. It seems like a back-handed attempt to discredit the security of keys that are certified only by TLSA records (rather than by a certification chain headed by one of the existing CA businesses' trust anchors). The suggestion is that it would be a good idea for software that implements TLSA to be configurable to "deny the trust" of any certificate that arrives with usage types 2 or 3. If that is the intent, this text doesn't belong in the very document that specifies that we think we HAVE defined a protocol that communicates such keys securely. If we wouldn't include similar text about usage types 0 or 1, why do we now have such a statement exclusively about types 2 and 3? If we recommend making software configurable to turn off specific usage types in specific clients, this will make interoperability fail. We currently have text in Section 6 that mandates that clients MUST implement all four usage types. This permits server operators to choose any usage type that fits their circumstances, relying on the fact that any standards-conforming TLSA client can interoperate with their server. I don't see how the new suggestion to distrust types 2 and 3 is compatible with this MUST. My proposal is to remove the paragraph. (If there is some reason to keep and modify it, please explain why.) John From ietf@augustcellars.com Wed Mar 21 01:19:27 2012 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 5832C21F859F for ; Wed, 21 Mar 2012 01:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 GUiwzYbGH1S0 for ; Wed, 21 Mar 2012 01:19:26 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 09FFD21F857D for ; Wed, 21 Mar 2012 01:19:25 -0700 (PDT) Received: from Tobias (unknown [68.25.130.116]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 9EB4C2CA17; Wed, 21 Mar 2012 01:19:23 -0700 (PDT) From: "Jim Schaad" To: "'John Gilmore'" , "'dane list'" References: <201203210135.q2L1ZEWD001880@new.toad.com> In-Reply-To: <201203210135.q2L1ZEWD001880@new.toad.com> Date: Wed, 21 Mar 2012 01:18:21 -0700 Message-ID: <000c01cd073b$36c35bd0$a44a1370$@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: AQKn1pdPvpeUsO8CsMTfmemWvnmQoZS+x+ew Content-Language: en-us Subject: Re: [dane] Security consideration "local policy" distrusting usages 2 and 3 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 Mar 2012 08:19:27 -0000 John, The issue is one of explicitly known when a trust decision is being made. While many people argue that one does not know for Windows when this decision is made as it gets farmed out to Microsoft, this is not true for all configurations and for all other operating systems. The statement does not say that you cannot trust it just because it is in the DNS records, it says that some people may not do so or may do so only under some circumstances. This is not an issue for type 0 or 1 records as the trust decision is made elsewhere. I guess it is no more of a back hand way of saying that some people will not trust it than DANE is a back handed way of saying that PKI is untrustworthy which is being said in this document. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > John Gilmore > Sent: Tuesday, March 20, 2012 6:35 PM > To: dane list; gnu@toad.com > Subject: [dane] Security consideration "local policy" distrusting usages 2 and 3 > > In the last paragraph of Section 8 of -18, we have this new text: > > The client's full trust of a certificate retrieved from a TLSA record > with a certificate usage type of 2 or 3 may be a matter of local > policy. While such trust is limited to the specific domain nane for > which the TLSA query was made, local policy may deny the trust or > further restrict the conditions under which that trust is permitted. > > Text similar to this was proposed by Jim Schaad on March 4th. Ondrej > responded LGTM ("Looks Good To Me"). I missed this proposed change at > that time. > > I don't see why usage types 2 and 3 are specifically called out here as > untrustworthy. > > It seems to me that local policy can override anything we say in an RFC, > anytime, anywhere. Local policy may break interoperability, of course, but > that's usually intentional (e.g. the locals don't trust some particular domain > name or key, so don't WANT to interoperate with it). We specify this in > Section 4: > > 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. > > But this new graf in Section 8 isn't about local policy about specific names or > keys. It seems like a back-handed attempt to discredit the security of keys > that are certified only by TLSA records (rather than by a certification chain > headed by one of the existing CA businesses' > trust anchors). The suggestion is that it would be a good idea for software > that implements TLSA to be configurable to "deny the trust" > of any certificate that arrives with usage types 2 or 3. If that is the intent, this > text doesn't belong in the very document that specifies that we think we > HAVE defined a protocol that communicates such keys securely. > > If we wouldn't include similar text about usage types 0 or 1, why do we now > have such a statement exclusively about types 2 and 3? If we recommend > making software configurable to turn off specific usage types in specific > clients, this will make interoperability fail. > > We currently have text in Section 6 that mandates that clients MUST > implement all four usage types. This permits server operators to choose any > usage type that fits their circumstances, relying on the fact that any > standards-conforming TLSA client can interoperate with their server. I don't > see how the new suggestion to distrust types 2 and 3 is compatible with this > MUST. > > My proposal is to remove the paragraph. (If there is some reason to keep > and modify it, please explain why.) > > John > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From mrex@sap.com Wed Mar 21 05:28:18 2012 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 22CA921F8616 for ; Wed, 21 Mar 2012 05:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.06 X-Spam-Level: X-Spam-Status: No, score=-10.06 tagged_above=-999 required=5 tests=[AWL=0.189, 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 f3jc1bOMY2eA for ; Wed, 21 Mar 2012 05:28:17 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E24E121F860D for ; Wed, 21 Mar 2012 05:28:16 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q2LCSD0a020894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Mar 2012 13:28:14 +0100 (MET) From: Martin Rex Message-Id: <201203211228.q2LCSDPi006612@fs4113.wdf.sap.corp> To: gnu@toad.com (John Gilmore) Date: Wed, 21 Mar 2012 13:28:13 +0100 (MET) In-Reply-To: <201203210059.q2L0xaWD032433@new.toad.com> from "John Gilmore" at Mar 20, 12 04:59:36 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] 3: SHA-384 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: Wed, 21 Mar 2012 12:28:18 -0000 John Gilmore wrote: > > In addition, I suspect that NSA would, upon reflection, also approve > the use of SHA-512 in cases where SHA-384 is not available, such as > this one. (If they wouldn't, then we'd like to know why they trust > SHA-384 but don't trust SHA-512!) SHA-384 and SHA-512 are exactly the same algorithm. SHA-384 only uses a different internal start value than SHA-512 and truncates the output. -Martin From ondrej.mikle@nic.cz Wed Mar 21 07:31:09 2012 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 CF00821F86F6 for ; Wed, 21 Mar 2012 07:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_20=-0.74, 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 QrWnuyp3SHFf for ; Wed, 21 Mar 2012 07:31:09 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB9921F8649 for ; Wed, 21 Mar 2012 07:31:09 -0700 (PDT) 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 52C372A2E44 for ; Wed, 21 Mar 2012 15:31:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1332340268; bh=l9Pxxnqeij4l3l92BHi//n5U0wg4Lcz9ZTEGGrqRW+c=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=MU6Dg79+XGfqepGB/gN0Q+rpO4mjm0/c4oQdtMhJ5yF2E5ev0xSYPqGIks9jotEC7 EGyc0C6kosuEC1+5SaEiVrqs96tJ3VXdN4jt6ksEeHFtOxEVFCc4uGefXQGQvIDoQv nVIwWmpwphUjLxZnFSp0MKqnK96/nezEYlbCWQcU= Message-ID: <4F69E5E0.9080903@nic.cz> Date: Wed, 21 Mar 2012 15:29:52 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: dane@ietf.org X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] Pseudocode in -18 for usage certificate usage 2 incorrect 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 Mar 2012 14:31:09 -0000 Hi, current pseudocode for certificate usage 2 only tests match against end-entity certificate C: // pass PKIX certification validation using TLSA record as the // trust anchor if (R.certUsage == 2) { for each PKIX certification path H that has R as the trust anchor { if (C passes PKIX certification validation in H) and Match(R.matchingType, Select(R.selectorType, C), R.cert)) { Finish(ACCEPT) } } } The Match() needs to check every certificate from chain, a new version could be: // pass PKIX certification validation using TLSA record as the // trust anchor if (R.certUsage == 2) { for each PKIX certification path H that has R as the trust anchor { if (C passes PKIX certification validation in H) { for each D in H { if (Match(R.matchingType, Select(R.selectorType, D), R.cert)) { Finish(ACCEPT) } } } } } Ondrej Mikle From kent@bbn.com Wed Mar 21 11:34:48 2012 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 527C621F84E4 for ; Wed, 21 Mar 2012 11:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.472 X-Spam-Level: X-Spam-Status: No, score=-106.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 RyEgjAUgh1KV for ; Wed, 21 Mar 2012 11:34:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5D67521F8453 for ; Wed, 21 Mar 2012 11:34:47 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49164) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SAQMh-000JRZ-OX; Wed, 21 Mar 2012 14:34:31 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4F690B56.1070504@cs.tcd.ie> References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> <4F690B56.1070504@cs.tcd.ie> Date: Wed, 21 Mar 2012 14:34:35 -0400 To: Stephen Farrell From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Paul Hoffman , dane list Subject: Re: [dane] 5: PKI disrepute 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 Mar 2012 18:34:48 -0000 What I would say is: The public CA model upon which browsers and OS's depend is fundamentally vulnerable, not because it is PKI-based, but because it allows any of these CAs to issue any certificate, with no constraints. Business models adopted by browser and OS vendors, and by the public CAs, have allowed this model to be exploited, with predictable consequences. Recent experiences with compromises of CAs or RAs have lead to very serious secruity problems that undermine confidence in this system. DANE is envisioned as a preferable basis for binding public keys to DNS names (a subset of what PKIs can do in general) because the entities that vouch for the binding of public key data to DNS names are the entities responsible to managing the DNS names in question. While the resulting system still has residual security vulnerabilities, it restricts the scope of assertions that can be made by any entity, consistent with the naming scope imposed by the DNS hierarchy. As a result, DANE embodies the security "principle of least privilege" that is lacking in the current public CA model. Steve From fanf2@hermes.cam.ac.uk Wed Mar 21 11:43:25 2012 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 4E28521F8603 for ; Wed, 21 Mar 2012 11:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 yPSLYCyPP4Aq for ; Wed, 21 Mar 2012 11:43:24 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 783FB21F861C for ; Wed, 21 Mar 2012 11:43:21 -0700 (PDT) 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]:45448) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SAQV9-00065E-SL (Exim 4.72) (return-path ); Wed, 21 Mar 2012 18:43:16 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SAQV9-0003jI-EI (Exim 4.67) (return-path ); Wed, 21 Mar 2012 18:43:15 +0000 Date: Wed, 21 Mar 2012 18:43:15 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Jim Fenton In-Reply-To: <4F69038C.10507@bluepopcorn.net> Message-ID: References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> 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 list , Paul Hoffman Subject: Re: [dane] 5: PKI disrepute 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 Mar 2012 18:43:25 -0000 Jim Fenton wrote: > On 3/20/12 9:46 AM, Stephen Farrell wrote: > > > > It seems to me that a DANE client trusting an external > > DNSSEC validator is as vulnerable as a current TLS > > client trusting a set of CAs in that any CA or any > > external validator can assert any key for any domain. > > But a given DANE client is likely to trust only one (or a small number) > of DNSSEC validators, as compared with the 100+ root CAs that usually > need to be trusted. Or looking at it another way, compromise of a given > DNSSEC validator is likely to impact a smaller number of clients than > compromise of a given root CA. Also, with DANE the DNSSEC validator is chosen by the client, either as a side-effect of the client's choice of connectivity provider, or by a deliberate choice to use a third party DNS service. Either way the client has some control over the trustworthiness of the validator. With bare X.509 users are vulnerable to hundreds of organizations that have no relationship with either the client or the server. The client and server have no control over the trustworthiness of authentication. Tony. -- f.anthony.n.finch http://dotat.at/ Hebrides, Bailey, Fair Isle, Faeroes, South-east Iceland: Southwesterly 5 to 7, occasionally gale 8 at first except in Fair Isle, backing southerly 5 or 6. Rough or very rough, occasionally high at first in Bailey. Rain and drizzle then mainly fair. Good, occasionally poor. From Rick_Andrews@symantec.com Wed Mar 21 12:08:36 2012 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 6026021E80AD for ; Wed, 21 Mar 2012 12:08:36 -0700 (PDT) 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 Md2i+DX+OfR2 for ; Wed, 21 Mar 2012 12:08:35 -0700 (PDT) Received: from ecl1mtaoutpex02.symantec.com (ecl1mtaoutpex02.symantec.com [166.98.1.210]) by ietfa.amsl.com (Postfix) with ESMTP id C183E21F85E7 for ; Wed, 21 Mar 2012 12:08:14 -0700 (PDT) X-AuditID: a66201d2-b7fdc6d000002a88-02-4f6a271d128b Received: from tus1smtintpin01.ges.symantec.com (TUS1SMTINTPIN01.ges.symantec.com [192.168.215.101]) by ecl1mtaoutpex02.symantec.com (Symantec Messaging Gateway) with SMTP id 1F.8B.10888.D172A6F4; Wed, 21 Mar 2012 19:08:13 +0000 (GMT) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by tus1smtintpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1SAQtJ-0003fX-9M; Wed, 21 Mar 2012 12:08:13 -0700 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Wed, 21 Mar 2012 12:08:13 -0700 From: Rick Andrews To: Tony Finch , Jim Fenton Date: Wed, 21 Mar 2012 12:08:12 -0700 Thread-Topic: [dane] 5: PKI disrepute Thread-Index: Ac0HkoQARAOWxwzXTrSG0BlGghHqdgAAm9SA Message-ID: <544B0DD62A64C1448B2DA253C011414605E9764BD5@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsVyYMX1VF1Z9Sx/g+ZmU4s9xyeyWmzruchm 8a1zFrPFrfVfWB1YPJ6uesXkse94A6vHkiU/mTw+z77KHMASxWWTkpqTWZZapG+XwJXRv+Y9 S8FmnooJl6cyNTDe4+xi5OSQEDCRWHp9IQuELSZx4d56ti5GLg4hgTeMElNObGeFcF4xSkza 8YEJwlnFKHH851Y2kBY2AT2JLY+vsHcxcnCICDhJLD9dCRJmFnCW2DjrClgJi4CqxNRvD1hA SoQFVCSOH7ACCYsAhe9u/8MEYRtJzHm/GMzmFYiSOLNwGzPEqi4miSOH54JdxyngIbH45n6w IkagS7+fWsMEsUtc4taT+UwQHwhILNlznhnCFpV4+fgfK0S9qMSd9vWMEPU6Egt2f2KDsLUl li18zQyxWFDi5MwnLBMYxWchGTsLScssJC2zkLQsYGRZxSiTmpxjmFuSmF9aUpBaYWCkV1yZ mwiMxWS95PzcTYzAeFyWxHhpB+P9w7qHGAU4GJV4eB+KZfkLsSaWAVUeYpTgYFYS4Z3FABTi TUmsrEotyo8vKs1JLT7EKM3BoiTO67M1w19IID2xJDU7NbUgtQgmy8TBKdXAeDTb2yGff09p 6oaF31/aT/n45bbdDIUvvWmfmsonbGcQyd77TtxOy2+PdqDRae09moZy/8z/8rhoLHl+eF58 Md8bW5EqK/n7vA0hj2enqwq8l58R6XNN+qjDV/MQ/nMZWxbzm17ZdPSt2NTbD/dr+L0rsP7X sHGSS4ycS1NbZPX3/Hb2v98zlViKMxINtZiLihMBI1yIVcMCAAA= Cc: Paul Hoffman , dane list Subject: Re: [dane] 5: PKI disrepute 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 Mar 2012 19:08:36 -0000 > > On 3/20/12 9:46 AM, Stephen Farrell wrote: > > > > > > It seems to me that a DANE client trusting an external > > > DNSSEC validator is as vulnerable as a current TLS > > > client trusting a set of CAs in that any CA or any > > > external validator can assert any key for any domain. > > > > But a given DANE client is likely to trust only one (or a small number) > > of DNSSEC validators, as compared with the 100+ root CAs that usually > > need to be trusted. Or looking at it another way, compromise of a given > > DNSSEC validator is likely to impact a smaller number of clients than > > compromise of a given root CA. > > Also, with DANE the DNSSEC validator is chosen by the client, either as a > side-effect of the client's choice of connectivity provider, or by a > deliberate choice to use a third party DNS service. Either way the client > has some control over the trustworthiness of the validator. > > With bare X.509 users are vulnerable to hundreds of organizations that > have no relationship with either the client or the server. The client > and server have no control over the trustworthiness of authentication. Browsers give users control today by allowing them to untrust any of those = root CAs. Granted, it's not too easy to do, but it's possible. If I hear ab= out a breach at a particular CA, it's possible to edit my trust settings to= untrust all certs signed by that CA. In a DANE world, assuming CAs still exist and sign at least some certs, it = will be impossible to untrust all certs signed by a particular CA. -Rick From ietf@augustcellars.com Wed Mar 21 13:43:43 2012 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 508F721E811D for ; Wed, 21 Mar 2012 13:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 96YwAgSRa+R1 for ; Wed, 21 Mar 2012 13:43:42 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 34D9E21F844B for ; Wed, 21 Mar 2012 13:43:42 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id E280938EED; Wed, 21 Mar 2012 13:43:38 -0700 (PDT) From: "Jim Schaad" To: "'Ondrej Mikle'" , References: <4F69E5E0.9080903@nic.cz> In-Reply-To: <4F69E5E0.9080903@nic.cz> Date: Wed, 21 Mar 2012 13:42:39 -0700 Message-ID: <004701cd07a3$2f5a8ea0$8e0fabe0$@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: AQHFPNjx4QTkBemRcAu2f3sBpYuwcpaEzISw Content-Language: en-us Subject: Re: [dane] Pseudocode in -18 for usage certificate usage 2 incorrect 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 Mar 2012 20:43:43 -0000 No, if the certificate is a trust anchor, the chain stops at that point. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Ondrej Mikle > Sent: Wednesday, March 21, 2012 7:30 AM > To: dane@ietf.org > Subject: [dane] Pseudocode in -18 for usage certificate usage 2 incorrect > > Hi, > > current pseudocode for certificate usage 2 only tests match against end- > entity certificate C: > > // pass PKIX certification validation using TLSA record as the > // trust anchor > if (R.certUsage == 2) { > for each PKIX certification path H that has R as the > trust anchor { > if (C passes PKIX certification validation in H) and > Match(R.matchingType, Select(R.selectorType, C), > R.cert)) { > Finish(ACCEPT) > } > } > } > > The Match() needs to check every certificate from chain, a new version could > be: > > // pass PKIX certification validation using TLSA record as the > // trust anchor > if (R.certUsage == 2) { > for each PKIX certification path H that has R as the > trust anchor { > if (C passes PKIX certification validation in H) { > for each D in H { > if (Match(R.matchingType, Select(R.selectorType, D), > R.cert)) { > Finish(ACCEPT) > } > } > } > } > } > > Ondrej Mikle > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From fanf2@hermes.cam.ac.uk Thu Mar 22 03:55:54 2012 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 20F5021F858D for ; Thu, 22 Mar 2012 03:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 wOqnJ1nIeBsO for ; Thu, 22 Mar 2012 03:55:52 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id A5EB021F856F for ; Thu, 22 Mar 2012 03:55:52 -0700 (PDT) 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]:54578) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SAfgL-0001Va-E3 (Exim 4.72) (return-path ); Thu, 22 Mar 2012 10:55:49 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SAfgL-0006H2-A3 (Exim 4.67) (return-path ); Thu, 22 Mar 2012 10:55:49 +0000 Date: Thu, 22 Mar 2012 10:55:49 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Rick Andrews In-Reply-To: <544B0DD62A64C1448B2DA253C011414605E9764BD5@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Message-ID: References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> <544B0DD62A64C1448B2DA253C011414605E9764BD5@TUS1XCHEVSPIN33.SYMC.SYMANTEC.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: Paul Hoffman , dane list Subject: Re: [dane] 5: PKI disrepute 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, 22 Mar 2012 10:55:54 -0000 Rick Andrews wrote: > > Browsers give users control today by allowing them to untrust any of > those root CAs. Granted, it's not too easy to do, but it's possible. If > I hear about a breach at a particular CA, it's possible to edit my trust > settings to untrust all certs signed by that CA. Trust wrt a validation service is not the same thing as trust wrt a CA (an authentication service). Clients don't have a free choice about which CAs they trust, because CAs are chosen by servers. The alternative to trusting CAs is for clients to authenticate each name themselves, which is not a PKI. With DANE clients have a free choice of which validator to trust, independent of which names they want to authenticate. > In a DANE world, assuming CAs still exist and sign at least some certs, > it will be impossible to untrust all certs signed by a particular CA. You are assuming that client software doesn't provide a CA blacklist. Tony. -- f.anthony.n.finch http://dotat.at/ Lundy, Fastnet, Irish Sea, Shannon: East or southeast 4 or 5, increasing 6 at times, except in Irish Sea. Slight or moderate, occasionally rough in Shannon. Occasional thundery rain. Moderate or good, occasionally poor. From gnu@toad.com Sat Mar 24 02:36:49 2012 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 539E021F86F5 for ; Sat, 24 Mar 2012 02:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.199 X-Spam-Level: * X-Spam-Status: No, score=1.199 tagged_above=-999 required=5 tests=[AWL=-0.757, BAYES_20=-0.74, 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 0XXRT5+P4don for ; Sat, 24 Mar 2012 02:36:48 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id C103D21F86FC for ; Sat, 24 Mar 2012 02:36:48 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q2O9alWD028629; Sat, 24 Mar 2012 01:36:47 -0800 Message-Id: <201203240936.q2O9alWD028629@new.toad.com> To: dane@ietf.org, gnu@toad.com Date: Sat, 24 Mar 2012 01:36:47 -0800 From: John Gilmore Subject: [dane] US FCC CSRIC recommends DNSSEC, US ISPs agree to deploy it 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 Mar 2012 09:36:49 -0000 FYI. --John http://www.fcc.gov/document/csric-adopts-recs-minimize-three-major-cyber-threats Chairman Genachowski applauds voluntary commitments by nation's largest Internet Service Providers, including AT&T, CenturyLink, Comcast, Cox, Sprint, Time Warner Cable, T-Mobile and Verizon to better secure their communications networks and protect consumers and business ... ...industry advisory group for the Federal Communications Commission (FCC), the Communications, Security, Reliability, and Interoperability Council (CSRIC), unanimously adopted recommendations for voluntary action by Internet service providers (ISPs) to combat three major cyber security threats, including botnets, attacks on the Domain Name System (DNS), and Internet route hijacking. ... CSRIC recommended that ISPs implement best practices to better secure the Domain Name System. DNS works like a telephone book for the Internet, but lack of security for DNS has enabled spoofing, allowing Internet criminals to coax credit card numbers and personal data from users who do not realize they are on an illegitimate website. DNSSEC is a set of secure protocol extensions that prevent such fraudulent activity. This recommendation is a significant first step toward full DNSSEC implementation by ISPs and will allow users, with software applications like browsers, to validate that the destination they are trying to reach is authentic and not a spoofed website. ... When fully implemented, these measures will strengthen the security of the networks of the ISPs that provide Internet access to over 50 percent of residential broadband users. ... From warren@kumari.net Sat Mar 24 08:29:20 2012 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 BD6C021F86C4 for ; Sat, 24 Mar 2012 08:29:20 -0700 (PDT) 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 qvu079S9glJx for ; Sat, 24 Mar 2012 08:29:20 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id C8BDC21F86DB for ; Sat, 24 Mar 2012 08:29:19 -0700 (PDT) Received: from [172.28.226.85] (unknown [74.125.57.241]) by vimes.kumari.net (Postfix) with ESMTPSA id CD8A01B414B3; Sat, 24 Mar 2012 11:29:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <201203240936.q2O9alWD028629@new.toad.com> Date: Sat, 24 Mar 2012 16:29:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201203240936.q2O9alWD028629@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] US FCC CSRIC recommends DNSSEC, US ISPs agree to deploy it 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 Mar 2012 15:29:20 -0000 On Mar 24, 2012, at 10:36 AM, John Gilmore wrote: > FYI. --John >=20 > = http://www.fcc.gov/document/csric-adopts-recs-minimize-three-major-cyber-t= hreats >=20 > Chairman Genachowski applauds voluntary commitments by nation's > largest Internet Service Providers, including AT&T, CenturyLink, > Comcast, Cox, Sprint, Time Warner Cable, T-Mobile and Verizon to > better secure their communications networks and protect consumers and > business ... >=20 > ...industry advisory group for the Federal Communications Commission > (FCC), the Communications, Security, Reliability, and = Interoperability > Council (CSRIC), unanimously adopted recommendations for voluntary > action by Internet service providers (ISPs) to combat three major > cyber security threats, including botnets, attacks on the Domain Name > System (DNS), and Internet route hijacking. ... >=20 > CSRIC recommended that ISPs implement best practices to better secure > the Domain Name System. DNS works like a telephone book for the > Internet, but lack of security for DNS has enabled spoofing, allowing > Internet criminals to coax credit card numbers and personal data from > users who do not realize they are on an illegitimate website. DNSSEC > is a set of secure protocol extensions that prevent such fraudulent > activity. This recommendation is a significant first step toward full > DNSSEC implementation by ISPs and will allow users, with software > applications like browsers, to validate that the destination they are > trying to reach is authentic and not a spoofed website. ... >=20 > When fully implemented, these measures will strengthen the security > of the networks of the ISPs that provide Internet access to over 50 > percent of residential broadband users. =85 In the interests of full disclosure, I was part of this CSRIC WG=85 W > _____________________________________ > __________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From msk@cloudmark.com Thu Mar 29 08:06:42 2012 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 7E24721E815F for ; Thu, 29 Mar 2012 08:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 T+UxG1g4juhy for ; Thu, 29 Mar 2012 08:06:42 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0F25721E80DF for ; Thu, 29 Mar 2012 08:06:39 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 29 Mar 2012 08:06:38 -0700 From: "Murray S. Kucherawy" To: IETF DANE WG list Thread-Topic: [dane] Draft -18 Thread-Index: AQHM/h0LwV0YGai3rEmb+GZ3W9ZQG5aBflpw Date: Thu, 29 Mar 2012 15:06:37 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C11BD@exch-mbx901.corp.cloudmark.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.64.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dane] Draft -18 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, 29 Mar 2012 15:06:42 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of P= aul Hoffman > Sent: Friday, March 09, 2012 9:50 AM > To: IETF DANE WG list > Subject: [dane] Draft -18 >=20 > ... has everything Jakob and I believe we were instructed to do by the > chairs. The chairs will also decide what to do about the issue under > discussion with the definition of usage type 2, but we wanted to get > everyone a clean draft to look at. Hi Paul and everyone, Just checking in: I've been assigned the AppsDir review for this draft, whi= ch is good because I've been meaning to track the work more closely anyway.= (In fact, I volunteered to do it.) I was hoping to get it done on my way here, but it didn't happen. I plan t= o do it on the flights home, so I hope to have it to you within a week or s= o. -MSK From paul.hoffman@vpnc.org Sat Mar 31 16:36:29 2012 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 1C2A521F87B4 for ; Sat, 31 Mar 2012 16:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.369 X-Spam-Level: X-Spam-Status: No, score=-101.369 tagged_above=-999 required=5 tests=[AWL=-1.371, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOPIEqR4-5et for ; Sat, 31 Mar 2012 16:36:27 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 273A421F878E for ; Sat, 31 Mar 2012 16:36:27 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2VNaMCv010298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 31 Mar 2012 16:36:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: multipart/alternative; boundary="Apple-Mail=_E1030729-D561-4632-90CF-753B32B4CA98" Date: Sat, 31 Mar 2012 16:36:21 -0700 References: <9452079D1A51524AA5749AD23E0039280C3D5E@exch-mbx901.corp.cloudmark.com> To: dane list Message-Id: <08A9ED70-1B27-4D36-9CE9-BFCF84E29892@vpnc.org> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dane] Fwd: AppsDir review of draft-ietf-dane-protocol-18 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 23:36:29 -0000 --Apple-Mail=_E1030729-D561-4632-90CF-753B32B4CA98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Begin forwarded message: > From: "Murray S. Kucherawy" > Subject: AppsDir review of draft-ietf-dane-protocol-18 > Date: March 31, 2012 1:39:56 PM PDT > To: "apps-discuss@ietf.org" , = "draft-ietf-dane-protocol.all@tools.ietf.org" = >=20 > I have been selected as the Applications Area Directorate reviewer for = this draft (for background on appsdir, please see = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)= . > =20 > This review is being undertaken early, during AD Evaluation but before = IETF Last Call. Please resolve these comments along with any other = pre-Last Call comments you may receive. Please wait for direction from = your document shepherd or AD before posting a new version of the draft. > =20 > Document: draft-ietf-dane-protocol > Title: The DNS-Based Authentication of Named Entities (DANE) Protocol = for Transport Layer Security (TLS) > Reviewer: Murray S. Kucherawy > Review Date: March 31, 2012 > IETF Last Call Date: not started > IESG Telechat Date: not scheduled > =20 > Review Summary: This draft is almost ready for publication as an = Standards Track RFC but has a few issues that should be fixed before = publication. > =20 > Document Summary: The draft proposes a mechanism by which an = association between a TLS certificate and an ADMD (a domain owner or = similar) can be inferred from data found in the DNS. That is, one could = confirm =93This key really does belong to example.com=94 by checking for = some corresponding new data in example.com=92s DNS. The goal appears to = be to eliminate the current requirement for third-party certificate = validation. The document is well-formed and clearly a lot of good work = has gone into it. The IANA and Security sections are present and = well-formed. Truly, a captivating read; I was particularly moved by the = authors=92 use of =9330820454308202BC020900AB58D24E77AD2AF6300D06092A86=94= in Appendix C. > =20 > Major Issues (things I think the WG needs to think about, clarify, = reconsider, overhaul, describe better, fret about, talk me out of, = etc.): > =20 > Section 2.1.3: I don=92t know understand why this is a SHOULD. = Doesn=92t it have to match exactly? What=92s an example of a situation = where one could/should/would legitimately deviate from what this field = says with a meaningful result? The pseudocode in Appendix B leaves no = room for SHOULD-style evaluation, so maybe this really ought to be a = MUST. > =20 > Section 10: RFC1034 and RFC1035 should be normative references, = probably dragged in very early in this document. The examples in = Section 2.3 rely on zone file syntax defined there, and Appendix A.2 = includes quite a bit of material that requires DNS familiarity. A = reference for DNAME (I don=92t have it handy) would probably also be a = good idea, though that one could be informative. > =20 > Minor Issues (things I believe can be improved without too much effort = or additional thought): > =20 > Section 1.3: The lone MUST here seems out of place given that Section = 1 is =93Introduction=94. I suspect it might belong in or near Section = 4. It=92s also unclear to me whether you=92re repeating a requirement = of DNSSEC or declaring one imposed by the protocol this document = presents. > =20 > Section 1.3: The sentence at the end of the first paragraph should = probably be on its own, at the start of this section. It should be = followed by the =93This document defines a secure method=85=94 = paragraph, which also has a very context-setting feel to it. > =20 > Section 2: The =93TBD=94 here might be better replaced by a forward = reference to Section 7 where that number will presumably be assigned, so = that there=92s no need to update the same value in two places once the = assignment occurs. More on that later when I get to section 7. > =20 > Section 2.1.1: Suggest the lowercase =93must=94 in the 0 definition be = changed to =93MUST=94. > =20 > Section 2.1.1: Suggest the lowercase =93may=94 be changed to =93can=94 = in the 1 definition. > =20 > Section 2.2: Suggest stating that the unsigned decimal integers are = eight-bit unsigned decimal integers. (I realize this is redundant to = the block diagram earlier, but since you=92re being so precise here, you = may as well be complete.) > =20 > Section 2.3: Suggest adding an example that uses matching type 0 and = selector 1. >=20 > Section 2.3: The TLSA syntax in the example has me wondering of = RFC103[45] defined the space-separated integers in the zone file to do = what you=92re obviously trying to do here. Since I=92m airborne I don=92t= have access to confirm, but I suspect you=92ve done your homework and = this is fine. It=92s just a note to me to check it when I=92m back on = the ground. > =20 > Section 3: Don=92t use active voice. Generally, instead of =93you = would use=94, say =93is used=94 or =93would be used=94. > =20 > Section 4: The third paragraph is juicy insofar as I can think of = other current IETF work that might be useful to reference here. For = example, might the domain name with which an association is established = be useful input to the Same Origin work being done in WEBSEC? Have they = talked about this? It might be an interesting use case to call out here = or in an appendix or some such. > =20 > Section 4: The fourth paragraph needs a MUST in there somewhere, = either covering the full set of steps or one for each of them. > =20 > Section 4: The third item in the bulleted list is less assertive than = the other two and seems to leave things dangling a bit. Suggest saying = explicitly that the TLS session can continue but no positive assertion = of an association can be made, or something like that. > =20 > Section 4, second last paragraph: In the preceding paragraph, you = direct the client to consider the TLSA data unusable. In this one, you = direct the client to mark it unusable. Is there a reason for the = distinction between =93considering=94 and =93marking=94? I don=92t know = what I would do differently here. > =20 > Section 4, last paragraph: Is this referring to a TLSA query that = returns multiple answers? I think it is; just confirming. (You = actually do answer this in the next section, I believe.) >=20 > Section 4: The last paragraph also leaves me hanging a bit. It should = probably say something about exactly what the meaning of a successful = match is, since you were so clear about the meanings of the failure = cases. > =20 > Section 6: Do we need version numbering in the protocol anywhere, = since you=92re already anticipating a revision? The answer might be = =93no=94, just want to make sure it got consideration. >=20 > Section 7.1: Why do the TBD thing instead of making the RRtype = assignment request now? > =20 > Section 7.2: Would it be appropriate to make a DANE registry group for = the work you=92re doing in 7.2, 7.3 and 7.4? IANA might do that = automatically, I suppose, but I thought I=92d ask anyway. > =20 > Section 8, second last paragraph: A caveat about long TTLs meaning = termination of a TLSA record can take a long time to take effect might = be useful here. (This came up in a recent SecDir review for a draft I = authored in another working group.) > =20 > Section 8.1: I=92m not a fan of normative language in Security = Considerations. Suggest this section be moved up to a new subsection of = Section 4, or rendered non-normative. > =20 > Section A.1.2.1: Where would a na=EFve implementer find a guide to = which algorithms are considered weak? > =20 > Section A.1.2.2: Avoid use of non-normative =93should=94. > =20 > Appendix B: =93This section is non-normative=94 can be removed. = There=92s no such thing as a normative appendix. You didn=92t say it in = Appendix A, so you don=92t need to say it here. (One is also left = wondering if Appendix A is normative with this here and not there.) > =20 > Nits (these are presentation improvements only and mostly are driven = by personal preference; if you do none of these, it=92s fine with me, = but it might save the RFC Editor some work): > =20 > Section 1.1: s/the service that the key is used by/the service that = uses the key/ >=20 > Section 1.3: =93DNSSEC, which is defined in RFCs 4033, 4034, and 4035 = ([RFC4033], [RFC4034], and [RFC4035])=94 could just become =93DNSSEC, = which is defined in [RFC4033], [RFC4034], and [RFC4035]=94, as you did = in Section 1.4. > =20 > Section 1.3: s/This document only relates to securely getting the DNS = information for the certificate association using DNSSEC;/This document = only relates to getting the DNS information for the certificate = association securely using DNSSEC;/ > =20 > Section 2.1.1: s/specifying/specifies/, otherwise the surrounding text = isn=92t a sentence. The fragment would be fine if this were a bulleted = list or suchlike, but it reads awkwardly in this case. > =20 > Section 2.1.1: In the definition of usage type 2, there=92s a comma = splice. The =93for example=94 clause should be its own sentence, e.g., = =93For example, a domain name administrator would use this to indicate = that the domain issues its own=85=94 > Section 2.1.2: s/specifying/specifies/, otherwise the surrounding text = isn=92t a sentence. > =20 > Section 2.1.2: =93SubjectPublicKeyInfo=94 isn=92t defined before this = point. I suspect this is likely fine; I=92m doing this review on a = plane without access to some of the referenced RFCs, so I just want to = confirm that this isn=92t a dangling reference. > =20 > Section 2.1.3: s/specifying/specifies/, otherwise the surrounding text = isn=92t a sentence. > =20 > Section 5: s/appendixes/appendices/ >=20 > Section 5: s/to use TLSA records that are only shown to be = validated/to use only those TLSA records that are shown to be validated/ > =20 > Section 6: s/selectors type/selector types/ > =20 > Section A.1: Add a comma before =93care must be taken=94. > =20 > Section A.1.1: s/may/can/ (or =93could=94 or =93might=94) > =20 > Section A.1.1: Starting with the =93CAs frequently reissue=94 = paragraph, the section contains numerous grammatical errors. > =20 > Section A.1.2: s/for certificate/for a certificate/ > =20 > Section A.1.2.1: s/best course=85are/best course=85is/, and make the = bulleted list into a numbered list. > =20 > Section A.1.2.1: Should MD2 and MD5 be informative references? > =20 > Section A.1.2.2: s/not sharing key of/not sharing the key of/ > =20 > Section A.2.1.3: =85or the same certificate is used for all services = on a host. (Correct?) > =20 > Section A.3: s/to securely find this out/to determine this securely/ > =20 > -MSK --Apple-Mail=_E1030729-D561-4632-90CF-753B32B4CA98 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
From: "Murray S. = Kucherawy" <msk@cloudmark.com>
Subject: = AppsDir review of = draft-ietf-dane-protocol-18
Date: March 31, 2012 1:39:56 PM PDT

I have been selected = as the Applications Area Directorate reviewer for this draft (for = background on appsdir, please see  = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate<= /a>).

 

This review is being undertaken early, during AD = Evaluation but before IETF Last Call.  Please resolve these = comments along with any other pre-Last Call comments you may receive. = Please wait for direction from your document shepherd or AD before posting a new version of the draft.

 

Document: = draft-ietf-dane-protocol

Title: The = DNS-Based Authentication of Named Entities (DANE) Protocol for Transport = Layer Security (TLS)

Reviewer: = Murray S. Kucherawy

Review Date: = March 31, 2012

IETF Last Call Date: = not started

IESG Telechat Date: not = scheduled

 

Review Summary:  This draft is almost ready for = publication as an Standards Track RFC but has a few issues that should = be fixed before publication.

 

Document = Summary: The draft proposes a mechanism by which an association between = a TLS certificate and an ADMD (a domain owner or similar) can be = inferred from data found in the DNS.  That is, one could confirm = =93This key really does belong to example.com=94 by checking for = some corresponding new data in example.com=92s DNS.  The goal = appears to be to eliminate the current requirement for third-party = certificate validation.  The document is well-formed and clearly a = lot of good work has gone into it.  The IANA and Security sections are present and = well-formed.  Truly, a captivating read; I was particularly moved = by the authors=92 use of = =9330820454308202BC020900AB58D24E77AD2AF6300D06092A86=94 in Appendix = C.

 

Major Issues (things I think the WG needs to think = about, clarify, reconsider, overhaul, describe better, fret about, talk = me out of, etc.):

 

Section = 2.1.3: I don=92t know understand why this is a SHOULD.  Doesn=92t = it have to match exactly?  What=92s an example of a situation where = one could/should/would legitimately deviate from what this field says = with a meaningful result?  The pseudocode in Appendix B leaves no room for SHOULD-style evaluation, so = maybe this really ought to be a MUST.

 

Section = 10: RFC1034 and RFC1035 should be normative references, probably dragged = in very early in this document.  The examples in Section 2.3 rely = on zone file syntax defined there, and Appendix A.2 includes quite a bit = of material that requires DNS familiarity.  A reference for DNAME (I don=92t have = it handy) would probably also be a good idea, though that one could be = informative.

 

Minor Issues (things I believe can be improved = without too much effort or additional thought):

 

Section = 1.3: The lone MUST here seems out of place given that Section 1 is = =93Introduction=94.  I suspect it might belong in or near Section = 4.  It=92s also unclear to me whether you=92re repeating a = requirement of DNSSEC or declaring one imposed by the protocol this document presents.

 

Section = 1.3: The sentence at the end of the first paragraph should probably be = on its own, at the start of this section.  It should be followed by = the =93This document defines a secure method=85=94 paragraph, which also = has a very context-setting feel to it.

 

Section 2: The =93TBD=94 here might be better = replaced by a forward reference to Section 7 where that number will = presumably be assigned, so that there=92s no need to update the same = value in two places once the assignment occurs.  More on that later when I get to section 7.

 

Section = 2.1.1: Suggest the lowercase =93must=94 in the 0 definition be changed = to =93MUST=94.

 

Section = 2.1.1: Suggest the lowercase =93may=94 be changed to =93can=94 in the 1 = definition.

 

Section 2.2: Suggest stating that the unsigned = decimal integers are eight-bit unsigned decimal integers.  (I = realize this is redundant to the block diagram earlier, but since you=92re= being so precise here, you may as well be complete.)

 

Section = 2.3: Suggest adding an example that uses matching type 0 and selector = 1.


Section 2.3: The TLSA syntax in the example has me wondering of = RFC103[45] defined the space-separated integers in the zone file to do = what you=92re obviously trying to do here.  Since I=92m airborne I = don=92t have access to confirm, but I suspect you=92ve done your homework and this is fine.  It=92s just a note to me to check it = when I=92m back on the ground.

 

Section = 3: Don=92t use active voice.  Generally, instead of =93you would = use=94, say =93is used=94 or =93would be used=94.

 

Section = 4: The third paragraph is juicy insofar as I can think of other current = IETF work that might be useful to reference here.  For example, = might the domain name with which an association is established be useful = input to the Same Origin work being done in WEBSEC?  Have they talked about this?  It = might be an interesting use case to call out here or in an appendix or = some such.

 

Section 4: The fourth paragraph needs a MUST in = there somewhere, either covering the full set of steps or one for each = of them.

 

Section 4: The third item in the bulleted list is = less assertive than the other two and seems to leave things dangling a = bit.  Suggest saying explicitly that the TLS session can continue = but no positive assertion of an association can be made, or something like that.

 

Section = 4, second last paragraph: In the preceding paragraph, you direct the = client to consider the TLSA data unusable.  In this one, you direct = the client to mark it unusable.  Is there a reason for the = distinction between =93considering=94 and =93marking=94?  I don=92t know what I would do differently = here.

 

Section 4, last paragraph: Is this referring to a = TLSA query that returns multiple answers?  I think it is; just = confirming.  (You actually do answer this in the next section, I = believe.)


Section 4: The last paragraph also leaves me hanging a bit.  It = should probably say something about exactly what the meaning of a = successful match is, since you were so clear about the meanings of the = failure cases.

 

Section = 6: Do we need version numbering in the protocol anywhere, since you=92re = already anticipating a revision?  The answer might be =93no=94, = just want to make sure it got consideration.


Section 7.1: Why do the TBD thing instead of making the RRtype = assignment request now?

 

Section = 7.2: Would it be appropriate to make a DANE registry group for the work = you=92re doing in 7.2, 7.3 and 7.4?  IANA might do that = automatically, I suppose, but I thought I=92d ask = anyway.

 

Section 8, second last paragraph: A caveat about = long TTLs meaning termination of a TLSA record can take a long time to = take effect might be useful here.  (This came up in a recent SecDir = review for a draft I authored in another working group.)

 

Section 8.1: I=92m not a fan of normative language = in Security Considerations.  Suggest this section be moved up to a = new subsection of Section 4, or rendered non-normative.

 

Section = A.1.2.1: Where would a na=EFve implementer find a guide to which = algorithms are considered weak?

 

Section = A.1.2.2: Avoid use of non-normative =93should=94.

 

Appendix = B: =93This section is non-normative=94 can be removed.  There=92s = no such thing as a normative appendix.  You didn=92t say it in = Appendix A, so you don=92t need to say it here.  (One is also left = wondering if Appendix A is normative with this here and not there.)

 

Nits = (these are presentation improvements only and mostly are driven by = personal preference; if you do none of these, it=92s fine with me, but = it might save the RFC Editor some work):

 

Section = 1.1:  s/the service that the key is used by/the service that uses = the key/


Section 1.3: =93DNSSEC, which is defined in RFCs 4033, 4034, and 4035 = ([RFC4033], [RFC4034], and [RFC4035])=94 could just become =93DNSSEC, = which is defined in [RFC4033], [RFC4034], and [RFC4035]=94, as you did = in Section 1.4.

 

Section = 1.3: s/This document only relates to securely getting the DNS = information for the certificate association using DNSSEC;/This document = only relates to getting the DNS information for the certificate = association securely using DNSSEC;/

 

Section = 2.1.1: s/specifying/specifies/, otherwise the surrounding text isn=92t a = sentence.  The fragment would be fine if this were a bulleted list = or suchlike, but it reads awkwardly in this case.

 

Section = 2.1.1: In the definition of usage type 2, there=92s a comma = splice.  The =93for example=94 clause should be its own sentence, = e.g., =93For example, a domain name administrator would use this to = indicate that the domain issues its own=85=94

Section 2.1.2: = s/specifying/specifies/, otherwise the surrounding text isn=92t a = sentence.

 

Section 2.1.2: =93SubjectPublicKeyInfo=94 isn=92t = defined before this point.  I suspect this is likely fine; I=92m = doing this review on a plane without access to some of the referenced = RFCs, so I just want to confirm that this isn=92t a dangling reference.

 

Section 2.1.3: s/specifying/specifies/, otherwise = the surrounding text isn=92t a sentence.

 

Section = 5: s/appendixes/appendices/


Section 5: s/to use TLSA records that are only shown to be validated/to = use only those TLSA records that are shown to be = validated/

 

Section 6: s/selectors type/selector = types/

 

Section A.1: Add a comma before =93care must be = taken=94.

 

Section A.1.1: s/may/can/ (or =93could=94 or = =93might=94)

 

Section A.1.1: Starting with the =93CAs frequently = reissue=94 paragraph, the section contains numerous grammatical = errors.

 

Section A.1.2: s/for certificate/for a = certificate/

 

Section A.1.2.1: s/best course=85are/best = course=85is/, and make the bulleted list into a numbered = list.

 

Section A.1.2.1: Should MD2 and MD5 be informative = references?

 

Section A.1.2.2: s/not sharing key of/not sharing = the key of/

 

Section A.2.1.3: =85or the same certificate is used = for all services on a host.  (Correct?)

 

Section = A.3: s/to securely find this out/to determine this = securely/

 

-MSK


= --Apple-Mail=_E1030729-D561-4632-90CF-753B32B4CA98-- From stephen.farrell@cs.tcd.ie Sat Mar 31 17:18:10 2012 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 D755921F879B for ; Sat, 31 Mar 2012 17:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsIXVNQXf8HP for ; Sat, 31 Mar 2012 17:18:10 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C64421F879A for ; Sat, 31 Mar 2012 17:18:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id F17EF171C17 for ; Sun, 1 Apr 2012 01:18:08 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1333239488; bh=JEi68D2OFbtJ1+ro5t33fX5m pm44SMABQCKO2b59joA=; b=CnY+XRe6mXqtfaQgLAeh0GDIjwUFqd77pTOZFZ/U CA1eE0WqruoMFIoMBNhXzXUBSW8QC7WMBJrZ/6a6eh+QGWwLwuYhFawXh8djB7X6 CjEt/h8WwJwOOeN6spN3FMmc2yA1/7cm+J8wbZOePJk+woaLs/AnPG4LxvM9B55f G0j1tIgdj9GgSPoB0fXtShSZA+0Hz8CeXzq4pn9NOxpnhkXddwZCOJXsUxhOldiy F3yi3iIdOdavpEEDW8D4ONfHRAmUySmOj8LavWAuYJNhUSigJQlGTtJFjrnwqYll mUlSAkeDBv++74Lnu9u/4Hai1Dzd8RlCrcarUugjE2uRYQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 56Ni9EiwMWEU for ; Sun, 1 Apr 2012 01:18:08 +0100 (IST) Received: from [10.87.48.8] (unknown [86.42.31.132]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A5BA1171C05 for ; Sun, 1 Apr 2012 01:18:08 +0100 (IST) Message-ID: <4F779EBF.2040609@cs.tcd.ie> Date: Sun, 01 Apr 2012 01:18:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: dane Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dane] base64 vs base64url 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, 01 Apr 2012 00:18:11 -0000 (This is just a near-idle query and is definitely asked wearing no hats, AD or other. In other words, just treat it as the random query it is.) So I'm doing a thing where I need text forms of hash outputs to be URL-safe and the obvious thing to use there is a base64url encoding of the hash value. DANE uses base64 in the examples in A.2, I think for the form of encoded data that's fed in via a zone file or equivalent. That's a difference that might be annoying for me someday so I wondered: a) Does the above paragraph correctly describe what DANE does? b) Would it be right or possible or wrong or just totally stupid to make Appendix A.2 of dane-protocol use base64url? c) Even if the answer to (b) is yes, is it too late since there's code out there and this would be considered by most as being a gratuitous change? d) Regardless of (a)-(c), does dane-protocol-18 appropriately specify a format for zone files to use at the right level of detail? Thanks, S. From msk@cloudmark.com Sat Mar 31 23:33:08 2012 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 4F44821F86A5 for ; Sat, 31 Mar 2012 23:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnSUrs-eEym9 for ; Sat, 31 Mar 2012 23:33:02 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 85CA921F85C0 for ; Sat, 31 Mar 2012 23:32:59 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Sat, 31 Mar 2012 23:32:59 -0700 From: "Murray S. Kucherawy" To: IETF DANE WG list Thread-Topic: AppsDir review of draft-ietf-dane-protocol-18 Thread-Index: Ac0PZos4Ee9Go2DpTUOKvm1U+AQEwgAJq6jw Date: Sun, 1 Apr 2012 06:32:58 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C3F9E@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: multipart/mixed; boundary="_004_9452079D1A51524AA5749AD23E0039280C3F9Eexchmbx901corpclo_" MIME-Version: 1.0 Subject: [dane] FW: AppsDir review of draft-ietf-dane-protocol-18 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, 01 Apr 2012 06:33:08 -0000 --_004_9452079D1A51524AA5749AD23E0039280C3F9Eexchmbx901corpclo_ Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280C3F9Eexchmbx901corpclo_" --_000_9452079D1A51524AA5749AD23E0039280C3F9Eexchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_9452079D1A51524AA5749AD23E0039280C3F9Eexchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

--_000_9452079D1A51524AA5749AD23E0039280C3F9Eexchmbx901corpclo_-- --_004_9452079D1A51524AA5749AD23E0039280C3F9Eexchmbx901corpclo_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Sun, 01 Apr 2012 06:32:56 GMT"; modification-date="Sun, 01 Apr 2012 06:32:56 GMT" From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" , "draft-ietf-dane-protocol.all@tools.ietf.org" Subject: AppsDir review of draft-ietf-dane-protocol-18 Thread-Topic: AppsDir review of draft-ietf-dane-protocol-18 Thread-Index: Ac0PZos4Ee9Go2DpTUOKvm1U+AQEwg== Date: Sat, 31 Mar 2012 17:48:56 +0000 Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7280746968706971808068677178697276787579657267707677806_" MIME-Version: 1.0 --_000_7280746968706971808068677178697276787579657267707677806_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have been selected as the Applications Area Directorate reviewer for this= draft (for background on appsdir, please see http://trac.tools.ietf.org/a= rea/app/trac/wiki/ApplicationsAreaDirectorate). This review is being undertaken early, during AD Evaluation but before IETF= Last Call. Please resolve these comments along with any other pre-Last Ca= ll comments you may receive. Please wait for direction from your document s= hepherd or AD before posting a new version of the draft. Document: draft-ietf-dane-protocol Title: The DNS-Based Authentication of Named Entities (DANE) Protocol for T= ransport Layer Security (TLS) Reviewer: Murray S. Kucherawy Review Date: March 31, 2012 IETF Last Call Date: not started IESG Telechat Date: not scheduled Review Summary: This draft is almost ready for publication as an Standards= Track RFC but has a few issues that should be fixed before publication. Document Summary: The draft proposes a mechanism by which an association be= tween a TLS certificate and an ADMD (a domain owner or similar) can be infe= rred from data found in the DNS. That is, one could confirm "This key real= ly does belong to example.com" by checking for some corresponding new data = in example.com's DNS. The goal appears to be to eliminate the current requ= irement for third-party certificate validation. The document is well-forme= d and clearly a lot of good work has gone into it. The IANA and Security s= ections are present and well-formed. Truly, a captivating read; I was part= icularly moved by the authors' use of "30820454308202BC020900AB58D24E77AD2A= F6300D06092A86" in Appendix C. Major Issues (things I think the WG needs to think about, clarify, reconsid= er, overhaul, describe better, fret about, talk me out of, etc.): Section 2.1.3: I don't know understand why this is a SHOULD. Doesn't it ha= ve to match exactly? What's an example of a situation where one could/shou= ld/would legitimately deviate from what this field says with a meaningful r= esult? The pseudocode in Appendix B leaves no room for SHOULD-style evalua= tion, so maybe this really ought to be a MUST. Section 10: RFC1034 and RFC1035 should be normative references, probably dr= agged in very early in this document. The examples in Section 2.3 rely on = zone file syntax defined there, and Appendix A.2 includes quite a bit of ma= terial that requires DNS familiarity. A reference for DNAME (I don't have = it handy) would probably also be a good idea, though that one could be info= rmative. Minor Issues (things I believe can be improved without too much effort or a= dditional thought): Section 1.3: The lone MUST here seems out of place given that Section 1 is = "Introduction". I suspect it might belong in or near Section 4. It's also= unclear to me whether you're repeating a requirement of DNSSEC or declarin= g one imposed by the protocol this document presents. Section 1.3: The sentence at the end of the first paragraph should probably= be on its own, at the start of this section. It should be followed by the= "This document defines a secure method..." paragraph, which also has a ver= y context-setting feel to it. Section 2: The "TBD" here might be better replaced by a forward reference t= o Section 7 where that number will presumably be assigned, so that there's = no need to update the same value in two places once the assignment occurs. = More on that later when I get to section 7. Section 2.1.1: Suggest the lowercase "must" in the 0 definition be changed = to "MUST". Section 2.1.1: Suggest the lowercase "may" be changed to "can" in the 1 def= inition. Section 2.2: Suggest stating that the unsigned decimal integers are eight-b= it unsigned decimal integers. (I realize this is redundant to the block di= agram earlier, but since you're being so precise here, you may as well be c= omplete.) Section 2.3: Suggest adding an example that uses matching type 0 and select= or 1. Section 2.3: The TLSA syntax in the example has me wondering of RFC103[45] = defined the space-separated integers in the zone file to do what you're obv= iously trying to do here. Since I'm airborne I don't have access to confir= m, but I suspect you've done your homework and this is fine. It's just a n= ote to me to check it when I'm back on the ground. Section 3: Don't use active voice. Generally, instead of "you would use", = say "is used" or "would be used". Section 4: The third paragraph is juicy insofar as I can think of other cur= rent IETF work that might be useful to reference here. For example, might = the domain name with which an association is established be useful input to= the Same Origin work being done in WEBSEC? Have they talked about this? = It might be an interesting use case to call out here or in an appendix or s= ome such. Section 4: The fourth paragraph needs a MUST in there somewhere, either cov= ering the full set of steps or one for each of them. Section 4: The third item in the bulleted list is less assertive than the o= ther two and seems to leave things dangling a bit. Suggest saying explicit= ly that the TLS session can continue but no positive assertion of an associ= ation can be made, or something like that. Section 4, second last paragraph: In the preceding paragraph, you direct th= e client to consider the TLSA data unusable. In this one, you direct the c= lient to mark it unusable. Is there a reason for the distinction between "= considering" and "marking"? I don't know what I would do differently here. Section 4, last paragraph: Is this referring to a TLSA query that returns m= ultiple answers? I think it is; just confirming. (You actually do answer = this in the next section, I believe.) Section 4: The last paragraph also leaves me hanging a bit. It should prob= ably say something about exactly what the meaning of a successful match is,= since you were so clear about the meanings of the failure cases. Section 6: Do we need version numbering in the protocol anywhere, since you= 're already anticipating a revision? The answer might be "no", just want t= o make sure it got consideration. Section 7.1: Why do the TBD thing instead of making the RRtype assignment r= equest now? Section 7.2: Would it be appropriate to make a DANE registry group for the = work you're doing in 7.2, 7.3 and 7.4? IANA might do that automatically, I= suppose, but I thought I'd ask anyway. Section 8, second last paragraph: A caveat about long TTLs meaning terminat= ion of a TLSA record can take a long time to take effect might be useful he= re. (This came up in a recent SecDir review for a draft I authored in anot= her working group.) Section 8.1: I'm not a fan of normative language in Security Considerations= . Suggest this section be moved up to a new subsection of Section 4, or re= ndered non-normative. Section A.1.2.1: Where would a na=EFve implementer find a guide to which al= gorithms are considered weak? Section A.1.2.2: Avoid use of non-normative "should". Appendix B: "This section is non-normative" can be removed. There's no suc= h thing as a normative appendix. You didn't say it in Appendix A, so you d= on't need to say it here. (One is also left wondering if Appendix A is nor= mative with this here and not there.) Nits (these are presentation improvements only and mostly are driven by per= sonal preference; if you do none of these, it's fine with me, but it might = save the RFC Editor some work): Section 1.1: s/the service that the key is used by/the service that uses t= he key/ Section 1.3: "DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC40= 33], [RFC4034], and [RFC4035])" could just become "DNSSEC, which is defined= in [RFC4033], [RFC4034], and [RFC4035]", as you did in Section 1.4. Section 1.3: s/This document only relates to securely getting the DNS infor= mation for the certificate association using DNSSEC;/This document only rel= ates to getting the DNS information for the certificate association securel= y using DNSSEC;/ Section 2.1.1: s/specifying/specifies/, otherwise the surrounding text isn'= t a sentence. The fragment would be fine if this were a bulleted list or s= uchlike, but it reads awkwardly in this case. Section 2.1.1: In the definition of usage type 2, there's a comma splice. = The "for example" clause should be its own sentence, e.g., "For example, a = domain name administrator would use this to indicate that the domain issues= its own..." Section 2.1.2: s/specifying/specifies/, otherwise the surrounding text isn'= t a sentence. Section 2.1.2: "SubjectPublicKeyInfo" isn't defined before this point. I s= uspect this is likely fine; I'm doing this review on a plane without access= to some of the referenced RFCs, so I just want to confirm that this isn't = a dangling reference. Section 2.1.3: s/specifying/specifies/, otherwise the surrounding text isn'= t a sentence. Section 5: s/appendixes/appendices/ Section 5: s/to use TLSA records that are only shown to be validated/to use= only those TLSA records that are shown to be validated/ Section 6: s/selectors type/selector types/ Section A.1: Add a comma before "care must be taken". Section A.1.1: s/may/can/ (or "could" or "might") Section A.1.1: Starting with the "CAs frequently reissue" paragraph, the se= ction contains numerous grammatical errors. Section A.1.2: s/for certificate/for a certificate/ Section A.1.2.1: s/best course...are/best course...is/, and make the bullet= ed list into a numbered list. Section A.1.2.1: Should MD2 and MD5 be informative references? Section A.1.2.2: s/not sharing key of/not sharing the key of/ Section A.2.1.3: ...or the same certificate is used for all services on a h= ost. (Correct?) Section A.3: s/to securely find this out/to determine this securely/ -MSK --_000_7280746968706971808068677178697276787579657267707677806_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have been selected as the Applications Area Direct= orate reviewer for this draft (for background on appsdir, please see  http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

 

This review is being undertaken early, during AD Eva= luation but before IETF Last Call.  Please resolve these comments alon= g with any other pre-Last Call comments you may receive. Please wait for di= rection from your document shepherd or AD before posting a new version of the draft.

 

Document: draft-ietf-dane-protocol

Title: The DNS-Based Authentication of Named Entitie= s (DANE) Protocol for Transport Layer Security (TLS)

Reviewer: Murray S. Kucherawy

Review Date: March 31, 2012

IETF Last Call Date: not started

IESG Telechat Date: not scheduled

 

Review Summary:  This draft is almost ready for= publication as an Standards Track RFC but has a few issues that should be = fixed before publication.

 

Document Summary: The draft proposes a mechanism by = which an association between a TLS certificate and an ADMD (a domain owner = or similar) can be inferred from data found in the DNS.  That is, one = could confirm “This key really does belong to example.com” by checking for some corresponding new data in examp= le.com’s DNS.  The goal appears to be to eliminate the current r= equirement for third-party certificate validation.  The document is we= ll-formed and clearly a lot of good work has gone into it.  The IANA and Security sections are present and well-formed. = ; Truly, a captivating read; I was particularly moved by the authors’= use of “30820454308202BC020900AB58D24E77AD2AF6300D06092A86” in= Appendix C.

 

Major Issues (things I think the WG needs to think a= bout, clarify, reconsider, overhaul, describe better, fret about, talk me o= ut of, etc.):

 

Section 2.1.3: I don’t know understand why thi= s is a SHOULD.  Doesn’t it have to match exactly?  WhatR= 17;s an example of a situation where one could/should/would legitimately de= viate from what this field says with a meaningful result?  The pseudocode in Appendix B leaves no room for SHOULD-style evaluation, so ma= ybe this really ought to be a MUST.

 

Section 10: RFC1034 and RFC1035 should be normative = references, probably dragged in very early in this document.  The exam= ples in Section 2.3 rely on zone file syntax defined there, and Appendix A.= 2 includes quite a bit of material that requires DNS familiarity.  A reference for DNAME (I don’t have = it handy) would probably also be a good idea, though that one could be info= rmative.

 

Minor Issues (things I believe can be improved witho= ut too much effort or additional thought):

 

Section 1.3: The lone MUST here seems out of place g= iven that Section 1 is “Introduction”.  I suspect it might= belong in or near Section 4.  It’s also unclear to me whether y= ou’re repeating a requirement of DNSSEC or declaring one imposed by the protocol this document presents.

 

Section 1.3: The sentence at the end of the first pa= ragraph should probably be on its own, at the start of this section.  = It should be followed by the “This document defines a secure method&#= 8230;” paragraph, which also has a very context-setting feel to it.

 

Section 2: The “TBD” here might be bette= r replaced by a forward reference to Section 7 where that number will presu= mably be assigned, so that there’s no need to update the same value i= n two places once the assignment occurs.  More on that later when I get to section 7.

 

Section 2.1.1: Suggest the lowercase “mustR= 21; in the 0 definition be changed to “MUST”.

 

Section 2.1.1: Suggest the lowercase “may̶= 1; be changed to “can” in the 1 definition.

 

Section 2.2: Suggest stating that the unsigned decim= al integers are eight-bit unsigned decimal integers.  (I realize this = is redundant to the block diagram earlier, but since you’re being so = precise here, you may as well be complete.)

 

Section 2.3: Suggest adding an example that uses mat= ching type 0 and selector 1.


Section 2.3: The TLSA syntax in the example has me wondering of RFC103[45] = defined the space-separated integers in the zone file to do what you’= re obviously trying to do here.  Since I’m airborne I don’= t have access to confirm, but I suspect you’ve done your homework and this is fine.  It’s just a note to me to check it = when I’m back on the ground.

 

Section 3: Don’t use active voice.  Gener= ally, instead of “you would use”, say “is used” or = “would be used”.

 

Section 4: The third paragraph is juicy insofar as I= can think of other current IETF work that might be useful to reference her= e.  For example, might the domain name with which an association is es= tablished be useful input to the Same Origin work being done in WEBSEC?  Have they talked about this?  It mig= ht be an interesting use case to call out here or in an appendix or some su= ch.

 

Section 4: The fourth paragraph needs a MUST in ther= e somewhere, either covering the full set of steps or one for each of them.=

 

Section 4: The third item in the bulleted list is le= ss assertive than the other two and seems to leave things dangling a bit.&n= bsp; Suggest saying explicitly that the TLS session can continue but no pos= itive assertion of an association can be made, or something like that.

 

Section 4, second last paragraph: In the preceding p= aragraph, you direct the client to consider the TLSA data unusable.  I= n this one, you direct the client to mark it unusable.  Is there a rea= son for the distinction between “considering” and “marking”?  I don’t know what I would do differ= ently here.

 

Section 4, last paragraph: Is this referring to a TL= SA query that returns multiple answers?  I think it is; just confirmin= g.  (You actually do answer this in the next section, I believe.)=


Section 4: The last paragraph also leaves me hanging a bit.  It should= probably say something about exactly what the meaning of a successful matc= h is, since you were so clear about the meanings of the failure cases.=

 

Section 6: Do we need version numbering in the proto= col anywhere, since you’re already anticipating a revision?  The= answer might be “no”, just want to make sure it got considerat= ion.


Section 7.1: Why do the TBD thing instead of making the RRtype assignment r= equest now?

 

Section 7.2: Would it be appropriate to make a DANE = registry group for the work you’re doing in 7.2, 7.3 and 7.4?  I= ANA might do that automatically, I suppose, but I thought I’d ask any= way.

 

Section 8, second last paragraph: A caveat about lon= g TTLs meaning termination of a TLSA record can take a long time to take ef= fect might be useful here.  (This came up in a recent SecDir review fo= r a draft I authored in another working group.)

 

Section 8.1: I’m not a fan of normative langua= ge in Security Considerations.  Suggest this section be moved up to a = new subsection of Section 4, or rendered non-normative.

 

Section A.1.2.1: Where would a na=EFve implementer f= ind a guide to which algorithms are considered weak?

 

Section A.1.2.2: Avoid use of non-normative “s= hould”.

 

Appendix B: “This section is non-normativeR= 21; can be removed.  There’s no such thing as a normative append= ix.  You didn’t say it in Appendix A, so you don’t need to= say it here.  (One is also left wondering if Appendix A is normative = with this here and not there.)

 

Nits (these are presentation improvements only and m= ostly are driven by personal preference; if you do none of these, it’= s fine with me, but it might save the RFC Editor some work):

 

Section 1.1:  s/the service that the key is use= d by/the service that uses the key/


Section 1.3: “DNSSEC, which is defined in RFCs 4033, 4034, and 4035 (= [RFC4033], [RFC4034], and [RFC4035])” could just become “DNSSEC= , which is defined in [RFC4033], [RFC4034], and [RFC4035]”, as you di= d in Section 1.4.

 

Section 1.3: s/This document only relates to securel= y getting the DNS information for the certificate association using DNSSEC;= /This document only relates to getting the DNS information for the certific= ate association securely using DNSSEC;/

 

Section 2.1.1: s/specifying/specifies/, otherwise th= e surrounding text isn’t a sentence.  The fragment would be fine= if this were a bulleted list or suchlike, but it reads awkwardly in this c= ase.

 

Section 2.1.1: In the definition of usage type 2, th= ere’s a comma splice.  The “for example” clause shou= ld be its own sentence, e.g., “For example, a domain name administrat= or would use this to indicate that the domain issues its own…”<= o:p>

Section 2.1.2: s/specifying/specifies/, otherwise th= e surrounding text isn’t a sentence.

 

Section 2.1.2: “SubjectPublicKeyInfo” is= n’t defined before this point.  I suspect this is likely fine; I= ’m doing this review on a plane without access to some of the referen= ced RFCs, so I just want to confirm that this isn’t a dangling reference.

 

Section 2.1.3: s/specifying/specifies/, otherwise th= e surrounding text isn’t a sentence.

 

Section 5: s/appendixes/appendices/


Section 5: s/to use TLSA records that are only shown to be validated/to use= only those TLSA records that are shown to be validated/

 

Section 6: s/selectors type/selector types/

 

Section A.1: Add a comma before “care must be = taken”.

 

Section A.1.1: s/may/can/ (or “could” or= “might”)

 

Section A.1.1: Starting with the “CAs frequent= ly reissue” paragraph, the section contains numerous grammatical erro= rs.

 

Section A.1.2: s/for certificate/for a certificate/<= o:p>

 

Section A.1.2.1: s/best course…are/best course= …is/, and make the bulleted list into a numbered list.

 

Section A.1.2.1: Should MD2 and MD5 be informative r= eferences?

 

Section A.1.2.2: s/not sharing key of/not sharing th= e key of/

 

Section A.2.1.3: …or the same certificate is u= sed for all services on a host.  (Correct?)

 

Section A.3: s/to securely find this out/to determin= e this securely/

 

-MSK

--_000_7280746968706971808068677178697276787579657267707677806_-- --_004_9452079D1A51524AA5749AD23E0039280C3F9Eexchmbx901corpclo_--