From christopher.morrow@gmail.com Tue May 3 20:41:32 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E8CE06C8 for ; Tue, 3 May 2011 20:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuWmk0z6BINH for ; Tue, 3 May 2011 20:41:31 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C624E06AD for ; Tue, 3 May 2011 20:41:28 -0700 (PDT) Received: by wyb29 with SMTP id 29so597959wyb.31 for ; Tue, 03 May 2011 20:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QTdLQg4QAgyQmSYPJkg3PWo5zA2jn98KCk/K63vo49k=; b=dANlfvsE1kyi+qGXp2b8yr+b+53TpaioiuCXkj1E2PyyHjE1mbaJAknUPdkKsfUs3b vAzJvDAmvqgAINORf0/FrMvGphviSKUc990QNe6S8LBvQrQVzpv7WKzfznHv/mYF+EIP YupVhjqnXL6QIb243yOyE3nuv5FJVvCm0RiUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=CpjZrBFSxypMV/P/yHsSzJvHgXN/6cQOtTfUy3gZ2T8qDXrFQz4A7Hg/66jk2hzq6a ft69jhGlv0Nk+kCpuPtFZtA05ItXsXCVeNQH5L3DLCMvf9k7TqEtOq+CZE3G0K0kyUEw X/7smzFG7FH2rGwAIgdZc8drkahAJ1HEFbD40= MIME-Version: 1.0 Received: by 10.216.158.131 with SMTP id q3mr4278566wek.99.1304480487302; Tue, 03 May 2011 20:41:27 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.241.136 with HTTP; Tue, 3 May 2011 20:41:27 -0700 (PDT) In-Reply-To: References: <1302734872.1842.78.camel@localhost> Date: Tue, 3 May 2011 23:41:27 -0400 X-Google-Sender-Auth: OCFRiWZj3M77CmZ81N2vpk3iAXQ Message-ID: From: Christopher Morrow To: Paul Wouters Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: kirk@affirmtrust.com, dane@ietf.org Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 03:41:32 -0000 first, apologies for lobbing a grenade ~1month ago and getting busy with work instead of this discussion... On Thu, Apr 14, 2011 at 11:50 PM, Paul Wouters wrote: >> I=92m quite certain this will be DANE=92s fate among browsers and other >> consumer facing applications for self-signed certs, unless DANE builds i= nto >> its specs some way to >> distinguish self-signed certs that have gone through an anti-fraud check >> from those that have not. > > fraud detection is really out of scope for dane (both the working group > and the protocol) It is indeed a real problem that needs to be solved. Bu= t > no easy solution exists that will work for every domain. I think this is the central point of the entire discussion about self-signed certs and DANE, and really about DANE as a whole. the point is NOT about fraud. I said something a few messages ago (to DANE, which I recognize is ~1month ago...) along the lines of: I really want a way for a client to validate that the serivce they connect to (https on www.you.com for example) is: 1) the server the service owner expected (and the cusotmer expects) 2) the service is what the service owner setup (and the customer expects) (ref: http://www.ietf.org/mail-archive/web/dane/current/msg02390.html) Thanks Kirk for restarting the discussion. -Chris From ynir@checkpoint.com Tue May 3 22:47:39 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886A1E06E6 for ; Tue, 3 May 2011 22:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.709 X-Spam-Level: X-Spam-Status: No, score=-7.709 tagged_above=-999 required=5 tests=[AWL=2.890, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXdCHf4UXFGW for ; Tue, 3 May 2011 22:47:38 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 516BCE06A1 for ; Tue, 3 May 2011 22:47:37 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p445lZ77024896; Wed, 4 May 2011 08:47:35 +0300 X-CheckPoint: {4DC0F5B2-0-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 4 May 2011 08:47:35 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 4 May 2011 08:47:35 +0300 From: Yoav Nir To: "dane@ietf.org" Date: Wed, 4 May 2011 08:47:33 +0300 Thread-Topic: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE Thread-Index: AcwKHsRRFjvkCeq0R+iBiVyEpXfYYQ== Message-ID: <0AC330D6-632A-4300-968F-F8B164A82E50@checkpoint.com> References: <1302734872.1842.78.camel@localhost> 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 05:47:39 -0000 On May 4, 2011, at 6:41 AM, Christopher Morrow wrote: > first, apologies for lobbing a grenade ~1month ago and getting busy > with work instead of this discussion... >=20 > On Thu, Apr 14, 2011 at 11:50 PM, Paul Wouters wrote= : >>> I=92m quite certain this will be DANE=92s fate among browsers and other >>> consumer facing applications for self-signed certs, unless DANE builds = into >>> its specs some way to >>> distinguish self-signed certs that have gone through an anti-fraud chec= k >>> from those that have not. >>=20 >> fraud detection is really out of scope for dane (both the working group >> and the protocol) It is indeed a real problem that needs to be solved. B= ut >> no easy solution exists that will work for every domain. >=20 > I think this is the central point of the entire discussion about > self-signed certs and DANE, and really about DANE as a whole. the > point is NOT about fraud. I said something a few messages ago (to > DANE, which I recognize is ~1month ago...) along the lines of: >=20 > I really want a way for a client to validate > that the serivce they connect to (https on www.you.com for example) > is: > 1) the server the service owner expected (and the cusotmer expects) > 2) the service is what the service owner setup (and the customer expects) >=20 > (ref: http://www.ietf.org/mail-archive/web/dane/current/msg02390.html) >=20 I think we'll find that just like in PKIX, it's all about the infrastructur= e. If you own www.you.com and your customer knows this, then you can get both = (1) and (2) only if both these conditions apply: 1) The DNS replies cannot be spoofed, and 2) Entering records in the DNS is not susceptible to fraud. DNSSEC may provide the former at some point. I don't think DANE should ever= be used for domain-issued certificates without DNSSEC. The latter is a harder question. If you're google, then you enter your own = DNS records, but smaller organizations use some service like GoDaddy to reg= ister the domain, add DNS records and everything else required to get a nam= e for your server on the Internet. If I can get GoDaddy to add the records = for www.you.com, it's as bad as Comodo issuing me a cert for www.you.com.=20 From christopher.morrow@gmail.com Tue May 3 22:56:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955EBE06EF for ; Tue, 3 May 2011 22:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1s6MujDJZ1c1 for ; Tue, 3 May 2011 22:55:53 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 29C09E06E6 for ; Tue, 3 May 2011 22:55:52 -0700 (PDT) Received: by wyb29 with SMTP id 29so648338wyb.31 for ; Tue, 03 May 2011 22:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6ec8/vhtfWcw4ZbPoGCkpcUI3vHAkGfFeQXsT2MzBhU=; b=gS05lJubO1u1vrTxf4inEZzIA9wOIqL5GUf2ovGKaCQvlMMOTp82IpHNq0dM2cBArX ZyWw6S8nvOpiZvcAN0nzUDb4fPNK2ElcIShaW4MK/9/4D0h9uTixIpIxdIXxwxAIexL6 WH5jwLnh0P6OSULhDxAF5aHSHKclh7q4WIYRE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=SEbLvwA2BBJXr8YUkpwt2G9YJEBB0G5S6J8eZVyGe+S1k1hlpggGncOFxGnwolNt1m EO+Wqnkf5mjq+rOta5F5gIMQHr28PRopjQ2NGW4UmjIxIDHBWPZmgAxpu9NLgdI2BCT8 ckNzxUuRN5T2n+pEA3LGW+/GGDW2tteHhOw4c= MIME-Version: 1.0 Received: by 10.216.82.142 with SMTP id o14mr616960wee.114.1304488550057; Tue, 03 May 2011 22:55:50 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.241.136 with HTTP; Tue, 3 May 2011 22:55:50 -0700 (PDT) In-Reply-To: <83BE20C5-6392-4581-864E-302941DBF862@kumari.net> References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <83BE20C5-6392-4581-864E-302941DBF862@kumari.net> Date: Wed, 4 May 2011 01:55:50 -0400 X-Google-Sender-Auth: m3KGKwMGQgHYCLNvHry9pTMHfXo Message-ID: From: Christopher Morrow To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 04 May 2011 05:56:11 -0000 On Sat, Apr 30, 2011 at 9:24 PM, Warren Kumari wrote: > > On Apr 29, 2011, at 12:03 PM, Warren Kumari wrote: > >> Hi all, >> >> I think that Richard has integrated most of the comments received on-lis= t into this most recent version of the doc and so, as I mentioned, we are g= oing to kick off WGLC... >> >> Please get y'er comments in -- =A0WGLC will be closing on 2011-05-13 at = 16:00UTC (noonish EDT). failing another place to ask/point-this-out, in reading the doc I noticed t= his: "3.3. Domain-Issued Certificates Alice would like to be able to use generate and use certificates for her website on alice.example.com without involving an external CA at all. " The first sentence is a tad odd... 'to use generate and use certificates for" ... probably some other sentence fragment belongs there. -chris (more when more rested) From christopher.morrow@gmail.com Tue May 3 23:03:02 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B806AE0720 for ; Tue, 3 May 2011 23:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id On48vBtXtb0S for ; Tue, 3 May 2011 23:03:02 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0731E0716 for ; Tue, 3 May 2011 23:03:01 -0700 (PDT) Received: by wwa36 with SMTP id 36so575626wwa.13 for ; Tue, 03 May 2011 23:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vfuxj0eSnvrhyjzvCpJcwTWZKdXUN1zfHA65pmLI+Tc=; b=svxarEeqMpR7zQtvsS+FFWQm1IAUY/eFU7gHmFABYalqhdViV0iKz565Go+XetvcP8 FapIH+O0LKGOtOJ+yrob5Nbe4MiC5v/rdiY+Ob6eXtSLvY2+h0M7ZVily2M+Yf4zjxk3 asJfhaM73LpLME1oHAVQo0sogCn9r3dC7VBXQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=PeKVUxUI1lxdPyN6f7Nhk/SPKvKQ6Yw4hdY99MNL9HZE6ChVSyXeWPxw+jvwcDdnXa 83FFkiFd3vSfNK+Wfwcp8UXe0Gi41wcP8FlaCRXYH82c4XGCN9QJ536J75e/5cNHYX4i xp43YByiKCZGSTrqjP12RZvstbQsEw5j0Ilzw= MIME-Version: 1.0 Received: by 10.216.240.202 with SMTP id e52mr1820649wer.84.1304488980743; Tue, 03 May 2011 23:03:00 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.241.136 with HTTP; Tue, 3 May 2011 23:03:00 -0700 (PDT) In-Reply-To: <0AC330D6-632A-4300-968F-F8B164A82E50@checkpoint.com> References: <1302734872.1842.78.camel@localhost> <0AC330D6-632A-4300-968F-F8B164A82E50@checkpoint.com> Date: Wed, 4 May 2011 02:03:00 -0400 X-Google-Sender-Auth: ddq8jMQz5FYeg_zHhFeNWqplfqo Message-ID: From: Christopher Morrow To: Yoav Nir Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "dane@ietf.org" Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 06:03:02 -0000 On Wed, May 4, 2011 at 1:47 AM, Yoav Nir wrote: > > On May 4, 2011, at 6:41 AM, Christopher Morrow wrote: > >> first, apologies for lobbing a grenade ~1month ago and getting busy >> with work instead of this discussion... >> >> On Thu, Apr 14, 2011 at 11:50 PM, Paul Wouters wrot= e: >>>> I=92m quite certain this will be DANE=92s fate among browsers and othe= r >>>> consumer facing applications for self-signed certs, unless DANE builds= into >>>> its specs some way to >>>> distinguish self-signed certs that have gone through an anti-fraud che= ck >>>> from those that have not. >>> >>> fraud detection is really out of scope for dane (both the working group >>> and the protocol) It is indeed a real problem that needs to be solved. = But >>> no easy solution exists that will work for every domain. >> >> I think this is the central point of the entire discussion about >> self-signed certs and DANE, and really about DANE as a whole. the >> point is NOT about fraud. I said something a few messages ago (to >> DANE, which I recognize is ~1month ago...) along the lines of: >> >> I really want a way for a client to validate >> that the serivce they connect to (https on www.you.com for example) >> is: >> 1) the server the service owner expected (and the cusotmer expects) >> 2) the service is what the service owner setup (and the customer expects= ) >> >> (ref: http://www.ietf.org/mail-archive/web/dane/current/msg02390.html) >> > > I think we'll find that just like in PKIX, it's all about the infrastruct= ure. > > If you own www.you.com and your customer knows this, then you can get bot= h (1) and (2) only if both these conditions apply: > 1) The DNS replies cannot be spoofed, and > 2) Entering records in the DNS is not susceptible to fraud. > > DNSSEC may provide the former at some point. I don't think DANE should ev= er be used for domain-issued certificates without DNSSEC. agreed... or 'use of dane implies dnssec is in use as well' > The latter is a harder question. If you're google, then you enter your ow= n DNS records, but smaller organizations use some service like GoDaddy to r= egister the domain, add DNS records and everything else required to get a n= ame for your server on the Internet. If I can get GoDaddy to add the record= s for www.you.com, it's as bad as Comodo issuing me a cert for www.you.com. > sure, but ... I'm sure that eventually dns service providers (go-daddy/etc) will have to pony up for some real infrastructure to support dnssec. pch does this for ~2k/deployment (I think... bill had some slides at caribnog ~2wks ago that talked about this very problem, actually). For GoDaddy/etc it's not that hard to implement some secure interfaces/apis and the backend bits required. They may not do this TODAY, but they will be driven there by market pressures in the future. (which seems fine to me) -Chris From rbarnes@bbn.com Wed May 4 00:06:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B95E0764 for ; Wed, 4 May 2011 00:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.669 X-Spam-Level: X-Spam-Status: No, score=-104.669 tagged_above=-999 required=5 tests=[AWL=1.930, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktewYNGEPUXs for ; Wed, 4 May 2011 00:06:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D4D2FE0756 for ; Wed, 4 May 2011 00:06:43 -0700 (PDT) Received: from [128.89.254.137] (port=54042 helo=[192.168.50.151]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QHWAT-0007fi-QM; Wed, 04 May 2011 03:06:42 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 4 May 2011 09:06:39 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <83BE20C5-6392-4581-864E-302941DBF862@kumari.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1082) Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 04 May 2011 07:06:44 -0000 > "3.3. Domain-Issued Certificates > > Alice would like to be able to use generate and use certificates for > her website on alice.example.com without involving an external CA at > all. " > > The first sentence is a tad odd... 'to use generate and use > certificates for" ... probably some other sentence fragment belongs > there. Thanks, I've fixed this in my working copy. Looking forward to the rest, --Richard From rbarnes@bbn.com Wed May 4 00:14:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC17E0736 for ; Wed, 4 May 2011 00:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.757 X-Spam-Level: X-Spam-Status: No, score=-104.757 tagged_above=-999 required=5 tests=[AWL=1.842, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PdrEjhuoNOR for ; Wed, 4 May 2011 00:14:10 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A5303E0709 for ; Wed, 4 May 2011 00:14:10 -0700 (PDT) Received: from [128.89.254.137] (port=54117 helo=[192.168.50.151]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QHWHi-0007hd-0F; Wed, 04 May 2011 03:14:10 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <0AC330D6-632A-4300-968F-F8B164A82E50@checkpoint.com> Date: Wed, 4 May 2011 09:14:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0E21F266-ED68-4FEB-8E09-EC50C1F624CF@bbn.com> References: <1302734872.1842.78.camel@localhost> <0AC330D6-632A-4300-968F-F8B164A82E50@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1082) Cc: "dane@ietf.org" Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 07:14:11 -0000 > If I can get GoDaddy to add the records for www.you.com, it's as bad = as Comodo issuing me a cert for www.you.com.=20 =46rom the perspective of risks to www.you.com, that's true. It's = better than the traditional CAs (including Comodo) in the sense that = GoDaddy is restricted to abusing their customers and not the whole DNS. --Richard= From rbarnes@bbn.com Wed May 4 00:25:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D45E0765 for ; Wed, 4 May 2011 00:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.837 X-Spam-Level: X-Spam-Status: No, score=-104.837 tagged_above=-999 required=5 tests=[AWL=1.762, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9+fmpdk2vua for ; Wed, 4 May 2011 00:25:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D4D31E0691 for ; Wed, 4 May 2011 00:25:55 -0700 (PDT) Received: from [128.89.254.137] (port=54215 helo=[192.168.50.151]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QHWT4-0007kK-Dg; Wed, 04 May 2011 03:25:54 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 4 May 2011 09:25:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8C2A8492-DDF9-4A4B-B60D-1798EDCC2121@bbn.com> References: <1302734872.1842.78.camel@localhost> <0AC330D6-632A-4300-968F-F8B164A82E50@checkpoint.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1082) Cc: "dane@ietf.org" Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 07:25:57 -0000 >> The latter is a harder question. If you're google, then you enter = your own DNS records, but smaller organizations use some service like = GoDaddy to register the domain, add DNS records and everything else = required to get a name for your server on the Internet. If I can get = GoDaddy to add the records for www.you.com, it's as bad as Comodo = issuing me a cert for www.you.com. >>=20 >=20 > sure, but ... I'm sure that eventually dns service providers > (go-daddy/etc) will have to pony up for some real infrastructure to > support dnssec. pch does this for ~2k/deployment (I think... bill had > some slides at caribnog ~2wks ago that talked about this very problem, > actually). For GoDaddy/etc it's not that hard to implement some secure > interfaces/apis and the backend bits required. They may not do this > TODAY, but they will be driven there by market pressures in the > future. (which seems fine to me) To be clear, there's two attack vectors here: 1. Abuse by people masquerading as a domain owner 2. Abuse by the registrar itself The former is what you're talking about (if I understand you correctly); = the latter is the Comodo-like case that Yoav mentioned, which isn't = really helped by more infrastructure. --Richard From hallam@gmail.com Wed May 4 06:10:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7EBE06A4 for ; Wed, 4 May 2011 06:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.024 X-Spam-Level: X-Spam-Status: No, score=-3.024 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkSeqz8U5iO2 for ; Wed, 4 May 2011 06:09:58 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 371CCE06D8 for ; Wed, 4 May 2011 06:09:58 -0700 (PDT) Received: by gwb20 with SMTP id 20so454210gwb.31 for ; Wed, 04 May 2011 06:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BKXqcsvGASKec3Y71tJvab6R2hdyARsyrjexIOok5yo=; b=pTVHiydAfmXvO2Xr3grL0fmbK33uytnLv6T2urQwWGU+Dv67/RsSKeS50dPqotYd4H qVGYzTZMyFxr4kaV8kEUozvJHfEWBsHJbkJjupYoTcUSvC0bEj39XsB6hzmXc711YM8t a3MUpoEvKbWpRU7cUQ4pOHvSmg5rmoZLuqLWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CjblSRhFJKlIBXRyl3UBL2kdog+uWjusph0vZI8ByKuXXTUrXTD0cIhBepcYVw7KOL NLAI9xumKc93RxhrUwEiTnAVXECgVmKJ2VcVUCvJctvqCftczv/dJb4VHZE9aFauZsZ3 Hc0qn4JrDY9/jUbsUwxQvxQMuVfVSg2wDPv8Y= MIME-Version: 1.0 Received: by 10.100.229.2 with SMTP id b2mr690152anh.72.1304514597433; Wed, 04 May 2011 06:09:57 -0700 (PDT) Received: by 10.100.178.6 with HTTP; Wed, 4 May 2011 06:09:57 -0700 (PDT) In-Reply-To: <0E21F266-ED68-4FEB-8E09-EC50C1F624CF@bbn.com> References: <1302734872.1842.78.camel@localhost> <0AC330D6-632A-4300-968F-F8B164A82E50@checkpoint.com> <0E21F266-ED68-4FEB-8E09-EC50C1F624CF@bbn.com> Date: Wed, 4 May 2011 09:09:57 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=001636af02d72f319c04a272f944 Cc: "dane@ietf.org" Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 13:10:16 -0000 --001636af02d72f319c04a272f944 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 4, 2011 at 3:14 AM, Richard L. Barnes wrote: > > If I can get GoDaddy to add the records for www.you.com, it's as bad as > Comodo issuing me a cert for www.you.com. > > From the perspective of risks to www.you.com, that's true. It's better > than the traditional CAs (including Comodo) in the sense that GoDaddy is > restricted to abusing their customers and not the whole DNS. You think that is really the case? I would like to see proof of that assertion. I know that there is a domain locking system, but I have no idea how it is enforced and have never seen documentation. I would not expect the locking mechanism to be particularly strong since (1) the thin registry has very little information to go on (2) any malicious behavior can be reversed out easily (3) registrars have a large incentive not to defect. Fraudulent issue of certificates has been a much much rarer occurrence than DNS name hijacking at the registry or registrar. The plausible objective of this exercise in my view is to allow the domain name owner to (securely) tell the relying party what the 'best' connection is to the service. I see an advantage to using DNSSEC, but I don't see an absolute requirement because 'best' may turn out to be 'not very good' but it will still be better than raw TCP/IP without SSL. -- Website: http://hallambaker.com/ --001636af02d72f319c04a272f944 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, May 4, 2011 at 3:14 AM, Richard = L. Barnes <rbarnes@= bbn.com> wrote:
> If I can get GoDaddy to add the records for www.you.com, it's as bad = as Comodo issuing me a cert for www.you.com.

From the perspective of risks to www.you.com, that's true. =A0It's better than the = traditional CAs (including Comodo) in the sense that GoDaddy is restricted = to abusing their customers and not the whole DNS.

You think that is really the case?

=
I would like to see proof of that assertion. I know that there is a do= main locking system, but I have no idea how it is enforced and have never s= een documentation.

I would not expect the locking mechanism to be particul= arly strong since (1) the thin registry has very little information to go o= n (2) any malicious behavior can be reversed out easily (3) registrars have= a large incentive not to defect.
=A0

Fraudulent issue of certificates ha= s been a much much rarer occurrence than DNS name hijacking at the registry= or registrar.


The plausible object= ive of this exercise in my view is to allow the domain name owner to (secur= ely) tell the relying party what the 'best' connection is to the se= rvice.=A0

I see an advantage to using DNSSEC, but I don't see= an absolute requirement because 'best' may turn out to be 'not= very good' but it will still be better than raw TCP/IP without SSL.=A0=

--
Website: http://hallambaker.= com/

--001636af02d72f319c04a272f944-- From rbarnes@bbn.com Wed May 4 06:31:22 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C90E0762 for ; Wed, 4 May 2011 06:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.978 X-Spam-Level: X-Spam-Status: No, score=-104.978 tagged_above=-999 required=5 tests=[AWL=1.621, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dd-CP9hlljLs for ; Wed, 4 May 2011 06:31:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 97BBAE06A4 for ; Wed, 4 May 2011 06:31:21 -0700 (PDT) Received: from [128.89.254.149] (port=57495 helo=dhcp-27-1.ripemtg.ripe.net) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QHcAi-000D9h-BG; Wed, 04 May 2011 09:31:20 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 4 May 2011 15:30:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0D292850-61B5-4875-BBF9-062F38C1957B@bbn.com> References: <1302734872.1842.78.camel@localhost> <0AC330D6-632A-4300-968F-F8B164A82E50@checkpoint.com> <0E21F266-ED68-4FEB-8E09-EC50C1F624CF@bbn.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: "dane@ietf.org" Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 13:31:22 -0000 At the very least, the practical barriers are higher. =20 For a well-known CA to project false credentials for a domain that will = be accepted by clients, all it has to do is issue a cert. It's = technically very simple, and violates no legal agreements except = possibly the CA's own CP or CPS. For someone to use DANE to project false credentials for domain that is = not legitimately theirs, they have to hijack a domain, which in itself = presents technical and legal challenges, especially if the hijacker is a = registrar. And in addition to the standard domain hijacking challenges, = they also have to get a DS record into the appropriate parent zone. Alternatively, since domain hijacking already exists, you could say that = DANE enables you to move from two threats (CA+hijack) to one (hijack). --Richard On May 4, 2011, at 3:09 PM, Phillip Hallam-Baker wrote: >=20 >=20 > On Wed, May 4, 2011 at 3:14 AM, Richard L. Barnes = wrote: > > If I can get GoDaddy to add the records for www.you.com, it's as bad = as Comodo issuing me a cert for www.you.com. >=20 > =46rom the perspective of risks to www.you.com, that's true. It's = better than the traditional CAs (including Comodo) in the sense that = GoDaddy is restricted to abusing their customers and not the whole DNS. >=20 > You think that is really the case? >=20 > I would like to see proof of that assertion. I know that there is a = domain locking system, but I have no idea how it is enforced and have = never seen documentation. >=20 > I would not expect the locking mechanism to be particularly strong = since (1) the thin registry has very little information to go on (2) any = malicious behavior can be reversed out easily (3) registrars have a = large incentive not to defect. > =20 >=20 > Fraudulent issue of certificates has been a much much rarer occurrence = than DNS name hijacking at the registry or registrar. >=20 >=20 > The plausible objective of this exercise in my view is to allow the = domain name owner to (securely) tell the relying party what the 'best' = connection is to the service.=20 >=20 > I see an advantage to using DNSSEC, but I don't see an absolute = requirement because 'best' may turn out to be 'not very good' but it = will still be better than raw TCP/IP without SSL.=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 From warren@kumari.net Wed May 4 06:34:36 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECA7E0762 for ; Wed, 4 May 2011 06:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2hXDtKuYHP1 for ; Wed, 4 May 2011 06:34:36 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 134DCE06A4 for ; Wed, 4 May 2011 06:34:35 -0700 (PDT) Received: from [172.19.118.237] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 77A3A1B40156; Wed, 4 May 2011 09:34:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <8C2A8492-DDF9-4A4B-B60D-1798EDCC2121@bbn.com> Date: Wed, 4 May 2011 09:34:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1302734872.1842.78.camel@localhost> <0AC330D6-632A-4300-968F-F8B164A82E50@checkpoint.com> <8C2A8492-DDF9-4A4B-B60D-1798EDCC2121@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) Cc: "dane@ietf.org" Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 13:34:36 -0000 On May 4, 2011, at 3:25 AM, Richard L. Barnes wrote: >>> The latter is a harder question. If you're google, then you enter = your own DNS records, but smaller organizations use some service like = GoDaddy to register the domain, add DNS records and everything else = required to get a name for your server on the Internet. If I can get = GoDaddy to add the records for www.you.com, it's as bad as Comodo = issuing me a cert for www.you.com. >>>=20 >>=20 >> sure, but ... I'm sure that eventually dns service providers >> (go-daddy/etc) will have to pony up for some real infrastructure to >> support dnssec. pch does this for ~2k/deployment (I think... bill had >> some slides at caribnog ~2wks ago that talked about this very = problem, >> actually). For GoDaddy/etc it's not that hard to implement some = secure >> interfaces/apis and the backend bits required. They may not do this >> TODAY, but they will be driven there by market pressures in the >> future. (which seems fine to me) >=20 > To be clear, there's two attack vectors here: > 1. Abuse by people masquerading as a domain owner > 2. Abuse by the registrar itself >=20 > The former is what you're talking about (if I understand you = correctly); the latter is the Comodo-like case that Yoav mentioned, = which isn't really helped by more infrastructure. And if your registrar (or anyone else who can masquerade as the domain = owner) is out to screw with you, they already have this capability[0] -- = they can really easily point NS records at nameservers that they = control, serve MX records for your domain at mailservers that they run = and apply for a cert, capturing the cookie / token needed to prove = control..... W [0]: Yes, this may not work for the big brands (that are greylisted by = most CAs), and doesn't work for getting an EV cert, but... >=20 > --Richard >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From paul.hoffman@vpnc.org Wed May 4 07:33:04 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17065E0728 for ; Wed, 4 May 2011 07:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.798 X-Spam-Level: X-Spam-Status: No, score=-101.798 tagged_above=-999 required=5 tests=[AWL=0.801, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbaoTdxhNBwH for ; Wed, 4 May 2011 07:33:03 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E525DE0794 for ; Wed, 4 May 2011 07:33:02 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p44EWwtT065920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 4 May 2011 07:33:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Paul Hoffman In-Reply-To: <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> Date: Wed, 4 May 2011 07:32:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4D1BBE1D-BCB1-4D18-B612-2F2DB4A2A7F8@vpnc.org> References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> To: dane@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 04 May 2011 14:33:04 -0000 This draft seems to hit all the use cases and requirements that I = remember seeing on the list, although it is hard to be sure given that = people didn't change the Subject: line when they, you know, changed the = subject. --Paul Hoffman From hallam@gmail.com Wed May 4 10:09:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6885FE07CE for ; Wed, 4 May 2011 10:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.118 X-Spam-Level: X-Spam-Status: No, score=-3.118 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANvGqPwZVVzg for ; Wed, 4 May 2011 10:09:43 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 60A46E07CC for ; Wed, 4 May 2011 10:09:43 -0700 (PDT) Received: by ywi6 with SMTP id 6so569692ywi.31 for ; Wed, 04 May 2011 10:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=U0sk9dLUCS2GkAKb2WpiKCrfjj6ARJSKonc7EtNs7aE=; b=e7l3R2BNBPD3P5HWY5lrx+slIZsHWteMEiilnGY1+UhIdX9xHhzwI9q725ZoZLnHDM VOQ2OECH3mC4pHON4e5CzOyTXdpfgO3GvrJg9okKR8t4jvCNSUPhzY2+6NCRp3qxULBo 5n07hPlEudIQuayBOcPyHysqQXuhh3C8/RomA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Xw2DsuyQEY8l3UUDKWrpcB/h91DmoUniL0Y+PWLlf/SMPmDp7TAKKUombbDFzyX/Kx ekrigAGGfpYh+6u3sU47ajYE39LyOR2Cp2tMfK1WRYAEnXXxDW53fGW5Zvn16F9xvJgK uIqLqbWebRXDJl6VKVn4uUOJP5XzutaDwmDRA= MIME-Version: 1.0 Received: by 10.101.2.25 with SMTP id e25mr910174ani.28.1304528982187; Wed, 04 May 2011 10:09:42 -0700 (PDT) Received: by 10.100.178.6 with HTTP; Wed, 4 May 2011 10:09:42 -0700 (PDT) In-Reply-To: <0D292850-61B5-4875-BBF9-062F38C1957B@bbn.com> References: <1302734872.1842.78.camel@localhost> <0AC330D6-632A-4300-968F-F8B164A82E50@checkpoint.com> <0E21F266-ED68-4FEB-8E09-EC50C1F624CF@bbn.com> <0D292850-61B5-4875-BBF9-062F38C1957B@bbn.com> Date: Wed, 4 May 2011 13:09:42 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=0016368e2a87951ecb04a2765283 Cc: "dane@ietf.org" Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 17:09:45 -0000 --0016368e2a87951ecb04a2765283 Content-Type: text/plain; charset=ISO-8859-1 You have absolutely no knowledge or experience on which to base those assertions. Nor does anyone else. Claims such as these are unnecessary and are going to damage DANE. There is a mechanism already being deployed to provide a control against the attack stated here. If you want to make comparisons you should compare like with like, proposed system with proposed system. DANE does not offer any advantage in this respect over the CA system + CAA. Don't spoil a strong case by insisting on making a weak one. On Wed, May 4, 2011 at 9:30 AM, Richard L. Barnes wrote: > At the very least, the practical barriers are higher. > > For a well-known CA to project false credentials for a domain that will be > accepted by clients, all it has to do is issue a cert. It's technically > very simple, and violates no legal agreements except possibly the CA's own > CP or CPS. > > For someone to use DANE to project false credentials for domain that is not > legitimately theirs, they have to hijack a domain, which in itself presents > technical and legal challenges, especially if the hijacker is a registrar. > And in addition to the standard domain hijacking challenges, they also have > to get a DS record into the appropriate parent zone. > > Alternatively, since domain hijacking already exists, you could say that > DANE enables you to move from two threats (CA+hijack) to one (hijack). > > --Richard > > > > On May 4, 2011, at 3:09 PM, Phillip Hallam-Baker wrote: > > > > > > > On Wed, May 4, 2011 at 3:14 AM, Richard L. Barnes > wrote: > > > If I can get GoDaddy to add the records for www.you.com, it's as bad > as Comodo issuing me a cert for www.you.com. > > > > From the perspective of risks to www.you.com, that's true. It's better > than the traditional CAs (including Comodo) in the sense that GoDaddy is > restricted to abusing their customers and not the whole DNS. > > > > You think that is really the case? > > > > I would like to see proof of that assertion. I know that there is a > domain locking system, but I have no idea how it is enforced and have never > seen documentation. > > > > I would not expect the locking mechanism to be particularly strong since > (1) the thin registry has very little information to go on (2) any malicious > behavior can be reversed out easily (3) registrars have a large incentive > not to defect. > > > > > > Fraudulent issue of certificates has been a much much rarer occurrence > than DNS name hijacking at the registry or registrar. > > > > > > The plausible objective of this exercise in my view is to allow the > domain name owner to (securely) tell the relying party what the 'best' > connection is to the service. > > > > I see an advantage to using DNSSEC, but I don't see an absolute > requirement because 'best' may turn out to be 'not very good' but it will > still be better than raw TCP/IP without SSL. > > > > -- > > Website: http://hallambaker.com/ > > > > -- Website: http://hallambaker.com/ --0016368e2a87951ecb04a2765283 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You have absolutely no knowledge or experience on which to base those = assertions. Nor does anyone else.

Claims such as t= hese are unnecessary and are going to damage DANE.


There is a mechanism already being deployed to provide a con= trol against the attack stated here.

If you want t= o make comparisons you should compare like with like, proposed system with = proposed system. DANE does not offer any advantage in this respect over the= CA system + CAA.


Don't spoil a strong case by insisti= ng on making a weak one.

On Wed, M= ay 4, 2011 at 9:30 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
At the very least, the practical barriers a= re higher.

For a well-known CA to project false credentials for a domain that will be = accepted by clients, all it has to do is issue a cert. =A0It's technica= lly very simple, and violates no legal agreements except possibly the CA= 9;s own CP or CPS.

For someone to use DANE to project false credentials for domain that is not= legitimately theirs, they have to hijack a domain, which in itself present= s technical and legal challenges, especially if the hijacker is a registrar= . =A0And in addition to the standard domain hijacking challenges, they also= have to get a DS record into the appropriate parent zone.

Alternatively, since domain hijacking already exists, you could say that DA= NE enables you to move from two threats (CA+hijack) to one (hijack).

--Richard



On May 4, 2011, at 3:09 PM, Phillip Hallam-Baker wrote:

>
>
> On Wed, May 4, 2011 at 3:14 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
> > If I can get GoDaddy to add the records for www.you.com, it's as bad as Comodo issu= ing me a cert for www.you.= com.
>
> From the perspective of risks to www.you.com, that's true. =A0It's better than the t= raditional CAs (including Comodo) in the sense that GoDaddy is restricted t= o abusing their customers and not the whole DNS.
>
> You think that is really the case?
>
> I would like to see proof of that assertion. I know that there is a do= main locking system, but I have no idea how it is enforced and have never s= een documentation.
>
> I would not expect the locking mechanism to be particularly strong sin= ce (1) the thin registry has very little information to go on (2) any malic= ious behavior can be reversed out easily (3) registrars have a large incent= ive not to defect.
>
>
> Fraudulent issue of certificates has been a much much rarer occurrence= than DNS name hijacking at the registry or registrar.
>
>
> The plausible objective of this exercise in my view is to allow the do= main name owner to (securely) tell the relying party what the 'best'= ; connection is to the service.
>
> I see an advantage to using DNSSEC, but I don't see an absolute re= quirement because 'best' may turn out to be 'not very good'= but it will still be better than raw TCP/IP without SSL.
>
> --
> Website: http://= hallambaker.com/
>




--
Website: http://hallambaker.com/

--0016368e2a87951ecb04a2765283-- From paul@xelerance.com Wed May 4 13:13:56 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F9DE06F4 for ; Wed, 4 May 2011 13:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCe8Cap1vY7i for ; Wed, 4 May 2011 13:13:55 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4F44BE06DE for ; Wed, 4 May 2011 13:13:55 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 56F23C63F; Wed, 4 May 2011 16:13:53 -0400 (EDT) Date: Wed, 4 May 2011 16:13:52 -0400 (EDT) From: Paul Wouters To: Warren Kumari In-Reply-To: <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> Message-ID: References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 04 May 2011 20:13:56 -0000 I believe this document still needs some work before publication. Comments below. the first use case is about pinning the CA using DANE. It states: Because these constraints do not increase the scope of PKIX-based assertions about domains, there is not a strict requirement for DNSSEC. This seems untrue if choices for CAs are going to be made based on a DANE record. Specifically, When Bob connects to alice.example.com, he uses this mechanism to verify that that the certificate presented by the server was issued under the proper CA I have no idea what "verify" means in the absense of DNSSEC, but it is not a process I feel comfortable endorsing. It also conflicts more or less with the introduction that states: and with the advent of DNSSEC [RFC1034][RFC4033], it is possible for this information to be provided securely, Providing insecure information used to pin the CA seems wrong. Saying that this new feature could be spoofed but in that case we can still rely on the underlying PKIX security raises the question what this new dane process would add securety wise. Without DNSSEC, only a false sense of security. Addiitonally, it ALSO conflicts with section 4's statement of: Downgrade: An attacker who can tamper with DNS responses must not be able to make a DANE-compliant client treat a site that has deployed DANE and DNSSEC like a site that has deployed neither. I still feel very strongly that dane should just make a clear cut "DNSSEC required" statement. Injected or modified false records are not useful unless the attacker can also obtain a certificate for the target domain. This is also not true, with users having warning pop-up fatigue. An attacker will have a certain percentage of users clicking through. The entire use case becomes much clearer if we don't try to explain (badly) why DNSSEC is optional in this use case. This is not a significant incremental risk, however, relative to the current PKIX-based system. This sentence can be parsed in different ways, and I am not sure I even understand it. It seems to try and say that this gives more power to the DNS operator since there is no CA involved. However, it is wrong. In the use case of 3.2, the DNS operator can also remove the CA based dane record for a domain based dane record and then they can generate their own valid certificate as well. Paul From jakob@kirei.se Wed May 4 23:48:18 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBAFE069F for ; Wed, 4 May 2011 23:48:18 -0700 (PDT) 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.776, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHigp79eu17E for ; Wed, 4 May 2011 23:48:17 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id DC0D3E06CE for ; Wed, 4 May 2011 23:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=Cn3y0OmJHAymwU6pYnaewVgrJ1iY3rd1LSvITF4WPCQ=; b=SxzdX64nJR6/uWDia6NNcwTCdZSS419QvPaxlOVrLhF4ABt2dMFLNr6+cpB/Rj5DLDYsJaxeJ3pdw KlsBdCUDLBLWB8HlFAGEtBpnez+ysVFRj+hZQJ0leCGTEoT94HcQhaHegajZIMvkzKGgu9PMOhnvYO J47CDdQtzpaNw098= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 5 May 2011 08:48:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Thu, 5 May 2011 08:48:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1302734872.1842.78.camel@localhost> <0AC330D6-632A-4300-968F-F8B164A82E50@checkpoint.com> <0E21F266-ED68-4FEB-8E09-EC50C1F624CF@bbn.com> <0D292850-61B5-4875-BBF9-062F38C1957B@bbn.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: "dane@ietf.org" Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 06:48:18 -0000 On 4 maj 2011, at 19.09, Phillip Hallam-Baker wrote: > There is a mechanism already being deployed to provide a control = against the attack stated here. Could you please elaborate on how this "mechanism" work? jakob From jakob@kirei.se Wed May 4 23:49:10 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E5AE06AF for ; Wed, 4 May 2011 23:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElPTXjJLvFlD for ; Wed, 4 May 2011 23:49:09 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id B78B9E069F for ; Wed, 4 May 2011 23:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer; bh=RnsKpgq6gxLFOAGPidGC3vBVrRAY98uNUhHU6LKu3JA=; b=w1bf8jAYee4LlN874KQ2xN/GABKO6OI0ZNv4kXO75HT3bfnoHRWoEH8lGwuKVmP1EGfkyXPGIv45c c6JrnxPywjBSNIQQjfwPxFa3qpGiPExRBkvoZN9EIsBbwEtxVAOuQAZ7r8gywtHbH+TsLeOj3LJuCo q7l7oG9idVvjycT8= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Thu, 5 May 2011 08:49:07 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Jakob Schlyter In-Reply-To: <4D1BBE1D-BCB1-4D18-B612-2F2DB4A2A7F8@vpnc.org> Date: Thu, 5 May 2011 08:49:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <4D1BBE1D-BCB1-4D18-B612-2F2DB4A2A7F8@vpnc.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 05 May 2011 06:49:10 -0000 On 4 maj 2011, at 16.32, Paul Hoffman wrote: > This draft seems to hit all the use cases and requirements that I = remember seeing on the list, although it is hard to be sure given that = people didn't change the Subject: line when they, you know, changed the = subject. I concur and support moving the draft forward. jakob From rbarnes@bbn.com Thu May 5 00:31:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8609FE06F6 for ; Thu, 5 May 2011 00:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.852 X-Spam-Level: X-Spam-Status: No, score=-104.852 tagged_above=-999 required=5 tests=[AWL=1.147, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVIf0EMM+Moy for ; Thu, 5 May 2011 00:31:10 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B2D39E068C for ; Thu, 5 May 2011 00:30:56 -0700 (PDT) Received: from [128.89.254.157] (port=54647 helo=dhcp-27-1.ripemtg.ripe.net) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QHt1S-000L5r-Uv; Thu, 05 May 2011 03:30:55 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 5 May 2011 09:30:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1302734872.1842.78.camel@localhost> <0AC330D6-632A-4300-968F-F8B164A82E50@checkpoint.com> <0E21F266-ED68-4FEB-8E09-EC50C1F624CF@bbn.com> <0D292850-61B5-4875-BBF9-062F38C1957B@bbn.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: "dane@ietf.org" Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 07:31:11 -0000 > You have absolutely no knowledge or experience on which to base those = assertions. Nor does anyone else. Ad hominem arguments don't do anybody any good. Especially ad omnes = homines arguments, which honestly seem kind of nonsensical, from an = epistemological point of view. > There is a mechanism already being deployed to provide a control = against the attack stated here. Like Jakob, I would appreciate more detail. If you're referring to CAA, = see below. > If you want to make comparisons you should compare like with like, = proposed system with proposed system. DANE does not offer any advantage = in this respect over the CA system + CAA. In the CA+CAA system, the CAs are still trusted entities. In the sense = of RFC 4949, the client acts on the assumption that the CA does the = right thing. CAA increases the probability that a good CA will do the = right thing (clearly a good thing), but it doesn't prevent a bad CA from = violating the security model. The entire point of DANE is to allow clients to limit the scope of this = trust using additional information from a domain owner. In the process, = this shifts some of the trust to DNS providers, but as I and others have = repeatedly pointed out, DNS providers are *already* trusted entities in = the CA system. =20 --Richard >=20 > Don't spoil a strong case by insisting on making a weak one. >=20 > On Wed, May 4, 2011 at 9:30 AM, Richard L. Barnes = wrote: > At the very least, the practical barriers are higher. >=20 > For a well-known CA to project false credentials for a domain that = will be accepted by clients, all it has to do is issue a cert. It's = technically very simple, and violates no legal agreements except = possibly the CA's own CP or CPS. >=20 > For someone to use DANE to project false credentials for domain that = is not legitimately theirs, they have to hijack a domain, which in = itself presents technical and legal challenges, especially if the = hijacker is a registrar. And in addition to the standard domain = hijacking challenges, they also have to get a DS record into the = appropriate parent zone. >=20 > Alternatively, since domain hijacking already exists, you could say = that DANE enables you to move from two threats (CA+hijack) to one = (hijack). >=20 > --Richard >=20 >=20 >=20 > On May 4, 2011, at 3:09 PM, Phillip Hallam-Baker wrote: >=20 > > > > > > On Wed, May 4, 2011 at 3:14 AM, Richard L. Barnes = wrote: > > > If I can get GoDaddy to add the records for www.you.com, it's as = bad as Comodo issuing me a cert for www.you.com. > > > > =46rom the perspective of risks to www.you.com, that's true. It's = better than the traditional CAs (including Comodo) in the sense that = GoDaddy is restricted to abusing their customers and not the whole DNS. > > > > You think that is really the case? > > > > I would like to see proof of that assertion. I know that there is a = domain locking system, but I have no idea how it is enforced and have = never seen documentation. > > > > I would not expect the locking mechanism to be particularly strong = since (1) the thin registry has very little information to go on (2) any = malicious behavior can be reversed out easily (3) registrars have a = large incentive not to defect. > > > > > > Fraudulent issue of certificates has been a much much rarer = occurrence than DNS name hijacking at the registry or registrar. > > > > > > The plausible objective of this exercise in my view is to allow the = domain name owner to (securely) tell the relying party what the 'best' = connection is to the service. > > > > I see an advantage to using DNSSEC, but I don't see an absolute = requirement because 'best' may turn out to be 'not very good' but it = will still be better than raw TCP/IP without SSL. > > > > -- > > Website: http://hallambaker.com/ > > >=20 >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 From hallam@gmail.com Thu May 5 08:53:18 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4AFE06A4 for ; Thu, 5 May 2011 08:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqQ30jzabfDs for ; Thu, 5 May 2011 08:53:16 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 994FFE0689 for ; Thu, 5 May 2011 08:53:16 -0700 (PDT) Received: by ywi6 with SMTP id 6so988916ywi.31 for ; Thu, 05 May 2011 08:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RdHv4VJee0k0N0/wM1toxkgApOqSTtQlLeMdI2grVlg=; b=I7mF1bl6AZZuvgIre3hxR4g9Z4eq9YllAf8hZm69cqVDhdsrAwE4DRbgx1LxNQRPvQ DHFWaL+85RsJrw9i0gI3jMNOPY85+1QxNaxsQTlAjzowF0/ExPdRWLWUmyvLxUCdCN8h JNmUDJ/r5DnR2fy04pGsIHSxJUC1q6IlOQ05Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ULxzAv9Z/zThbV2GikS6WqaYExJaF8I6UkWS91QMG75oBVyREhJwF/yvgyxRycpn8o PJOyKhpD33dN5pnB2kWOvFDqJMTF/4UotysAkqU/qQLuQFSWzDOZrjs1TdiOswpyrKyy xw2TT5wWZMv7Lx6Gb7m3lit0/SbJfLdB9HAlM= MIME-Version: 1.0 Received: by 10.100.229.2 with SMTP id b2mr1657135anh.72.1304610795954; Thu, 05 May 2011 08:53:15 -0700 (PDT) Received: by 10.100.178.6 with HTTP; Thu, 5 May 2011 08:53:15 -0700 (PDT) In-Reply-To: References: <1302734872.1842.78.camel@localhost> <0AC330D6-632A-4300-968F-F8B164A82E50@checkpoint.com> <0E21F266-ED68-4FEB-8E09-EC50C1F624CF@bbn.com> <0D292850-61B5-4875-BBF9-062F38C1957B@bbn.com> Date: Thu, 5 May 2011 11:53:15 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=001636af02d710243904a2895f13 Cc: "dane@ietf.org" Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 15:53:18 -0000 --001636af02d710243904a2895f13 Content-Type: text/plain; charset=ISO-8859-1 CAA is designed as an accountability mechanism. Part of the idea is to provide an objective criteria for CA malfeasance. One of the problems with the current situation is that every CA has their own criteria and there are no objective criteria at all. CABForum is currently looking to change that with minimum issue criteria, CAA will hopefully be a part of that. The advantage of an accountability approach is that it fixes the current system without depending on deployment of new code. The disadvantage is that accountability is retrospective and thus cannot prevent an attack, it can merely make the breach less likely. In the real world, accountability based security can be very effective, particularly if combined with access controls. Trying to use access controls or accountability on their own leads to defective security systems. Access controls are good but they can only be used when the criteria are completely objective and definable in advance. So they end up being useful only to set minimum standards. and that in turn leads to people like Bradley Manning having access to a quarter million diplomatic cables despite being a very low grade clerk. Accountability controls fail when the expectation of consequences is low or the consequences themselves are not a deterrent. Domain name holders can use CAA to tell applications that they must not accept certificates that do not comply with the Relying Application Authorization Set. Now one way that could be implemented would be to put the enforcement code in every browser. Which would be great as far as I am concerned. But we still have the question of what the relying party should do. And there are two options here: 1) Reject the certificate. 2) Tell someone an unauthorized certificate is being presented. 3) Do both The first of these makes CAA an access scheme as well as being an accountability scheme. I think that is useful, but it only provides protection to parties who have upgraded their browser and it does not provide us with any warning that an attack took place. Attempting the rejection approach is also subject to blocking of data in the DNS, requires us to validate the DNS records with DNSSEC and so on. I would very much like this to happen but I cannot guarantee that it will. So even though I want client deployment, I base my value proposition on the second point. I claim that there is a sufficiently high value proposition for deployment of CAA if the only client enforcement is of the second type and it is being done by the likes of CAs checking up on each other and the EFF and so on. The other point to consider for client deployment (and this would affect DANE as well) is that all or nothing deployment for a site is actually quite hard. We faced this with EV when some banks decided that they wanted to upgrade all their servers to EV at the same time to avoid having some EV and some not. Splitting the issue criteria and the enforcement criteria allows for a phased approach. If a site has had issue criteria specified for a year, there should be no certs in use that are non-conforming. It is thus much easier to flip the switch. So I believe that CAA has a value independent of the use cases and scope that DANE was intended to address. The question I think we should ask is whether we can work together or if we are going to have multiple mechanisms. When we first proposed CAA the gap between the CAA approach and the DANE approach was large. I believe that the gap is much smaller now but there are still important differences that would need to be reconciled. CAA is architected to conform to the syntactic prejudices of the PKIX world. I hate ASN.1 as much as anyone. But its the price of freight when dealing with the X.509 world. The CAA approach is potentially beneficial to DANE because it is designed in a way that allows it to start providing value before there is a large base of browser providers that implement it. On Thu, May 5, 2011 at 3:30 AM, Richard L. Barnes wrote: > > You have absolutely no knowledge or experience on which to base those > assertions. Nor does anyone else. > > Ad hominem arguments don't do anybody any good. Especially ad omnes > homines arguments, which honestly seem kind of nonsensical, from an > epistemological point of view. Observing that nobody has experience of smaller DNS registrars operating DNSSEC is a statement of fact, not an ad-hominem. Plus ad-hominem is the argument 'Y says X therefore not X'. I am arguing that your claim should be rejected as heresay. You are making a factual claim without the experience to back it up. There can be no factual evidence because the circumstances do not yet exist. > If you want to make comparisons you should compare like with like, > proposed system with proposed system. DANE does not offer any advantage in > this respect over the CA system + CAA. > > In the CA+CAA system, the CAs are still trusted entities. In the sense of > RFC 4949, the client acts on the assumption that the CA does the right > thing. CAA increases the probability that a good CA will do the right thing > (clearly a good thing), but it doesn't prevent a bad CA from violating the > security model. > > The entire point of DANE is to allow clients to limit the scope of this > trust using additional information from a domain owner. In the process, > this shifts some of the trust to DNS providers, but as I and others have > repeatedly pointed out, DNS providers are *already* trusted entities in the > CA system. Actually CAA allows for both mechanisms. See the above. -- Website: http://hallambaker.com/ --001636af02d710243904a2895f13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable CAA is designed as an accountability mechanism. Part of the idea is to prov= ide an objective criteria for CA malfeasance. One of the problems with the = current situation is that every CA has their own criteria and there are no = objective criteria at all. CABForum is currently looking to change that wit= h minimum issue criteria, CAA will hopefully be a part of that.

The advantage of an accountability approach is that it fixes= the current system without depending on deployment of new code. The disadv= antage is that accountability is retrospective and thus cannot prevent an a= ttack, it can merely make the breach less likely.

In the real world, accountability based security can be= very effective, particularly if combined with access controls. Trying to u= se access controls or accountability on their own leads to defective securi= ty systems. Access controls are good but they can only be used when the cri= teria are completely objective and definable in advance. So they end up bei= ng useful only to set minimum standards. and that in turn leads to people l= ike Bradley Manning having access to a quarter million diplomatic cables de= spite being a very low grade clerk. Accountability controls fail when the e= xpectation of consequences is low or the consequences themselves are not a = deterrent.


Domain name holders can use CAA to tell = applications that they must not accept certificates that do not comply with= the Relying Application Authorization Set.

Now on= e way that could be implemented would be to put the enforcement code in eve= ry browser. Which would be great as far as I am concerned.

But we still have the question of what the relying part= y should do. And there are two options here:

1) Re= ject the certificate.
2) Tell someone an unauthorized certificate= is being presented.
3) Do both

The first of these makes CAA an ac= cess scheme as well as being an accountability scheme. I think that is usef= ul, but it only provides protection to parties who have upgraded their brow= ser and it does not provide us with any warning that an attack took place.<= /div>

Attempting the rejection approach is also subject to bl= ocking of data in the DNS, requires us to validate the DNS records with DNS= SEC and so on. I would very much like this to happen but I cannot guarantee= that it will.

So even though I want client deployment, I base my valu= e proposition on the second point. I claim that there is a sufficiently hig= h value proposition for deployment of CAA if the only client enforcement is= of the second type and it is being done by the likes of CAs checking up on= each other and the EFF and so on.


The other point to consider for client d= eployment (and this would affect DANE as well) is that all or nothing deplo= yment for a site is actually quite hard. We faced this with EV when some ba= nks decided that they wanted to upgrade all their servers to EV at the same= time to avoid having some EV and some not.

Splitting the issue criteria and the enforcement criter= ia allows for a phased approach. If a site has had issue criteria specified= for a year, there should be no certs in use that are non-conforming. It is= thus much easier to flip the switch.


So I believe that CAA has a value indepe= ndent of the use cases and scope that DANE was intended to address. The que= stion I think we should ask is whether we can work together or if we are go= ing to have multiple mechanisms.=A0

When we first proposed CAA the gap between the CAA appr= oach and the DANE approach was large. I believe that the gap is much smalle= r now but there are still important differences that would need to be recon= ciled.=A0

CAA is architected to conform to the syntactic prejudic= es of the PKIX world. I hate ASN.1 as much as anyone. But its the price of = freight when dealing with the X.509 world.

The CAA= approach is potentially beneficial to DANE because it is designed in a way= that allows it to start providing value before there is a large base of br= owser providers that implement it.=A0


On Thu, May 5, 2011 at 3= :30 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
> You have absolutely no knowledge or experience on wh= ich to base those assertions. Nor does anyone else.

Ad hominem arguments don't do anybody any good. =A0Especially ad = omnes homines arguments, which honestly seem kind of nonsensical, from an e= pistemological point of view.

Observing tha= t nobody has experience of smaller DNS registrars operating DNSSEC is a sta= tement of fact, not an ad-hominem.

Plus ad-hominem is the argument 'Y says X therefore= not X'. I am arguing that your claim should be rejected as heresay. Yo= u are making a factual claim without the experience to back it up. There ca= n be no factual evidence because the circumstances do not yet exist.=A0


> If you want to make comparisons you should compare like with like= , proposed system with proposed system. DANE does not offer any advantage i= n this respect over the CA system + CAA.

In the CA+CAA system, the CAs are still trusted entities. =A0In the s= ense of RFC 4949, the client acts on the assumption that the CA does the ri= ght thing. =A0CAA increases the probability that a good CA will do the righ= t thing (clearly a good thing), but it doesn't prevent a bad CA from vi= olating the security model.

The entire point of DANE is to allow clients to limit the scope of this tru= st using additional information from a domain owner. =A0In the process, thi= s shifts some of the trust to DNS providers, but as I and others have repea= tedly pointed out, DNS providers are *already* trusted entities in the CA s= ystem.

Actually CAA allows for both mechanisms. See the above.=
=A0

--
Website: http://hallambaker.com/

--001636af02d710243904a2895f13-- From ietf@augustcellars.com Thu May 5 12:12:02 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9E0E091B for ; Thu, 5 May 2011 12:12:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sFXYReZeCX6 for ; Thu, 5 May 2011 12:12:02 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD87E091A for ; Thu, 5 May 2011 12:12:01 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id F20F36A46A; Thu, 5 May 2011 12:11:59 -0700 (PDT) From: "Jim Schaad" To: "'Paul Wouters'" , "'Warren Kumari'" References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> In-Reply-To: Date: Thu, 5 May 2011 12:39:25 -0700 Message-ID: <00d001cc0b5c$24978bb0$6dc6a310$@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: AQKLn3/Ps6X/LbhZOf22GW/Fk66M2AJ3VRcNAgBHpXyS27uBkA== Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 05 May 2011 19:12:02 -0000 I am going to support the removal of this comment for a slightly different reason. The issue is that Alice is worried that somebody else will generate a certificate for her service. There are two possibilities - a certificate for the same key is created w/ different attributes or a certificate is created for the purpose of setting up a different server. The first case can be ignored for now. The second case is what Alice is worried about happening. If there is any path for this to be successful then Alice is not going to feel reassured that it is not happening. Thus if Mallory can get the certificate and corrupt the DNS for Bob then the attack is successful and Alice has been thwarted in what she wants to see happen. Dane has not really helped except by making the attack harder by Mallory needed to add or remove one record from the DNS poisoning. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Paul Wouters > Sent: Wednesday, May 04, 2011 1:14 PM > To: Warren Kumari > Cc: dane@ietf.org > Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 > > > I believe this document still needs some work before publication. > Comments below. > > > the first use case is about pinning the CA using DANE. It states: > > Because these constraints do not increase the scope of PKIX-based > assertions about domains, there is not a strict requirement for > DNSSEC. > > This seems untrue if choices for CAs are going to be made based on a DANE > record. Specifically, > > When Bob connects to alice.example.com, he uses this mechanism to > verify that that the certificate presented by the server was issued > under the proper CA > > I have no idea what "verify" means in the absense of DNSSEC, but it is not a > process I feel comfortable endorsing. It also conflicts more or less with the > introduction that states: > > and with the advent of DNSSEC [RFC1034][RFC4033], it is possible > for this information to be provided securely, > > Providing insecure information used to pin the CA seems wrong. Saying that > this new feature could be spoofed but in that case we can still rely on the > underlying PKIX security raises the question what this new dane process > would add securety wise. Without DNSSEC, only a false sense of security. > > Addiitonally, it ALSO conflicts with section 4's statement of: > > Downgrade: An attacker who can tamper with DNS responses must not > be able to make a DANE-compliant client treat a site that has > deployed DANE and DNSSEC like a site that has deployed neither. > > I still feel very strongly that dane should just make a clear cut "DNSSEC > required" statement. > > > Injected or modified false records are not useful unless the > attacker can also obtain a certificate for the target domain. > > This is also not true, with users having warning pop-up fatigue. An attacker > will have a certain percentage of users clicking through. > > The entire use case becomes much clearer if we don't try to explain (badly) > why DNSSEC is optional in this use case. > > This is not a significant incremental risk, however, relative to the > current PKIX-based system. > > This sentence can be parsed in different ways, and I am not sure I even > understand it. It seems to try and say that this gives more power to the DNS > operator since there is no CA involved. However, it is wrong. In the use case > of 3.2, the DNS operator can also remove the CA based dane record for a > domain based dane record and then they can generate their own valid > certificate as well. > > Paul > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ajs@shinkuro.com Thu May 5 13:03:21 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA00E09DA for ; Thu, 5 May 2011 13:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1oYHkqwwiaD for ; Thu, 5 May 2011 13:03:19 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 86449E09E3 for ; Thu, 5 May 2011 13:03:19 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3FB8F1ECB408 for ; Thu, 5 May 2011 20:03:18 +0000 (UTC) Date: Thu, 5 May 2011 16:03:16 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110505200315.GO25833@crankycanuck.ca> References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 05 May 2011 20:03:21 -0000 On Fri, Apr 29, 2011 at 12:03:12PM -0400, Warren Kumari wrote: > Hi all, > > I think that Richard has integrated most of the comments received on-list into this most recent version of the doc and so, as I mentioned, we are going to kick off WGLC... > > Please get y'er comments in -- WGLC will be closing on 2011-05-13 at 16:00UTC (noonish EDT). Dear colleagues, I have read this document. I have some comments. I don't understand the reason for this reference to RFC 1034 in section 1: The DNS is built to provide information about domain names, and with the advent of DNSSEC [RFC1034][RFC4033], I'm not entirely sure what the implications of section 3.6 are. What does that section imply for the work of this WG? I'm slightly uneasy with the requirement about wild cards and CNAME (and why not DNAME?) at the end of section 4. It's a little glib from my point of view, and I'm not actually sure what is supposed to be entailed. For instance, once answer to "be compatible with" is "use wildcards or use DANE, but not both." Is that ok? This is perhaps my most serious issue. I think I'd prefer to see text along the following lines instead: Wild Cards and DNS redirection: The mechanism for distributing DANE information must not be susceptible to subversion in the face of DNS wild card labels (*) and redirection chains (such as those resulting from CNAME or DNAME records). In the case of wild card labels, it is desirable that the mechanism work when the owner name is a wild card, so that it may cover any wild card expansion [note: is that what's intended? ajs]. In the case of redirection chains, it is desirable that the mechanism work when the owner name is the result of following redirection chains. I don't know if that's what was intended, and I'm sure that can be made into more elegant prose. Even with the above, I support moving ahead with this document. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ietf@augustcellars.com Thu May 5 13:48:03 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B912CE08ED for ; Thu, 5 May 2011 13:48:03 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZCPv5DdAiVi for ; Thu, 5 May 2011 13:48:03 -0700 (PDT) Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDCDE0750 for ; Thu, 5 May 2011 13:48:03 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp01.pacifier.net (Postfix) with ESMTPSA id 7F98A2CA61; Thu, 5 May 2011 13:48:02 -0700 (PDT) From: "Jim Schaad" To: , "Richard L. Barnes" References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> In-Reply-To: <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> Date: Thu, 5 May 2011 14:15:28 -0700 Message-ID: <00d401cc0b69$8f35ef90$ada1ceb0$@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: AQKLn3/Ps6X/LbhZOf22GW/Fk66M2AJ3VRcNkuvMH6A= Content-Language: en-us Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 05 May 2011 20:48:03 -0000 In section 3.1 - para #1 - I think there is a small technical error that may need to be addressed. If Charlie and Trent are the same person (i.e. Charlie's certificate is a self-signed certificate) would that certificate actually appear in the certificate_list structure. It is my understanding that self-signed certificates are generally omitted from this list. It would be more accurate to say that the certificate will appear in the chain tested by the PKIX path validation code. (This also deals with cases where a client takes the EE certificate from the structure and just uses the balance of the certificates as possible certificates to chain through. That is the certificate chain built is not the same as that in the TLS structure.) In section 3.2 the next the last paragraph refers to text in section 3.1 that I cannot find. It is also possible that there is text there that I just don't associate with the referring text. - It appears that section 3.1 should have text about Oscar - either that or the reference should be to section 3.4 Is there a use case where Alice wants to do multiple of these operations at the same time. That is she wants to do both a CA constraint and a Certificate constraint simultaneously? In section 3.4 - for item 3 - I assume that the references to Diane should be references to Oscar. I think that the last sentence in this section should use the word enforce rather than make. One presumes that Alice might be able to make requirements contractually. I think that case 3.5 really should occur in section 4. As the current text is written it appears to be more a requirement on how DANE is defined than on what Alice can do when implementing DANE. A better description of what I think you are really trying to say is: Alice would like to publish a web site where Bob will use a secure link if he is using a client which understands DANE, but will use an unsecure link in the event that DANE is not understood by the client. Note that as currently written, it is possible that the Encapsulation criteria in section 4 is counter to bullet point 3 in section 3.4 From hallam@gmail.com Thu May 5 16:03:02 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1051BE0729 for ; Thu, 5 May 2011 16:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T7zk4i8wDWm for ; Thu, 5 May 2011 16:03:01 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E2EA8E069D for ; Thu, 5 May 2011 16:03:00 -0700 (PDT) Received: by yxk30 with SMTP id 30so1176400yxk.31 for ; Thu, 05 May 2011 16:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kWtyd+R/tc3jNkbl7m9hQH1HaojkmuDa3RvPZj5jiAc=; b=FEeBff4xYdaNuPQ+bfCJeQdYd4S4ZPdx7PNwFekhcTsQyMhTCKZf7lQ17TiUKsBoDG kZcNuxudmS7+CHu0R+y+KhtLVAH7IwM5kAd1UBKcnJjMROq+Hpic2oSsZlPMXy0SiFf4 SzP6GnZEwp5Hk4YoIGdPML9ODl/cTFy7P9rJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uqviIkYmlkIxVFX0BTIhTOepazx0/UxMLjrsWwEtxC2ycFkfKnLn/TFKDcczOTHHoO pEbtdnWL3PnBYFxLugouZHpML+106hfOOtt+qg3/qpvVN1pU2matSXcyN+hVSMiQvbyO Z3g02yPMkM9Bt2jAZjlBTWlLsAyJCI3yCPB84= MIME-Version: 1.0 Received: by 10.101.23.4 with SMTP id a4mr1942578anj.50.1304636580375; Thu, 05 May 2011 16:03:00 -0700 (PDT) Received: by 10.100.178.6 with HTTP; Thu, 5 May 2011 16:03:00 -0700 (PDT) In-Reply-To: <20110505200315.GO25833@crankycanuck.ca> References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <20110505200315.GO25833@crankycanuck.ca> Date: Thu, 5 May 2011 19:03:00 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=00504502eb95ef2e1304a28f5f6b Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 05 May 2011 23:03:02 -0000 --00504502eb95ef2e1304a28f5f6b Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 5, 2011 at 4:03 PM, Andrew Sullivan wrote: > > I'm slightly uneasy with the requirement about wild cards and CNAME > (and why not DNAME?) at the end of section 4. It's a little glib from > my point of view, and I'm not actually sure what is supposed to be > entailed. For instance, once answer to "be compatible with" is "use > wildcards or use DANE, but not both." Is that ok? This is perhaps my > most serious issue. I think I'd prefer to see text along the > following lines instead: > Well this is a use cases and requirements document, so it would be OK if the goal was aspirational in my view. I think its OK for a proposal to only meet some of the requirements if it turns out that doing so has costs. In the case of wildcard and CNAME/DNAME support I think that the question comes down to whether this is a higher priority than efficiency or if both are hard requirements whether it is OK to special case for HTTP Web browsing interactions. -- Website: http://hallambaker.com/ --00504502eb95ef2e1304a28f5f6b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, May 5, 2011 at 4:03 PM, Andrew S= ullivan <ajs@shink= uro.com> wrote:

I'm slightly uneasy with the requirement about wild cards and CNAME
(and why not DNAME?) at the end of section 4. =A0It's a little glib fro= m
my point of view, and I'm not actually sure what is supposed to be
entailed. =A0For instance, once answer to "be compatible with" is= "use
wildcards or use DANE, but not both." =A0Is that ok? =A0This is perhap= s my
most serious issue. =A0I think I'd prefer to see text along the
following lines instead:

Well this is a= use cases and requirements document, so it would be OK if the goal was asp= irational in my view. I think its OK for a proposal to only meet some of th= e requirements if it turns out that doing so has costs.

In the case of wildcard and CNAME/DNAME support I think= that the question comes down to whether this is a higher priority than eff= iciency or if both are hard requirements whether it is OK to special case f= or HTTP Web browsing interactions.



--
Website: http://hallambaker.com/

--00504502eb95ef2e1304a28f5f6b-- From i.grok@comcast.net Sun May 8 11:18:25 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFE9E0707 for ; Sun, 8 May 2011 11:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQgqKDJnK6N6 for ; Sun, 8 May 2011 11:18:25 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id ED846E068B for ; Sun, 8 May 2011 11:18:24 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta04.westchester.pa.mail.comcast.net with comcast id h6JQ1g0020QuhwU546JQXm; Sun, 08 May 2011 18:18:24 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta02.westchester.pa.mail.comcast.net with comcast id h6JP1g00600PQ6U3N6JP2u; Sun, 08 May 2011 18:18:24 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p48IIJD9021979 for ; Sun, 8 May 2011 14:18:19 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p48IIJWq021977 for dane@ietf.org; Sun, 8 May 2011 14:18:19 -0400 Date: Sun, 8 May 2011 14:18:19 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20110508181819.GA21241@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 08 May 2011 18:18:26 -0000 On Fri, Apr 29, 2011 at 12:03:12PM -0400, Warren Kumari wrote: > Hi all, > > I think that Richard has integrated most of the comments received on-list into this most recent version of the doc and so, as I mentioned, we are going to kick off WGLC... > > Please get y'er comments in -- WGLC will be closing on 2011-05-13 at 16:00UTC (noonish EDT). > In section 3.3, the 5th paragraph mentions that an attacker can cause Bob to trust fake records if DNSSEC weren't required, but in the 4th paragraph, you said that's not always true, since Bob could reject Alice's TA. Suggested text: Providing trust anchor material in this way clearly requires DNSSEC, since corrupted or injected records could be used by an attacker to cause clients to trust an attacker's certificate (unless their ^^^^^^^^^^^^^^ local policy rejects the records for other reasons). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In section 3.4 (#3), there is a reference to Diane, but Diane is not one of the dramatis personae in section 3. Is Diane === Oscar? In section 4, Encapsulation, "a DANE information" should just be "DANE information". -- Scott Schmit From warren@kumari.net Wed May 11 10:46:42 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62C4E0802 for ; Wed, 11 May 2011 10:46:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XV1IA2Cq5XIh for ; Wed, 11 May 2011 10:46:42 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1FFE06C6 for ; Wed, 11 May 2011 10:46:39 -0700 (PDT) Received: from [172.19.118.237] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 27A081B40929; Wed, 11 May 2011 13:46:38 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> Date: Wed, 11 May 2011 13:46:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <978AB129-20D8-417B-B86A-79E1CEDC0158@kumari.net> References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 11 May 2011 17:46:43 -0000 On Apr 29, 2011, at 12:03 PM, Warren Kumari wrote: > Hi all, >=20 > I think that Richard has integrated most of the comments received = on-list into this most recent version of the doc and so, as I mentioned, = we are going to kick off WGLC... >=20 > Please get y'er comments in -- WGLC will be closing on 2011-05-13 at = 16:00UTC (noonish EDT). During the in-person meeting in Prague there were a large number of folk = who expressed a desire for this document -- well, now is the time to: a: show support or b: grump. There is no "c"! (AKA, I realize folk are busy, but please take a moment to provide = feedback...) W >=20 > W >=20 > On Apr 29, 2011, at 12:15 AM, Internet-Drafts@ietf.org wrote: >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the DNS-based Authentication of Named = Entities Working Group of the IETF. >>=20 >>=20 >> Title : Use Cases and Requirements for DNS-based = Authentication of Named Entities (DANE) >> Author(s) : R. Barnes >> Filename : draft-ietf-dane-use-cases-02.txt >> Pages : 11 >> Date : 2011-04-28 >>=20 >> Many current applications use the certificate-based authentication >> features in TLS to allow clients to verify that a connected server >> properly represents a desired domain name. Traditionally, this >> authentication has been based on PKIX trust hierarchies, rooted in >> well-known CAs, but additional information can be provided via the >> DNS itself. This document describes a set of use cases in which the >> DNS and DNSSEC could be used to make assertions that support the TLS >> authentication process. >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-02.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From warren@kumari.net Wed May 11 10:47:26 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE465E0802 for ; Wed, 11 May 2011 10:47: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2KVKYQS2b2H for ; Wed, 11 May 2011 10:47:26 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 14C62E06C6 for ; Wed, 11 May 2011 10:47:26 -0700 (PDT) Received: from [172.19.118.237] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 5016B1B40929; Wed, 11 May 2011 13:47:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <978AB129-20D8-417B-B86A-79E1CEDC0158@kumari.net> Date: Wed, 11 May 2011 13:47:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <342ED6F9-F5C5-40DF-80EF-DCFA67F5BFF6@kumari.net> References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <978AB129-20D8-417B-B86A-79E1CEDC0158@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 11 May 2011 17:47:26 -0000 On May 11, 2011, at 1:46 PM, Warren Kumari wrote: >=20 > On Apr 29, 2011, at 12:03 PM, Warren Kumari wrote: >=20 >> Hi all, >>=20 >> I think that Richard has integrated most of the comments received = on-list into this most recent version of the doc and so, as I mentioned, = we are going to kick off WGLC... >>=20 >> Please get y'er comments in -- WGLC will be closing on 2011-05-13 at = 16:00UTC (noonish EDT). >=20 > During the in-person meeting in Prague there were a large number of = folk who expressed a desire for this document -- well, now is the time = to: > a: show support or > b: grump. > There is no "c"! >=20 > (AKA, I realize folk are busy, but please take a moment to provide = feedback...) and, thanks to those who already did... W > W >=20 >=20 >>=20 >> W >>=20 >> On Apr 29, 2011, at 12:15 AM, Internet-Drafts@ietf.org wrote: >>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the DNS-based Authentication of Named = Entities Working Group of the IETF. >>>=20 >>>=20 >>> Title : Use Cases and Requirements for DNS-based = Authentication of Named Entities (DANE) >>> Author(s) : R. Barnes >>> Filename : draft-ietf-dane-use-cases-02.txt >>> Pages : 11 >>> Date : 2011-04-28 >>>=20 >>> Many current applications use the certificate-based authentication >>> features in TLS to allow clients to verify that a connected server >>> properly represents a desired domain name. Traditionally, this >>> authentication has been based on PKIX trust hierarchies, rooted in >>> well-known CAs, but additional information can be provided via the >>> DNS itself. This document describes a set of use cases in which the >>> DNS and DNSSEC could be used to make assertions that support the TLS >>> authentication process. >>>=20 >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-02.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 From ynir@checkpoint.com Wed May 11 12:17:10 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4735CE073A for ; Wed, 11 May 2011 12:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mdz0Dfq9qhm for ; Wed, 11 May 2011 12:17:09 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D2E3CE066E for ; Wed, 11 May 2011 12:17:08 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p4BJH55n031082; Wed, 11 May 2011 22:17:05 +0300 X-CheckPoint: {4DCAEDC2-0-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 11 May 2011 22:17:04 +0300 From: Yoav Nir To: Warren Kumari Date: Wed, 11 May 2011 22:17:02 +0300 Thread-Topic: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 Thread-Index: AcwQEAJuNAbYLZQ0SP6CWa/aj0iLCQ== Message-ID: <5A0DD6E4-B3DB-481E-9604-813A367CB64E@checkpoint.com> References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <978AB129-20D8-417B-B86A-79E1CEDC0158@kumari.net> In-Reply-To: <978AB129-20D8-417B-B86A-79E1CEDC0158@kumari.net> 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 Cc: "dane@ietf.org" Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 11 May 2011 19:17:10 -0000 On May 11, 2011, at 8:46 PM, Warren Kumari wrote: >=20 > On Apr 29, 2011, at 12:03 PM, Warren Kumari wrote: >=20 >> Hi all, >>=20 >> I think that Richard has integrated most of the comments received on-lis= t into this most recent version of the doc and so, as I mentioned, we are g= oing to kick off WGLC... >>=20 >> Please get y'er comments in -- WGLC will be closing on 2011-05-13 at 16= :00UTC (noonish EDT). >=20 > During the in-person meeting in Prague there were a large number of folk = who expressed a desire for this document -- well, now is the time to: > a: show support or > b: grump. > There is no "c"! Why do I have to choose? Can't I do both? OK. I support this document even as is. But still, here are a few comments: In section 3.1 we might add what PHB suggested in his CAA proposal - that C= As check the DNS before signing certificates, so if the DNS says that Alice= 's certificate must be signed by "ComSign Secured CA", Charlie won't sign i= t. The upside is that this begins to bring benefit as soon as the CAs updat= e their software - even before the browser vendors do. If the DNS record contained just the public key, you could even say the sam= e for section 3.2. Alice would generate a key pair, publish a DNS record w= ith the public key, and then request a certificate. No matter how well at a= ttacker could impersonate Alice to any CA, they would not be able to get th= e CA to sign any certificate with a different public key. Section 3.3: s/the certificate presented by the server was issued by Alice/= the certificate presented by the server has been issued by Alice/ Section 3.4 starts off with "In addition to guarding against CA mis-issue..= .". But nothing has previously been said about guarding against CA mis-issu= e. Unless you add text to cover my comments for sections 3.1 and 3.2. Other than that, I support this document. Yoav From paul@xelerance.com Wed May 11 12:53:56 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D109BE07BA for ; Wed, 11 May 2011 12:53:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTFXpoFTSltk for ; Wed, 11 May 2011 12:53:56 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB91E08AC for ; Wed, 11 May 2011 12:53:24 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 216F057081; Wed, 11 May 2011 15:53:22 -0400 (EDT) Date: Wed, 11 May 2011 15:53:21 -0400 (EDT) From: Paul Wouters To: Warren Kumari In-Reply-To: <978AB129-20D8-417B-B86A-79E1CEDC0158@kumari.net> Message-ID: References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <978AB129-20D8-417B-B86A-79E1CEDC0158@kumari.net> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 11 May 2011 19:53:56 -0000 On Wed, 11 May 2011, Warren Kumari wrote: >> Please get y'er comments in -- WGLC will be closing on 2011-05-13 at 16:00UTC (noonish EDT). > > During the in-person meeting in Prague there were a large number of folk who expressed a desire for this document -- well, now is the time to: > a: show support or > b: grump. > There is no "c"! I gave feedback last week. Assuming that goes in, especially the use case error on the level of trust of the DNS Operator with CA certs in DANE, I have no objections. Though seeing that out of this use cases document, no obvious changes to the dane 06 draft came to light, one could argue that perhaps those people in Prague were not as well informed, and that this document is not really needed either. Paul From paul.hoffman@vpnc.org Wed May 11 13:02:00 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADCAE08B9 for ; Wed, 11 May 2011 13:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGJBD0OYH2SW for ; Wed, 11 May 2011 13:01:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 412C1E07BA for ; Wed, 11 May 2011 13:01:59 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4BK1kkM029020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 May 2011 13:01:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <5A0DD6E4-B3DB-481E-9604-813A367CB64E@checkpoint.com> Date: Wed, 11 May 2011 13:01:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <978AB129-20D8-417B-B86A-79E1CEDC0158@kumari.net> <5A0DD6E4-B3DB-481E-9604-813A367CB64E@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1084) Cc: "dane@ietf.org" Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 11 May 2011 20:02:00 -0000 On May 11, 2011, at 12:17 PM, Yoav Nir wrote: > In section 3.1 we might add what PHB suggested in his CAA proposal - = that CAs check the DNS before signing certificates, so if the DNS says = that Alice's certificate must be signed by "ComSign Secured CA", Charlie = won't sign it. The upside is that this begins to bring benefit as soon = as the CAs update their software - even before the browser vendors do. Stated as a use case, that would be "Alice wants CAs compliant with the = protocol to not issue certificates for alice.example.com unless they = have a trust anchor that she has listed using the DANE protocol". The = related requirement is that the DANE protocol must be able to identify = trust anchor certificates in a way that a CA can determine whether or = not they are authorized under the protocol to issue new certificates. > If the DNS record contained just the public key, you could even say = the same for section 3.2. Alice would generate a key pair, publish a = DNS record with the public key, and then request a certificate. No = matter how well at attacker could impersonate Alice to any CA, they = would not be able to get the CA to sign any certificate with a different = public key. I *think* my proposed wording above covers that; please check. > Section 3.3: s/the certificate presented by the server was issued by = Alice/the certificate presented by the server has been issued by Alice/ >=20 > Section 3.4 starts off with "In addition to guarding against CA = mis-issue...". But nothing has previously been said about guarding = against CA mis-issue. Unless you add text to cover my comments for = sections 3.1 and 3.2. Good catch. --Paul Hoffman From hallam@gmail.com Wed May 11 13:23:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEA2E0780 for ; Wed, 11 May 2011 13:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6cUUkIi1M0j for ; Wed, 11 May 2011 13:23:13 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id B8662E0711 for ; Wed, 11 May 2011 13:23:12 -0700 (PDT) Received: by yic13 with SMTP id 13so377942yic.31 for ; Wed, 11 May 2011 13:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s6Jnz3vAhYn/BCHJj9TSxkbfEsvGBBfgP74aJhkjpJc=; b=OTEcWqcQWsZdxb5AyijpvSx+GHaKscvQ9dKA4vy8cIFyJgEjNfxvscXFRLsjCkxLox cYTRdY+v3036/NdYMOOXbpm3jSImMxAeWrJqxf2JxbRSnAFQ2HLYmX8EDMwZLbQwd2hu PYp73syiyM+0+rL94pyySYPHtFQ7UKHJSvdHU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sPhJQt1QV7nzLFf9RFz52+HMwFra6LwfyZ7V3lCsR1PqsGOG2aVQuArAhiNU3BNnlq PAdjHcrslwhAxkIonzOPuri58eNY9FGGQteX6sHFN1K1Lb/aA6mEmLppunt5Dsv7Armp 22gDJlmzDdJiudNDWisXUuQzKzdA+vIPuzK44= MIME-Version: 1.0 Received: by 10.100.15.5 with SMTP id 5mr5964498ano.6.1305145391180; Wed, 11 May 2011 13:23:11 -0700 (PDT) Received: by 10.100.178.6 with HTTP; Wed, 11 May 2011 13:23:11 -0700 (PDT) In-Reply-To: References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <978AB129-20D8-417B-B86A-79E1CEDC0158@kumari.net> Date: Wed, 11 May 2011 16:23:11 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e6475b5a6bec0804a305d77d Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 11 May 2011 20:23:13 -0000 --0016e6475b5a6bec0804a305d77d Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 11, 2011 at 3:53 PM, Paul Wouters wrote: > On Wed, 11 May 2011, Warren Kumari wrote: > > Please get y'er comments in -- WGLC will be closing on 2011-05-13 at >>> 16:00UTC (noonish EDT). >>> >> >> During the in-person meeting in Prague there were a large number of folk >> who expressed a desire for this document -- well, now is the time to: >> a: show support or >> b: grump. >> There is no "c"! >> > > I gave feedback last week. Assuming that goes in, especially the use case > error on the level of trust of the DNS Operator with CA certs in DANE, > I have no objections. > > Though seeing that out of this use cases document, no obvious changes > to the dane 06 draft came to light, one could argue that perhaps those > people in Prague were not as well informed, and that this document is > not really needed either. Or one could conclude that the various groups continue to fail to communicate. My problem with this process has been that people insisted on deriving the requirements from the proposed spec. When I proposed a different set of requirements that considered the problem from scratch I was told that this was not what 'the group' wants to do. So I am not at all surprised that you draw that conclusion, what other conclusion could there have been? -- Website: http://hallambaker.com/ --0016e6475b5a6bec0804a305d77d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, May 11, 2011 at 3:53 PM, Paul Wouters <paul@xelerance.com> wrote:
=
On Wed, 11 May 2011, Warren Kumari wrote:

Please get y'er comments in -- =A0WGLC will be closing on 2011-05-13 at= 16:00UTC (noonish EDT).

During the in-person meeting in Prague there were a large number of folk wh= o expressed a desire for this document =A0-- well, now is the time to:
a: show support or
b: grump.
There is no "c"!

I gave feedback last week. Assuming that goes in, especially the use case error on the level of trust of the DNS Operator with CA certs in DANE,
I have no objections.

Though seeing that out of this use cases document, no obvious changes
to the dane 06 draft came to light, one could argue that perhaps those
people in Prague were not as well informed, and that this document is
not really needed either.

Or one could conc= lude that the various groups continue to fail to communicate.
My problem with this process has been that people insisted on d= eriving the requirements from the proposed spec. When I proposed a differen= t set of requirements that considered the problem from scratch I was told t= hat this was not what 'the group' wants to do.

So I am not at all surprised that you draw that conclus= ion, what other conclusion could there have been?

=
--
Website: http://= hallambaker.com/

--0016e6475b5a6bec0804a305d77d-- From ynir@checkpoint.com Wed May 11 13:45:05 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FB4E0868 for ; Wed, 11 May 2011 13:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hd8yLA5RaVLU for ; Wed, 11 May 2011 13:45:04 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1C645E079B for ; Wed, 11 May 2011 13:45:03 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p4BKj1mQ010378; Wed, 11 May 2011 23:45:01 +0300 X-CheckPoint: {4DCB025E-1-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 11 May 2011 23:45:00 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 11 May 2011 23:45:00 +0300 From: Yoav Nir To: Paul Hoffman Date: Wed, 11 May 2011 23:44:59 +0300 Thread-Topic: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 Thread-Index: AcwQHEuWqLn7ChQNQNu84j85OviV0Q== Message-ID: References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <978AB129-20D8-417B-B86A-79E1CEDC0158@kumari.net> <5A0DD6E4-B3DB-481E-9604-813A367CB64E@checkpoint.com> 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 Cc: "dane@ietf.org" Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 11 May 2011 20:45:05 -0000 On May 11, 2011, at 11:01 PM, Paul Hoffman wrote: > On May 11, 2011, at 12:17 PM, Yoav Nir wrote: >=20 >> In section 3.1 we might add what PHB suggested in his CAA proposal - tha= t CAs check the DNS before signing certificates, so if the DNS says that Al= ice's certificate must be signed by "ComSign Secured CA", Charlie won't sig= n it. The upside is that this begins to bring benefit as soon as the CAs up= date their software - even before the browser vendors do. >=20 > Stated as a use case, that would be "Alice wants CAs compliant with the p= rotocol to not issue certificates for alice.example.com unless they have a = trust anchor that she has listed using the DANE protocol". The related requ= irement is that the DANE protocol must be able to identify trust anchor cer= tificates in a way that a CA can determine whether or not they are authoriz= ed under the protocol to issue new certificates. >=20 >> If the DNS record contained just the public key, you could even say the = same for section 3.2. Alice would generate a key pair, publish a DNS recor= d with the public key, and then request a certificate. No matter how well a= t attacker could impersonate Alice to any CA, they would not be able to get= the CA to sign any certificate with a different public key. >=20 > I *think* my proposed wording above covers that; please check. I don't think so. How about: "Alice wants CAs compliant with the protocol to not issue certificates for = alice.example.com unless the public key in those certificates matches what = she has listed using the DANE protocol." I realize that this may not work with the current DANE proposal, which hash= es the entire cert in the record. >=20 >> Section 3.3: s/the certificate presented by the server was issued by Ali= ce/the certificate presented by the server has been issued by Alice/ >>=20 >> Section 3.4 starts off with "In addition to guarding against CA mis-issu= e...". But nothing has previously been said about guarding against CA mis-i= ssue. Unless you add text to cover my comments for sections 3.1 and 3.2. >=20 > Good catch. >=20 From paul.hoffman@vpnc.org Wed May 11 13:55:59 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B005E0891 for ; Wed, 11 May 2011 13:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BO0hhW2gZGi for ; Wed, 11 May 2011 13:55:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 80ED9E0886 for ; Wed, 11 May 2011 13:55:58 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4BKtnD8031447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 May 2011 13:55:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Wed, 11 May 2011 13:55:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <978AB129-20D8-417B-B86A-79E1CEDC0158@kumari.net> <5A0DD6E4-B3DB-481E-9604-813A367CB64E@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1084) Cc: "dane@ietf.org" Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 11 May 2011 20:55:59 -0000 On May 11, 2011, at 1:44 PM, Yoav Nir wrote: >=20 > On May 11, 2011, at 11:01 PM, Paul Hoffman wrote: >=20 >> On May 11, 2011, at 12:17 PM, Yoav Nir wrote: >>=20 >>> In section 3.1 we might add what PHB suggested in his CAA proposal - = that CAs check the DNS before signing certificates, so if the DNS says = that Alice's certificate must be signed by "ComSign Secured CA", Charlie = won't sign it. The upside is that this begins to bring benefit as soon = as the CAs update their software - even before the browser vendors do. >>=20 >> Stated as a use case, that would be "Alice wants CAs compliant with = the protocol to not issue certificates for alice.example.com unless they = have a trust anchor that she has listed using the DANE protocol". The = related requirement is that the DANE protocol must be able to identify = trust anchor certificates in a way that a CA can determine whether or = not they are authorized under the protocol to issue new certificates. >>=20 >>> If the DNS record contained just the public key, you could even say = the same for section 3.2. Alice would generate a key pair, publish a = DNS record with the public key, and then request a certificate. No = matter how well at attacker could impersonate Alice to any CA, they = would not be able to get the CA to sign any certificate with a different = public key. >>=20 >> I *think* my proposed wording above covers that; please check. >=20 > I don't think so. How about: > "Alice wants CAs compliant with the protocol to not issue certificates = for alice.example.com unless the public key in those certificates = matches what she has listed using the DANE protocol." That seems OK, but it is very much not what CAA is doing. CAA specifies = the CA, not the trust anchor in my proposed text, and not the public key = in your proposed text. I thought that my proposed text was closer to = what users expect; given that Phill has been talking to other CAs for = the past few months, CAA may be closer to what CAs expect. My impression is that people here care more about restricting to a trust = anchor than to a key, but I could easily be wrong about that. This = discussion is a good way to hear those opinions. > I realize that this may not work with the current DANE proposal, which = hashes the entire cert in the record. The purpose of this exercise is not to match what we already have in the = protocol; it is to find what the WG wants to be there. Having said that, = it would be easy to add an additional RRtype to DANE that covers what = you have proposed, if people prefer that over what I proposed. --Paul Hoffman From ynir@checkpoint.com Wed May 11 13:59:42 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BF6E06F7 for ; Wed, 11 May 2011 13:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R104o2NzbO6u for ; Wed, 11 May 2011 13:59:42 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8144DE06CF for ; Wed, 11 May 2011 13:59:41 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p4BKxdfd012129; Wed, 11 May 2011 23:59:39 +0300 X-CheckPoint: {4DCB05CC-0-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 11 May 2011 23:59:38 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 11 May 2011 23:59:38 +0300 From: Yoav Nir To: Paul Hoffman Date: Wed, 11 May 2011 23:59:31 +0300 Thread-Topic: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 Thread-Index: AcwQHlcixAldrG0+QAahVIi2Gt223Q== Message-ID: References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <978AB129-20D8-417B-B86A-79E1CEDC0158@kumari.net> <5A0DD6E4-B3DB-481E-9604-813A367CB64E@checkpoint.com> 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 Cc: "dane@ietf.org" Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 11 May 2011 20:59:42 -0000 On May 11, 2011, at 11:55 PM, Paul Hoffman wrote: >=20 > On May 11, 2011, at 1:44 PM, Yoav Nir wrote: >=20 >>=20 >> On May 11, 2011, at 11:01 PM, Paul Hoffman wrote: >>=20 >>> On May 11, 2011, at 12:17 PM, Yoav Nir wrote: >>>=20 >>>> In section 3.1 we might add what PHB suggested in his CAA proposal - t= hat CAs check the DNS before signing certificates, so if the DNS says that = Alice's certificate must be signed by "ComSign Secured CA", Charlie won't s= ign it. The upside is that this begins to bring benefit as soon as the CAs = update their software - even before the browser vendors do. >>>=20 >>> Stated as a use case, that would be "Alice wants CAs compliant with the= protocol to not issue certificates for alice.example.com unless they have = a trust anchor that she has listed using the DANE protocol". The related re= quirement is that the DANE protocol must be able to identify trust anchor c= ertificates in a way that a CA can determine whether or not they are author= ized under the protocol to issue new certificates. >>>=20 >>>> If the DNS record contained just the public key, you could even say th= e same for section 3.2. Alice would generate a key pair, publish a DNS rec= ord with the public key, and then request a certificate. No matter how well= at attacker could impersonate Alice to any CA, they would not be able to g= et the CA to sign any certificate with a different public key. >>>=20 >>> I *think* my proposed wording above covers that; please check. >>=20 >> I don't think so. How about: >> "Alice wants CAs compliant with the protocol to not issue certificates f= or alice.example.com unless the public key in those certificates matches wh= at she has listed using the DANE protocol." >=20 > That seems OK, but it is very much not what CAA is doing. CAA specifies t= he CA, not the trust anchor in my proposed text, and not the public key in = your proposed text. I thought that my proposed text was closer to what user= s expect; given that Phill has been talking to other CAs for the past few m= onths, CAA may be closer to what CAs expect. I meant your text for 3.1 and mine for 3.2. >=20 > My impression is that people here care more about restricting to a trust = anchor than to a key, but I could easily be wrong about that. This discussi= on is a good way to hear those opinions. I think there's lots of people here with different things they care about. = I care more about domain-issued certificates. >=20 >> I realize that this may not work with the current DANE proposal, which h= ashes the entire cert in the record. >=20 > The purpose of this exercise is not to match what we already have in the = protocol; it is to find what the WG wants to be there. Having said that, it= would be easy to add an additional RRtype to DANE that covers what you hav= e proposed, if people prefer that over what I proposed. >=20 > --Paul Hoffman >=20 >=20 > Scanned by Check Point Total Security Gateway. From matt@mattmccutchen.net Fri May 13 08:57:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1ADE06DB for ; Fri, 13 May 2011 08:57:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RF1uMcZBKpc for ; Fri, 13 May 2011 08:57:29 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 28EA1E0685 for ; Fri, 13 May 2011 08:57:29 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 898CE208069 for ; Fri, 13 May 2011 08:57:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=l4lh+KZ6CMIN/4RtSlZoLkhj7lv8qyJ80z/4xknA68U Cd4BV65dfXwju+8GJEnBnaRM46A5e1lsIk6PKQMF60sG85SA2axResgMPa4OmL2a cXi1llCYogEdDnCrhkapbVfyDu+C07R6viDm7TsGTN9n7Jy08GPbd302S4aKkvZE = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=zF0el7g8nS6D3NAe0TrZkgt05dM=; b=Ith4Qpmx/9 CvDsZ+x9JjTUKGXMSzD5RemNmstSddcG6u1p5EUnOvm8eiqPd802DOUvGMw1WqRs w2T/Aoaxr/cr12q19gdxK+lNcm28Zb5rhutQKG2Ua2TlE76zM3TwnglGiK3b74jb 3Qreuma17kwXC/d/f7aLsGmea3NXePN+E= Received: from [10.108.76.118] (unknown [129.2.129.86]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPSA id 4C3B220806B for ; Fri, 13 May 2011 08:57:28 -0700 (PDT) From: Matt McCutchen To: dane In-Reply-To: <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> Content-Type: text/plain; charset="UTF-8" Date: Fri, 13 May 2011 11:57:24 -0400 Message-ID: <1305302244.3471.21.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 13 May 2011 15:57:30 -0000 On Fri, 2011-04-29 at 12:03 -0400, Warren Kumari wrote: > I think that Richard has integrated most of the comments received > on-list into this most recent version of the doc and so, as I > mentioned, we are going to kick off WGLC... > > Please get y'er comments in -- WGLC will be closing on 2011-05-13 at > 16:00UTC (noonish EDT). In general, I'm very happy with the document. It provides an even-handed discussion of a number of touchy issues. Some suggestions: - The security considerations in Section 3.1 could be clarified. Here is some alternative text as inspiration: ----- Because these constraints do not increase the set of cases in which server authentication succeeds, no security is lost by processing the records even if they are retrieved without DNSSEC. No matter what an attacker does to the records, Bob will still require a valid PKIX certificate that chains to a trust anchor, so he will achieve the same level of security as without DANE. However, security is only gained if the records are DNSSEC signed and Bob is willing to fail unless he can get a "secure" or verified "insecure" DNSSEC response. An attacker with the ability to modify DNS responses as seen by Bob can cause a denial of service by falsifying the DANE records, but in general he can do so just as easily by falsifying the A or AAAA records, so this is not a new risk. ----- - This text does not belong in Section 3.3: Deleted records will only result in connection failure and denial of service, although this could result in clients re-connecting without TLS (a downgrade attack), depending on the application. Therefore, in order for this use case to be safe, applications must forbid clients from falling back to unsecured channels when records appear to have been deleted (e.g., when a missing record has no NSEC or NSEC3 record). Preventing a downgrade from TLS to non-TLS is, strictly speaking, an orthogonal issue to TLS server authentication. My understanding was that the scope of DANE was only the latter, and the former would be addressed with HASTLS or some such. If the downgrade prevention is to be mentioned here, it should be its own use case; it is not in any way specific to the use of domain-issued certificates. - Re the newfound power of DNSSEC zone operators under DANE (Section 3.3): I would not attempt to minimize this issue. CAs will not hesitate to remind us of the extra checks they perform for certain sites, so the comparison to domain validation is not entirely correct. Sites that have special relationships with CAs but do not have proper oversight of their DNSSEC zones will, indeed, have their security weakened when clients adopt DANE. If we are concerned about this, I think the natural solution is to have a flag with each DNSSEC delegation that indicates that the registrant fully trusts the child zone operator and hence schemes such as DANE can be enabled. - Section 3.4: I don't understand the motivation for constraining the certificates used by an outsourcing provider. If the provider is operating the service, what security benefit can there be to forcing the provider to use a particular certificate? Is this something I missed in the discussion? -- Matt From Jeff.Hodges@KingsMountain.com Fri May 13 09:33:30 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D40E06B9 for ; Fri, 13 May 2011 09:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1KbD5m+qWdv for ; Fri, 13 May 2011 09:33:30 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by ietfa.amsl.com (Postfix) with SMTP id 271C0E0671 for ; Fri, 13 May 2011 09:33:30 -0700 (PDT) Received: (qmail 11810 invoked by uid 0); 13 May 2011 16:33:29 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy2.bluehost.com with SMTP; 13 May 2011 16:33:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=WIxWL3gEWp3VYwReTp291BtOHASADZDfOrHvpfu3ua0KjJoqPqLH6N+wzAeWUHNWrZ98vdQDzZGTjctl0yBnSsM8RFnU/U1Q/hf2vLbnRZu7ex4LTjp8VLhq20PhYiGP; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.232]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QKvIv-0003dI-3e for dane@ietf.org; Fri, 13 May 2011 10:33:29 -0600 Message-ID: <4DCD5D59.5020609@KingsMountain.com> Date: Fri, 13 May 2011 09:33:29 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dane] DNSSEC optionality (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 13 May 2011 16:33:30 -0000 Both PaulW and JimS note that the security analysis of the S3.1 CA Constraints use case attempts to justify the optionality of DNSSEC.. Paul Wouters: http://www.ietf.org/mail-archive/web/dane/current/msg02559.html Jim Schaad http://www.ietf.org/mail-archive/web/dane/current/msg02564.html In overall support of their views, I although note that the security analysis of the S3.1 CA Constraints use case could be updated to not state a requirement (DNSSEC optionality), and to more thoroughly analyze the case (as they both have done). I agree that there doesn't appear to be very much of a justification for deploying DANE records is one isn't going to do so securely, and this should be made clear in some fashion. However, having a MUST functional requirement of performing DNSSEC validation by the application service client is not possible to satisfy in general today and for the forseeable future due to the so-called "DNSSEC last-mile problem". So realistically it should be a SHOULD and this last-mile issue noted. =JeffH From Jeff.Hodges@KingsMountain.com Fri May 13 09:33:40 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA325E071E for ; Fri, 13 May 2011 09:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqmNYEawrU9K for ; Fri, 13 May 2011 09:33:40 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 4DB01E0671 for ; Fri, 13 May 2011 09:33:40 -0700 (PDT) Received: (qmail 23292 invoked by uid 0); 13 May 2011 16:33:40 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 13 May 2011 16:33:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=pCkTdokaB95KfYkdz9vUvwc1j4imy55Sz2xXCQWlpur5eq9Wpsl8DE49E3bnh1IvIbYfiUtzd7kAKbFFa3swREYxtSjnRwqJZv2MgjxTCVvpNvqpEIa78Tc7kSlfnlGb; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.232]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QKvJ5-0003pc-GO for dane@ietf.org; Fri, 13 May 2011 10:33:39 -0600 Message-ID: <4DCD5D64.5040306@KingsMountain.com> Date: Fri, 13 May 2011 09:33:40 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dane] DNS wildcards (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 13 May 2011 16:33:41 -0000 Andrew Sullivan said.. > > I'm slightly uneasy with the requirement about wild cards and CNAME > (and why not DNAME?) at the end of section 4. It's a little glib from > my point of view, and I'm not actually sure what is supposed to be > entailed. For instance, once answer to "be compatible with" is "use > wildcards or use DANE, but not both." Is that ok? This is perhaps my > most serious issue. I think I'd prefer to see text along the > following lines instead: > > Wild Cards and DNS redirection: The mechanism for distributing DANE > information must not be susceptible to subversion in the face of > DNS wild card labels (*) and redirection chains (such as those > resulting from CNAME or DNAME records). In the case of wild > card labels, it is desirable that the mechanism work when the > owner name is a wild card, so that it may cover any wild card > expansion [note: is that what's intended? ajs]. In the case of > redirection chains, it is desirable that the mechanism work when > the owner name is the result of following redirection chains. > this seems like a reasonable re-statement of that functional requirement -- does it correctly state was is intended/desired behavior ? =JeffH From Jeff.Hodges@KingsMountain.com Fri May 13 09:33:46 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EDEE07DD for ; Fri, 13 May 2011 09:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USb8jKKZxp+F for ; Fri, 13 May 2011 09:33:46 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 390F3E07DC for ; Fri, 13 May 2011 09:33:46 -0700 (PDT) Received: (qmail 23477 invoked by uid 0); 13 May 2011 16:33:46 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 13 May 2011 16:33:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=JHfDFO6fdGCeX8I1Q4+qaRDVS+BlqJMk2p2ub7Mm06nmyC2iHTYU8gaLeRV7XhbvEWMfvh5c20xH+KjYi9ACanxd4qp/ObzccfOijIkGGRb9E95Ue19G4bVoz9aFzf6S; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.232]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QKvJB-0003wB-Ki for dane@ietf.org; Fri, 13 May 2011 10:33:45 -0600 Message-ID: <4DCD5D6A.7080203@KingsMountain.com> Date: Fri, 13 May 2011 09:33:46 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dane] simultaneous use cases (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 13 May 2011 16:33:46 -0000 Jim Schaad mused.. > > Is there a use case where Alice wants to do multiple of these operations at > the same time. That is she wants to do both a CA constraint and a > Certificate constraint simultaneously? this is a good question. Possibly. Others have thoughts? =JeffH From Jeff.Hodges@KingsMountain.com Fri May 13 09:34:09 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF91E070C for ; Fri, 13 May 2011 09:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hoa2RTQaH7EO for ; Fri, 13 May 2011 09:34:07 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id DD31FE0671 for ; Fri, 13 May 2011 09:34:06 -0700 (PDT) Received: (qmail 30163 invoked by uid 0); 13 May 2011 16:34:06 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 13 May 2011 16:34:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=gUV5DqZcKxqfM4bdNGuyf2Ra23pQe7DGcJIitUqfzywL8iP0gsVDpsh3asdGaFCarEbpMBSPbkM+AMUVqXvt1vELgP0UEWAHvsP4zt5AR1TyHRlY+l9R3AUizohp1svS; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.232]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QKvJW-0004JQ-E5 for dane@ietf.org; Fri, 13 May 2011 10:34:06 -0600 Message-ID: <4DCD5D7F.7030004@KingsMountain.com> Date: Fri, 13 May 2011 09:34:07 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [dane] comments on draft-ietf-dane-use-cases-02 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, 13 May 2011 16:34:09 -0000 overall, I support the WG decision to produce this document. If the WG wishes it to remain simply an I-D for WG-internal reference, then it doesn't necessarily need the full polish of all the below editorial comments, but still should be updated w.r.t. the more substantive comments, I believe. However, if it is to be issued as an RFC, then it needs polishing IMV such that it is not unnecessarily misleading or obtuse to readers who are not enmeshed in the WG's work. If DANE work ultimately is successful and deployed, it will be very helpful if a foundational document such as this one is clear and accurate detail-wise. I am willing to help edit the doc source if needed/desired. HTH, =JeffH ------ comments on draft-ietf-dane-use-cases-02 Jeff Hodges overall comments: 1. state explicitly that these use cases are applicable to any app service protocol layered over TLS, i.e. they don't apply to only HTTP/TLS. 2. leverage terminology from RFC6125. global editorial edits (though may need to be applied in case-by-case basis).. s/service/application service/g s/TLS client/application service client/g s/domain owner/domain holder/g s/owners of domains/domain holders/g Stylistically, I'd prefer to use terms such as "Trent's CA" rather than "the CA Trent". Maybe it's just me, but the former seems to read better since we're using anthropomorphic natural names to denote the actors. detailed inline comments... [ some page headers/footers and boilerplate are elided ] > DANE R. Barnes > Internet-Draft BBN Technologies > Intended status: Informational April 29, 2011 > Expires: October 31, 2011 > > > Use Cases and Requirements for DNS-based Authentication of Named > Entities (DANE) > draft-ietf-dane-use-cases-02.txt > > Abstract > > Many current applications use the certificate-based authentication > features in TLS to allow clients to verify that a connected server > properly represents a desired domain name. this first sentence needs rewriting; detailed comments below in Introduction section. > Traditionally, this > authentication has been based on PKIX trust hierarchies, rooted in > well-known CAs, but additional information can be provided via the > DNS itself. This document describes a set of use cases in which the > DNS and DNSSEC could be used to make assertions that support the TLS > authentication process. > > Status of this Memo > > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3.1. CA Constraints . . . . . . . . . . . . . . . . . . . . . . 4 > 3.2. Certificate Constraints . . . . . . . . . . . . . . . . . 5 > 3.3. Domain-Issued Certificates . . . . . . . . . . . . . . . . 6 > 3.4. Delegated Services . . . . . . . . . . . . . . . . . . . . 7 > 3.5. Opportunistic Security . . . . . . . . . . . . . . . . . . 8 > 3.6. Web Services . . . . . . . . . . . . . . . . . . . . . . . 8 > 4. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 9 > 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 > 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 > 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 > 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 > 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 > > > > > 1. Introduction > > Transport-Layer Security or TLS is used as the basis for security s/Transport-Layer Security or TLS/Transport Layer Security (TLS)/ > features in many modern Internet applications [RFC5246]. It > underlies secure HTTP and secure email [RFC2818][RFC2595][RFC3207], > and provides hop-by-hop security in real-time multimedia and instant- > messaging protocols [RFC3261][RFC6120]. > > One feature that is common to most uses of TLS is the use of > certificates to authenticate domain names for services. The latter sentence seems to me to make an inaccurate claim about TLS and its relation to domain names. The TLS handshake, and thus "the TLS layer", doesn't itself "authenticate domain names for services". Rather, "server identity checking" is done in the application service layer (not in the TLS layer), after a successful TLS handshake, and is comprised only of checking whether there's a match between presented identifier(s) found in the cert (potentially in various locations) and reference identifier(s) derived from the source domain(s) and optionally, an application service type. It is sort of a crude form of channel binding. RFC6125 specifies the gory details. Additionally, this matching is not "authentication" of the source domain name in a strict sense because there's no cryptographic authentication of the data resulting from the dereferencing of the domain name via DNS, neither is there cryptographic peer-entity authn of the DNS server, hence the DNS resolution can be transparently spoofed. DANE is about binding cryptographically-based domain name resolution (i.e. DNSSEC-secured DNS resolution) into application service TLS connection establishment such that we do in fact have cryptographic assurance of the bindings between the matched domain name, its DNS records, the presented TLS certificate, and the connection with the peer entity. I've massaged the introduction accordingly. I leverage terms from RFC6125 as appropriate (see its glossary for details). it also introduces the "mis-issued" situation.. > Transport-Layer Security or TLS is used as the basis for security > features in many modern Internet applications [RFC5246]. It > underlies secure HTTP and secure email [RFC2818][RFC2595][RFC3207], > and provides hop-by-hop security in real-time multimedia and instant- > messaging protocols [RFC3261][RFC6120]. > > One feature that is common to most uses of TLS is the use of > certificates to authenticate domain names for services. The TLS > client begins the TLS connection process with the goal of connecting > to a server with a specific domain name. (The process of obtaining > this domain name is application-specific. It could be entered by a > user or found through an automated discovery process, e.g., via an > SRV or NAPTR record.) After obtaining the address of the server via > an A or AAAA record, the client conducts a TLS handshake with the > server, during which the server presents a PKIX certificate for > itself [RFC5280]. Based on this certificate, the client decides > whether the server properly represents the desired domain name, and > thus whether to proceed with the TLS connection or not. > > In most current applications, this decision process is based on PKIX > validation and application-specific name matching. The client > validates that the certificate chains to a trust anchor [RFC5280], > and that the desired domain name is contained in the certificate > [RFC6125]. Within this framework, bindings between public keys and > domain names are asserted by PKIX CAs. Authentication decisions > based on these bindings rely on the authority of these CAs. > > The DNS is built to provide information about domain names, and with > the advent of DNSSEC [RFC1034][RFC4033], it is possible for this > information to be provided securely, in the sense that clients can > verify that DNS information was provided by the domain owner. The > goal of technologies for DNS-based Authentication of Named Entities > (DANE) is to use the DNS and DNSSEC to provide additional information > to inform the TLS domain authentication process. This document > describes a set of use cases that capture specific goals for using > the DNS in this way, and a set of requirements that the ultimate DANE > mechanism should satisfy. > Transport Layer Security (TLS) is used by many modern Internet application service protocols to provide secure client-server connections [RFC5246]. It underlies secure HTTP and secure email [RFC2818][RFC2595][RFC3207], and provides hop-by-hop security in real-time multimedia and instant messaging protocols [RFC3261][RFC6120]. Application service clients typically establish TLS connections to application servers denoted by DNS domain names. The process of obtaining this "source" domain name is application specific (it could be entered by a user or found through an automated discovery process, e.g., via an SRV or NAPTR record). After obtaining the address of the server via an A or AAAA DNS record, the client conducts a TLS handshake with the server, during which the server presents its PKIX certificate [RFC5280]. The TLS layer performs PKIX validation of the certificate including verification that the certificate chains to a trust anchor. If successful, then the application layer ascertains whether the application service DNS name in the presented certificate matches the source domain name [RFC6125], and typically proceeds with the TLS connection if so. Thus certificate authorities (CAs) are asserting bindings between domain names and the public keys they certify, and application service clients are making authorization decisions--whether to proceed with connections--based on these bindings. However, unless there is a cryptographic binding between information in the TLS channel and information in the DNS resolution channel, as well as authentication of the DNS interaction and the returned DNS data, the information obtained via the DNS is vulnerable to being misrepresented or tampered with, thus allowing for man-in-the-middle (MITM) impersonation of the application service. Such MITM impersonation can today be accomplished by a network attacker by obtaining a so-called "mis-issued" certificate (obtained, for example, from a compromised member of the set of well-known widely trusted-by-default CAs [ref?]) for some victim application service domain, and using it along with "poisoned" DNS resolution such that an arbitrary server of the network attacker's choice appears to legitimately serve the victim application service. With the advent of DNSSEC [RFC4033], it is now possible for DNS name resolution to provide its information securely, in the sense that clients can verify that DNS information was provided by the domain holder and not tampered with in transit. The goal of technologies for DNS-based Authentication of Named Entities (DANE) is to use DNSSEC-secured DNS information to provide cryptographic assurance of domain name resolution in application service TLS connection establishment. This document describes a set of use cases that capture specific goals for using the DNS in this way, and a set of requirements that the ultimate DANE mechanism should satisfy. > 2. Definitions > > This document also makes use of standard PKIX, DNSSEC, and TLS > terminology. See RFC 5280 [RFC5280], RFC 4033 [RFC4033], and RFC > 5246 [RFC5246], respectively, for these terms. > > Note in particular that the term "server" in this document refers to > the server role in TLS, rather than to a host. Multiple servers of > this type may be co-located on a single physical host, using > different ports, and each of these can use different certificates. also reference terminology section in RFC6125 ? > > > 3. Use Cases > > In this section, we describe the major use cases that the DANE > mechanism should support. This list is not intended to represent all > possible ways that the DNS can be used to support TLS authentication. s/the DNS/secure DNS/ > Rather it represents the specific cases that comprise the initial > goal for DANE. > > In the below use cases, we will refer to the following dramatis > personae: > > Alice The operator of a TLS-protected service on the host > alice.example.com, and administrator of the corresponding DNS > zone. > > Bob A client connecting to alice.example.com > > Charlie A well-known CA that issues certificates with domain names > as identifiers > > Oscar An outsourcing provider that operates TLS-protected services > on behalf of customers > > Trent A CA that issues certificates with domain names as > identifiers, but is not generally well-known. I'd fix up the source to better align the above items > These use cases are framed in terms of adding protections to TLS > server certificates, since the use of these certificates to > authenticate server domain names is very common. In applications > where TLS clients are also identified by domain names (e.g., XMPP > server-to-server connections), the same considerations and use cases > can also be applied to TLS client certificates. rewrite latter para: These use cases are framed in terms of adding verification steps to TLS server identity checking on the part of application service clients. In application services where the clients are also identified by domain names (e.g., XMPP server-to-server connections), the same considerations and use cases can also be applied to TLS application client certificates. > > 3.1. CA Constraints I would add a short intro para explaining why this use case is named "CA constraints". > > Alice runs a website on alice.example.com and has obtained a > certificate from the well-known CA Charlie. She is concerned that > other well-known CAs might issue certificates for alice.example.com > without her authorization, which clients would accept. Alice would > like to provide a mechanism for visitors to her site to know that > they should expect alice.example.com to use a certificate issued > under the CA that she uses (Charlie) and not another CA. In TLS > terms, Alice is letting Bob know that Charlie's certificate must > appear somewhere in the server Certificate message's certificate_list > structure. s/structure./structure [RFC5246]./ Also noting Jim Schaad's first comment in this message.. http://www.ietf.org/mail-archive/web/dane/current/msg02566.html ..the last sentence may require further work. I.e. it may be unnecessarily specific w.r.t. TLS protocol handshake message contents. perhaps.. In TLS terms, Alice is letting Bob know that Charlie's certificate is the "root certificate" [RFC5246], also known as a "trust anchor", and that her certificate must "chain" to Charlie's trust anchor when its evaluated for validity by Bob's TLS client. > > When Bob connects to alice.example.com, he uses this mechanism to > verify that that the certificate presented by the server was issued > under the proper CA, Charlie. Bob also performs the normal PKIX > validation procedure for this certificate, in particular verifying > that the certificate chains to a trust anchor. s/a trust anchor./Charlie's trust anchor./ I would encapsulate the below paras in a subsection entitled something like "use case security analysis and derived requirements" because, strictly speaking, they aren't part of the use case... > > Because these constraints do not increase the scope of PKIX-based > assertions about domains, there is not a strict requirement for > DNSSEC. Deletion of records removes the protection provided by this > constraint, but the client is still protected by CA practices (as > now). Injected or modified false records are not useful unless the > attacker can also obtain a certificate for the target domain. In the > worst case, tampering with these constraints increases the risk of > false authentication to the level that is now standard. > > Injected or modified false records can be used for denial of service, > even if the attacker does not have a certificate for the target > domain. If an attacker can modify DNS responses that a target host > receives, however, there are already much simpler ways of denying > service, such as providing a false A or AAAA record. In this case, > DNSSEC is not helpful, since an attacker could still case a denial of > service by blocking all DNS responses for the target domain. > > Continuing to require PKIX validation also limits the degree to which > DNS operators (as distinct from the owners of domains) can interfere > with TLS authentication through this mechanism. As above, even if a > DNS operator falsifies DANE records, it cannot masquerade as the > target server unless it can also obtain a certificate for the target > domain. Is the point of attempting to justify the optionality of DNSSEC in this use case to illustrate that Alice can obtain (some level of) CA exclusivity (aka a "CA constraint") even w/o DNSSEC ? I.E. an attacker who successfully obtains an otherwise valid mis-issued cert for Alice's domain would have to also poison/alter/spoof/block DNS for Alice's domain in order to successfully fool a DANE-compliant client into accepting the cert. However, as Jim Schaad and PaulW have pointed out, DANE w/o DNSSEC in this case is only making such an attack somewhat harder, but certainly not impossible. This should be noted in the analysis. This also raises questions that should probably be mentioned in the security analysis and derived requirements: hard fail on DANE errors ? or forsee facilitating user click-throughs ? > 3.2. Certificate Constraints I would add a short intro para explaining why this use case is named "Certificate constraints". > > Alice runs a website on alice.example.com and has obtained a > certificate from the well-known CA Charlie. She is concerned about > additional, unauthorized certificates being issued by Charlie as well > as by other CAs. She would like to provide a way for visitors to her > site to know that they should expect alice.example.com to present the > specific certificate issued by Charlie. In TLS terms, Alice is > letting Bob know that this specific certificate must be the first > certificate in the server Certificate message's certificate_list > structure. s/structure./structure [RFC5246]./ > > When Bob connects to alice.example.com, he uses this mechanism to > verify that that the certificate presented by the server is the > correct certificate. Bob also performs the normal PKIX validation > > > > Barnes Expires October 31, 2011 [Page 5] > > Internet-Draft DANE Use Cases April 2011 > > > procedure for this certificate, in particular verifying that the > certificate chains to a trust anchor. s/a trust anchor./Charlie's trust anchor, which was supplied to Bob out-of-band of this interaction./ I would encapsulate the below paras in a subsection entitled something like "use case security analysis and derived requirements"... > > As in Section 3.1., Alice's assertions about server certificates can > be used to constrain the behavior of an outsourcing provider Oscar as > well as the CA Charlie and other CAs. Such a certificate constraint > requires Oscar to present the specified certificate to clients and > not another. does the latter para really need to be here? it's essentially a hint about what's to come in section 3.4. JimS also noticed this. http://www.ietf.org/mail-archive/web/dane/current/msg02566.html > > The other security considerations for this case are the same as for > the "CA Constraints" case above. > 3.3. Domain-Issued Certificates "self issued certificate" seems to be a more commonly used term if one searches the net for both terms. though i think i can understand why you may want to use "domain issued" (arguably more technically accurate?). might want a brief intro para and equate the two terms. > > Alice would like to be able to use generate and use certificates for > her website on alice.example.com without involving an external CA at > all. Alice can generate her own certificates today, making self- > signed certificates and possibly certificates subordinate to those > certificates. When Bob receives such a certificate, however, he > doesn't have a way to verify that the issuer of the certificate is > actually Alice. rewrite last sentence: When Bob receives such a certificate in a TLS handshake, however, he doesn't automatically have a way to verify that the issuer of the certificate is actually Alice, because he doesn't necessarily possess Alice's corresponding trust anchor. > This concerns him because an attacker could present > a different certificate and perform a man in the middle attack. Bob > would like to protect against this. > > Alice would thus like to have a mechanism for visitors to her site to > know that the certificates she issues are actually hers. s/the certificates she issues are actually hers/the presented certificates are legitimately hers./ > When Bob > connects to alice.example.com, he uses this mechanism to verify that > the certificate presented by the server was issued by Alice. Since > Bob can bind certificates to Alice in this way, he can use Alice's CA > as a trust anchor for purposes of validating certificates for > alice.example.com. Alice can additionally recommend that clients > accept only her certificates using the CA constraints described > above. > > This use case is functionally equivalent to the case where Alice > doesn't issue her own certificates, but uses a CA Trent that is not s/a CA Trent/Trent's CA/ > well-known. In this case, Alice would be advising Bob that he should > treat Trent as a trust anchor for purposes of validating Alice's > certificates, rather than a CA operated by Alice herself. this implies that Bob has to obtain Trent's trust anchor (TA) cert in some secure fashion. the below says Alice advertises TA material, so it should be said explicitly above. I would encapsulate the below paras in a subsection entitled something like "use case security analysis and derived requirements"... > > Alice's advertising of trust anchor material in this way does not > guarantee that Bob will accept the advertised trust anchor. For > example, Bob might have out-of-band information (such as a pre- > existing local policy) that indicates that the CA Trent advertised by > Alice is not trustworthy, which would lead him to decide not to > accept Trent as a TA, and thus to reject Alice's certificate if it is > issued under Trent. > > Providing trust anchor material in this way clearly requires DNSSEC, > since corrupted or injected records could be used by an attacker to > cause clients to trust an attacker's certificate. because here the Relying Party (RP aka client) is accepting the TA material from (supposed) Alice (?), and doesn't otherwise already have it ? > Deleted records > will only result in connection failure and denial of service, > although this could result in clients re-connecting without TLS (a > downgrade attack), depending on the application. Therefore, in order > for this use case to be safe, applications must forbid clients from > falling back to unsecured channels when records appear to have been > deleted (e.g., when a missing record has no NSEC or NSEC3 record). > > By the same token, this use case puts the most power in the hands of > DNS operators. Since the operator of the appropriate DNS zone has de > facto control over the content and signing of the zone, he can create > false DANE records that bind a malicious party's certificate to a > domain. This risk is especially important to keep in mind in cases > where the operator of a DNS zone is a different entity than the owner > of the domain, as in DNS hosting/outsourcing arrangements, since in > these cases the DNS operator might be able to make changes to a > domain that are not authorized by the owner of the domain. > > This is not a significant incremental risk, however, relative to the > current PKIX-based system. In the current system, CAs need to verify > that an entity requesting a certificate for a domain is actually the > legitimate holder of that domain. Typically this is done using > information published about that domain, such as WHOIS email > addresses or special records inserted into a domain. By manipulating > these values, it is possible for DNS operators to obtain certificates > from some well-known certificate authorities today without > authorization from the true domain owner. > 3.4. Delegated Services > > In addition to guarding against CA mis-issue, CA constraints and > certificate constraints can also be used to constrain the set of > certificates that can be used by an outsourcing provider. Suppose > that Oscar operates alice.example.com on behalf of Alice. In > particular, Oscar then has de facto control over what certificates to > present in TLS handshakes for alice.example.com. In such cases, > there are few ways that DNS-based information about TLS certificates s/few/only a few/ > could be configured, for example: > > 1. Alice has the A/AAAA records in her DNS and can sign them along > with the DANE record, but Oscar and Alice now need to have tight > coordination if the addresses and/or the certificates change. > > 2. Alice refers to Oscar's DNS by delegating a sub-domain name to > Oscar, and has no control over the A/AAAA, DANE or any other > pieces under Oscar's control. this appears to be the typical content-delivery approach for web app components, eg images , but overlooks the case where alice's entire web app is delegated to Oscar (?) > 3. Alice can put DANE records into her DNS server, but delegate the > address records to Diane's DNS server. Diane not in dramatis personae should Diane be Oscar ? > This means that Alice can > control the usage of certificates but Diane is free to move the > servers around as needed. The only coordination needed is when > the certificates change, and then it would depend on how the DANE > record is setup (i.e. a CA or an EE certificate pointer). > > Which of these deployment patterns is used in a given deployment will > determine what sort of constraints can be made. In cases where Alice > controls DANE records (1 and 3), she can use CA and certificate > constraints to control what certificates Oscar presents for Alice's > services. For instance, Alice might require Oscar to use > certificates under a given set of CAs. This control, however, > requires that Alice update DANE records when Oscar needs to change > certificates. Cases where Oscar controls DANE records allow Oscar to > maintain more autonomy from Alice, but by the same token, Alice > cannot make any requirements on the certificates that Oscar uses. s/cannot make/technically enforce/ see.. http://www.ietf.org/mail-archive/web/dane/current/msg02566.html s/Oscar uses./Oscar presents in TLS handshakes./ > > 3.5. Opportunistic Security > > Alice would like to to publish a web site so that Bob will always > have the benefit of the best security his client is capable of, > without resulting in a negative user experience when using a legacy > browser. For example, suppose that Bob uses two browsers on > different machines, one is a legacy browser that does not support > DANE and cannot be updated, the other is a browser that has full > support for DANE. In this case, the legacy browser should continue > to work as before, while the new browser should be able to discover > DANE support. In general, the DANE mechanism must allow a clients to > determine whether DANE security is available for a site. S3.5 reqs should all be mapped into S4, and S3.5 goes away. see also.. http://www.ietf.org/mail-archive/web/dane/current/msg02566.html > > 3.6. Web Services > > A web service is an HTTP-based Internet protocol designed to support > direct machine-to-machine communication without the intervention of a > human operator or other form of supervisor. Actually, fyi/fwiw, that definition is arguably too narrow in that there are various protocol specs out there denoted as "web services" wherein an explicit user agent speaks SOAP-over-HTTP. > Since web services are > application protocols, the one aspect of Internet architecture that > is essential as far as a Web Service is concerned is that the DNS be > used as the naming system for service discovery. Web Services > typically evolve over time. A service provider must frequently > support legacy clients alongside new and in many cases multiple > versions of each protocol. Discovering the certificates or keys to > be used to secure the connection to the Web service represents merely > one aspect of the more general problem of Web Service property > discovery. This S3.6 doesn't appear to me to state a clear use case, nor necessarily have any import for the WG's work. Drop it? Andrew Sullivan also wondered about this need for this section. http://www.ietf.org/mail-archive/web/dane/current/msg02565.html > 4. Other Requirements > > In addition to supporting the above use cases, the DANE mechanism > must satisfy several lower-level operational and protocol > requirements and goals. > > Multiple Ports: DANE should be able to support multiple services > with different credentials on the same named host, distinguished > by port number. > > No Downgrade: An attacker who can tamper with DNS responses must not > be able to make a DANE-compliant client treat a site that has > deployed DANE and DNSSEC like a site that has deployed neither. > > Encapsulation: If there is a DANE information for the name > alice.example.com, it must only affect services hosted at > alice.example.com. > > Predictability: Client behavior in response to DANE information must > be spelled out in the DANE specification as precisely as possible, > especially for cases where DANE information might conflict with > PKIX information. > > Simple Key Management: DANE should have a mode in which the domain > owner only needs to maintain a single long-lived public/private > key pair. > > Minimal Dependencies: It should be possible for a site to deploy > DANE without also deploying anything else, except DNSSEC. > > Minimal Options: Ideally, DANE should have only one operating mode. > Practically, DANE should have as few operating modes as possible. > > Wild Cards and CNAME: The mechanism for distributing DANE > information should be compatible with the use of DNS wild cards > and CNAME records for setting default properties for domains and > redirecting services. I support Andrew Sullivan's expansion on the latter item. > 5. Acknowledgements > > Thanks to Eric Rescorla for the initial formulation of the use cases, > Zack Weinberg and Phillip Hallam-Baker for contributing other > requirements, and the whole DANE working group for helpful comments > on the mailing list. > > > > > > > Barnes Expires October 31, 2011 [Page 9] > > Internet-Draft DANE Use Cases April 2011 > > > 6. IANA Considerations > > This document makes no request of IANA. > > > 7. Security Considerations > > The primary focus of this document is the enhancement of TLS > authentication procedures using the DNS. The general effect of such > mechanisms is to increase the role of DNS operators in authentication > processes, either in place of or in addition to traditional third- > party actors such as commercial certificate authorities. The > specific security implications of the respective use cases are > discussed in their respective sections above. > > > 8. References > > 8.1. Normative References > > [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", > STD 13, RFC 1034, November 1987. > > [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. > Rose, "DNS Security Introduction and Requirements", > RFC 4033, March 2005. > > [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security > (TLS) Protocol Version 1.2", RFC 5246, August 2008. > > [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., > Housley, R., and W. Polk, "Internet X.509 Public Key > Infrastructure Certificate and Certificate Revocation List > (CRL) Profile", RFC 5280, May 2008. > > 8.2. Informative References > > [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", > RFC 2595, June 1999. > > [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. > > [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over > Transport Layer Security", RFC 3207, February 2002. > > [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, > A., Peterson, J., Sparks, R., Handley, M., and E. > Schooler, "SIP: Session Initiation Protocol", RFC 3261, > > > > Barnes Expires October 31, 2011 [Page 10] > > Internet-Draft DANE Use Cases April 2011 > > > June 2002. > > [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence > Protocol (XMPP): Core", RFC 6120, March 2011. > > [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and > Verification of Domain-Based Application Service Identity > within Internet Public Key Infrastructure Using X.509 > (PKIX) Certificates in the Context of Transport Layer > Security (TLS)", RFC 6125, March 2011. > > > Author's Address > > Richard Barnes > BBN Technologies > 9861 Broken Land Parkway > Columbia, MD 21046 > US > > Phone: +1 410 290 6169 > Email: rbarnes@bbn.com --- end From Jeff.Hodges@KingsMountain.com Fri May 13 09:53:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC995E0822 for ; Fri, 13 May 2011 09:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZrZj6fdNciB for ; Fri, 13 May 2011 09:53:16 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 1159AE073B for ; Fri, 13 May 2011 09:53:13 -0700 (PDT) Received: (qmail 10090 invoked by uid 0); 13 May 2011 16:53:13 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 13 May 2011 16:53:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=bcHd6F/Tj9xo1K6sS2La4fKebXuL6SLK85wADZKnjwXFFgnerIn42ze/7imw9M3Egwnty2y5b6GjdNyZ1yRf+OTajtyEjQ0lfQzn0hXdHRtlL2Y8oBs3du3PcMOPNCe3; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.232]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QKvc1-00081t-H8 for dane@ietf.org; Fri, 13 May 2011 10:53:13 -0600 Message-ID: <4DCD61FA.10103@KingsMountain.com> Date: Fri, 13 May 2011 09:53:14 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 13 May 2011 16:53:17 -0000 Yoav Nir suggested.. > > In section 3.1 we might add what PHB suggested in his CAA proposal - that > CAs check the DNS before signing certificates, so if the DNS says that > Alice's certificate must be signed by "ComSign Secured CA", Charlie won't > sign it. It seems to me that the DANE charter scope does not extend to this requirement. I could be wrong, but that's how it reads to me. Also, Phill's application for issuance of the CAA RRTYPE was approved last month.. http://www.ietf.org/mail-archive/web/dnsext/current/msg11181.html ..and so wrt this cert authority authz functionality, those who have feedback/thought on it, ought to comment in the context of draft-hallambaker-donotissue on the dnsext@ietf.org list. =JeffH From paul.hoffman@vpnc.org Fri May 13 10:43:58 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9583E07E4 for ; Fri, 13 May 2011 10:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFvNdKS4Y5Xd for ; Fri, 13 May 2011 10:43:57 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B924AE073D for ; Fri, 13 May 2011 10:43:56 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4DHhsEA061653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 May 2011 10:43:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4DCD61FA.10103@KingsMountain.com> Date: Fri, 13 May 2011 10:43:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <91F94E2D-114A-467D-8B38-04B341E739B1@vpnc.org> References: <4DCD61FA.10103@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 13 May 2011 17:43:58 -0000 On May 13, 2011, at 9:53 AM, =3DJeffH wrote: > Yoav Nir suggested.. > > > > In section 3.1 we might add what PHB suggested in his CAA proposal - = that > > CAs check the DNS before signing certificates, so if the DNS says = that > > Alice's certificate must be signed by "ComSign Secured CA", Charlie = won't > > sign it. >=20 > It seems to me that the DANE charter scope does not extend to this = requirement. I could be wrong, but that's how it reads to me. >=20 > Also, Phill's application for issuance of the CAA RRTYPE was approved = last month.. >=20 > http://www.ietf.org/mail-archive/web/dnsext/current/msg11181.html >=20 > ..and so wrt this cert authority authz functionality, those who have = feedback/thought on it, ought to comment in the context of = draft-hallambaker-donotissue on the dnsext@ietf.org list. I do not see anything in the charter that prevents this from being a use = case for DANE. The *ability* for CAs to check the DNS and base a = certificate-issuance decision on that is not in or out of scope, and it = seems like it is a use case that can be met with DANE. --Paul Hoffman From christopher.morrow@gmail.com Fri May 13 10:45:33 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F58E07E1 for ; Fri, 13 May 2011 10:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5kqp2wNI+-w for ; Fri, 13 May 2011 10:45:32 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 33D52E0764 for ; Fri, 13 May 2011 10:45:32 -0700 (PDT) Received: by wwa36 with SMTP id 36so2144656wwa.13 for ; Fri, 13 May 2011 10:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Mz7Nm7j1Ot7n3ta0HxyhRhkKaBO6UDD7DOO5RhWzhAg=; b=E0H2DrWWZmLbttZ17AUL6sw8WP0VrJquc6ob67veLoNQd19viy2ZDQw0nQlKPVmFQA NSAj9bvGj5VJfyC4exp4X3TAmvP8skwVT2VgWNiUGMfd0fpkm6YtlUwWeXDtu8zdeHfm m7gUSvkDR7qMm2/ssmVnZQ8oYpr/ZTorNoC0E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=k4bwJK9WBD2yzv7E56coFQe0js1GfSugbYSsq6AoeGMYDJ7iEYiAzADXgkeFSQwXqH B85QqyO5CAFum7srSD2xoqRuaRy5e6B/O3AVbeKyc+vNXgIj1KCLu9TIAiTuNogm7g4K zDNGCW1NF/DKkku5d1FZ8UudXsmjFWzVJ1g58= MIME-Version: 1.0 Received: by 10.216.144.2 with SMTP id m2mr931196wej.114.1305308731224; Fri, 13 May 2011 10:45:31 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.26.141 with HTTP; Fri, 13 May 2011 10:45:31 -0700 (PDT) In-Reply-To: References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <83BE20C5-6392-4581-864E-302941DBF862@kumari.net> Date: Fri, 13 May 2011 13:45:31 -0400 X-Google-Sender-Auth: TwpNTHPMFPtPs95jpwVPhwBAqVI Message-ID: From: Christopher Morrow To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 13 May 2011 17:45:33 -0000 On Wed, May 4, 2011 at 1:55 AM, Christopher Morrow wrote: > On Sat, Apr 30, 2011 at 9:24 PM, Warren Kumari wrote: >> >> On Apr 29, 2011, at 12:03 PM, Warren Kumari wrote: >> >>> Hi all, >>> >>> I think that Richard has integrated most of the comments received on-li= st into this most recent version of the doc and so, as I mentioned, we are = going to kick off WGLC... >>> >>> Please get y'er comments in -- =A0WGLC will be closing on 2011-05-13 at= 16:00UTC (noonish EDT). oops, I forgot to say: "I support the doc, it'd be nice to see a re-spin if some of the more substantive comments need to be included." -chris From Jeff.Hodges@KingsMountain.com Fri May 13 13:41:59 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D011E0804 for ; Fri, 13 May 2011 13:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tqi-FOk8CjvG for ; Fri, 13 May 2011 13:41:58 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 3ECD3E0789 for ; Fri, 13 May 2011 13:41:58 -0700 (PDT) Received: (qmail 29995 invoked by uid 0); 13 May 2011 20:41:57 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 13 May 2011 20:41:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=RUfe2qdwuYonDCCDQcZe1TJjLYEk+BvhoO92wcqmFu2Fns9YJxL2qYQBMDkNubeBUhOVUdZmz6O9eUvFNn8dWP2rKeosg/PZLgR5FvxnCVmaWFYcvdMhZpN2ZtB8w9Y1; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.232]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QKzBN-0006LE-5R for dane@ietf.org; Fri, 13 May 2011 14:41:57 -0600 Message-ID: <4DCD9795.90508@KingsMountain.com> Date: Fri, 13 May 2011 13:41:57 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 13 May 2011 20:41:59 -0000 PaulH replied.. > > On May 13, 2011, at 9:53 AM, =JeffH wrote: > >> Yoav Nir suggested.. >>> >>> In section 3.1 we might add what PHB suggested in his CAA proposal - >>> that CAs check the DNS before signing certificates, so if the DNS says >>> that Alice's certificate must be signed by "ComSign Secured CA", Charlie >>> won't sign it. >> >> It seems to me that the DANE charter scope does not extend to this >> requirement. I could be wrong, but that's how it reads to me. >> >> Also, Phill's application for issuance of the CAA RRTYPE was approved last >> month.. >> >> http://www.ietf.org/mail-archive/web/dnsext/current/msg11181.html >> >> ..and so wrt this cert authority authz functionality, those who have >> feedback/thought on it, ought to comment in the context of >> draft-hallambaker-donotissue on the dnsext@ietf.org list. > > > I do not see anything in the charter that prevents this from being a use > case for DANE. The *ability* for CAs to check the DNS and base a > certificate-issuance decision on that is not in or out of scope, and it > seems like it is a use case that can be met with DANE. Agree that it seems that the cert authority authz use case could be met with DANE. Of course, actually deciding whether it's within or without DANE scope is for the wg chairs and the AD(s) to figure out (yes?) I was more or less trying to give a heads up as well as maintain focus. Whether the CA-pre-cert-issuance-check (to coin a name) use case is in or out of the use case doc isn't a huge matter to me. I thought it might be out of scope due to at least this statement in the present charter.. Initial deliverables for this working group are limited to distribution of bindings between names within the zone operator's control and public keys. More general statements of policy for a domain are out of scope, and new tasks in this area may only be adopted through a re-chartering. However if the WG and chairs desire to add this use case to the doc, that's fine. Of course, one would have to then write a spec similar to draft-hallambaker-donotissue specifying how to accomplish the CA-pre-cert-issuance-check using DANE DNS records. And then there's the two-specs-solving-same-problem thing to either sort out or let dangle. =JeffH From paul.hoffman@vpnc.org Fri May 13 13:55:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2E3E0857 for ; Fri, 13 May 2011 13:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FO6f2-EQUYID for ; Fri, 13 May 2011 13:55:06 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 42A53E07E8 for ; Fri, 13 May 2011 13:55:06 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4DKt4RG069263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 May 2011 13:55:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4DCD9795.90508@KingsMountain.com> Date: Fri, 13 May 2011 13:55:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4047628A-185A-40D4-8BCE-3C71284F7CF2@vpnc.org> References: <4DCD9795.90508@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 13 May 2011 20:55:11 -0000 I'm going to push back a bit, not because I'm hyping one view, but = because I hope folks have clarity about what the document in question is = doing. On May 13, 2011, at 1:41 PM, =3DJeffH wrote: > Of course, actually deciding whether it's within or without DANE scope = is for the wg chairs and the AD(s) to figure out (yes?) Yes, the latter. > I was more or less trying to give a heads up as well as maintain = focus. Whether the CA-pre-cert-issuance-check (to coin a name) use case = is in or out of the use case doc isn't a huge matter to me. Good name. > I thought it might be out of scope due to at least this statement in = the present charter.. >=20 > Initial deliverables for this working group are limited to = distribution > of bindings between names within the zone operator's control and = public > keys. More general statements of policy for a domain are out of = scope, > and new tasks in this area may only be adopted through a = re-chartering. I believe that a *use case* that says "Charlie has agreed to check the = DNS before issuing certificates and would like a way to do that" meets = that paragraph of the charter. If Alice can distribute "bindings between = names within the zone operator's control and public keys" in such a way = that Charlie has something to check in the DNS as part of a = CA-pre-cert-issuance-check, then the first sentence is met. As long as = the use case is not "Alice demands that every CA in the world do what = she says in her DANE record" or "Alice's policy is that her domain must = only be signed by Charlie", I think the second sentence is covered as = well. > Of course, one would have to then write a spec similar to = draft-hallambaker-donotissue specifying how to accomplish the = CA-pre-cert-issuance-check using DANE DNS records. And then there's the = two-specs-solving-same-problem thing to either sort out or let dangle. I disagree. Saying "If Charlie wants to do X, here is a way to fulfill = that desire" is quite different than "If Charlie wants to do X, here is = the only acceptable method." I'm not saying we will actually be able to = meet the use case in the protocol document; I just don't see that it is = impossible so therefore we shouldn't even think of listing the use case. --Paul Hoffman From warren@kumari.net Fri May 13 14:59:28 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DBCE07E0 for ; Fri, 13 May 2011 14:59:28 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcAviV3AVK68 for ; Fri, 13 May 2011 14:59:27 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id D0F1AE07D9 for ; Fri, 13 May 2011 14:59:27 -0700 (PDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id 53C4B1B400EA; Fri, 13 May 2011 17:59:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Fri, 13 May 2011 17:59:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <83BE20C5-6392-4581-864E-302941DBF862@kumari.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 13 May 2011 21:59:28 -0000 Thank you to everyone who provided comments, suggestions and = (especially!) proposed text. WGLC is now closed, and my cochair and I will discuss the comments, etc. = (note to self: Don't end WGLC on a Friday :-P) W On May 13, 2011, at 1:45 PM, Christopher Morrow wrote: > On Wed, May 4, 2011 at 1:55 AM, Christopher Morrow > wrote: >> On Sat, Apr 30, 2011 at 9:24 PM, Warren Kumari = wrote: >>>=20 >>> On Apr 29, 2011, at 12:03 PM, Warren Kumari wrote: >>>=20 >>>> Hi all, >>>>=20 >>>> I think that Richard has integrated most of the comments received = on-list into this most recent version of the doc and so, as I mentioned, = we are going to kick off WGLC... >>>>=20 >>>> Please get y'er comments in -- WGLC will be closing on 2011-05-13 = at 16:00UTC (noonish EDT). >=20 > oops, I forgot to say: "I support the doc, it'd be nice to see a > re-spin if some of the more substantive comments need to be included." > -chris >=20 From paul@xelerance.com Fri May 13 15:28:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B233E08A4 for ; Fri, 13 May 2011 15:28:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qqy1yHEPFlju for ; Fri, 13 May 2011 15:28:29 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA15E0840 for ; Fri, 13 May 2011 15:28:29 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 7807857081; Fri, 13 May 2011 18:28:26 -0400 (EDT) Date: Fri, 13 May 2011 18:28:25 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: <91F94E2D-114A-467D-8B38-04B341E739B1@vpnc.org> Message-ID: References: <4DCD61FA.10103@KingsMountain.com> <91F94E2D-114A-467D-8B38-04B341E739B1@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF DANE WG list Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 13 May 2011 22:28:29 -0000 On Fri, 13 May 2011, Paul Hoffman wrote: >> http://www.ietf.org/mail-archive/web/dnsext/current/msg11181.html >> >> ..and so wrt this cert authority authz functionality, those who have feedback/thought on it, ought to comment in the context of draft-hallambaker-donotissue on the dnsext@ietf.org list. > > > I do not see anything in the charter that prevents this from being a use case for DANE. The *ability* for CAs to check the DNS and base a certificate-issuance decision on that is not in or out of scope, and it seems like it is a use case that can be met with DANE. I agree. Having one record for applications and one record for CAs seem strange. If it does become a dane use case, then like I suggested for the CAA record, there should be a valid "null record" to state that no CA should issue/be trusted. This would be to avoid people using "bogus" data to accomplish the same. So yes, it would be a good use case to add DANE. Paul From chris@eff.org Fri May 13 23:10:12 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A36E06B5 for ; Fri, 13 May 2011 23:10:12 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9kNoFxcnDLX for ; Fri, 13 May 2011 23:10:11 -0700 (PDT) Received: from mail1.eff.org (mail1.eff.org [64.147.188.4]) by ietfa.amsl.com (Postfix) with ESMTP id CBE77E06A1 for ; Fri, 13 May 2011 23:10:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Chris Palmer In-Reply-To: <4DCD5D59.5020609@KingsMountain.com> Date: Sat, 14 May 2011 01:10:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <522C8476-2311-4554-9F81-719FF41B417C@eff.org> References: <4DCD5D59.5020609@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] DNSSEC optionality (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 14 May 2011 06:10:12 -0000 On May 13, 2011, at 11:33 AM, =3DJeffH wrote: > I agree that there doesn't appear to be very much of a justification = for deploying DANE records is one isn't going to do so securely, and = this should be made clear in some fashion. In my view, DANE (or something like it) is the reason for DNSSEC to = exist. And if it's not end-to-end (i.e. if the last mile problem is not = solved), then... --=20 Chris Palmer Technology Director, Electronic Frontier Foundation https://www.eff.org/code From ynir@checkpoint.com Fri May 13 23:11:12 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B2DE06A1 for ; Fri, 13 May 2011 23:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3ElJvSY-nZl for ; Fri, 13 May 2011 23:11:11 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id DDCCAE0681 for ; Fri, 13 May 2011 23:11:10 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p4E6B8O2022374; Sat, 14 May 2011 09:11:09 +0300 X-CheckPoint: {4DCE2A00-2-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 14 May 2011 09:11:08 +0300 From: Yoav Nir To: Paul Wouters Date: Sat, 14 May 2011 09:11:05 +0300 Thread-Topic: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) Thread-Index: AcwR/baLizMBc7CnScaw63Jo8u48jg== Message-ID: References: <4DCD61FA.10103@KingsMountain.com> <91F94E2D-114A-467D-8B38-04B341E739B1@vpnc.org> 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 Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 14 May 2011 06:11:12 -0000 On May 14, 2011, at 1:28 AM, Paul Wouters wrote: > On Fri, 13 May 2011, Paul Hoffman wrote: >=20 >>> http://www.ietf.org/mail-archive/web/dnsext/current/msg11181.html >>>=20 >>> ..and so wrt this cert authority authz functionality, those who have fe= edback/thought on it, ought to comment in the context of draft-hallambaker-= donotissue on the dnsext@ietf.org list. >>=20 >>=20 >> I do not see anything in the charter that prevents this from being a use= case for DANE. The *ability* for CAs to check the DNS and base a certifica= te-issuance decision on that is not in or out of scope, and it seems like i= t is a use case that can be met with DANE. >=20 > I agree. Having one record for applications and one record for CAs seem s= trange. >=20 > If it does become a dane use case, then like I suggested for the CAA reco= rd, there should > be a valid "null record" to state that no CA should issue/be trusted. Thi= s would be to > avoid people using "bogus" data to accomplish the same. If we're using the same record for CAs and applications, what would the nul= l record mean for applications? >=20 > So yes, it would be a good use case to add DANE. >=20 > Paul From pgut001@login01.cs.auckland.ac.nz Fri May 13 23:29:42 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2A2E065D for ; Fri, 13 May 2011 23:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8a71e9toU35 for ; Fri, 13 May 2011 23:29:41 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 626C4E0658 for ; Fri, 13 May 2011 23:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1305354582; x=1336890582; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20chris@eff.org,=20Jeff.Hodges@KingsMountain.com |Subject:=20Re:=20[dane]=20DNSSEC=20optionality=20(was: =20Starting=20WGLC=20on:=20draft-ietf-dane-use-cases-02) |Cc:=20dane@ietf.org|In-Reply-To:=20<522C8476-2311-4554-9 F81-719FF41B417C@eff.org>|Message-Id:=20|Date:=20Sat,=2014=20May=202 011=2018:29:31=20+1200; bh=Kgpq/jiSxBh6MwaQDLDBbacBws3C2EbkeCJy8LufoQY=; b=GrKeghZFU3Xi4kP1oc9VJnHRbkl19ei6K6F0FkkQ/skRPsqvY7+0WI+g wnfHvY+TggZbvCwMk8LhLA4HjjqZZlal+tRjYv7PMN0hMwf/4Sw3xQjEN QlFjo42Q6R5zk5AKQt39nHMzg1z0fsUyiTb/oj9IIentdI9Ar0fP2GS1F I=; X-IronPort-AV: E=Sophos;i="4.64,367,1301832000"; d="scan'208";a="61741268" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 May 2011 18:29:32 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QL8Lz-0000Od-Gt; Sat, 14 May 2011 18:29:31 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QL8Lz-0002hx-6J; Sat, 14 May 2011 18:29:31 +1200 From: Peter Gutmann To: chris@eff.org, Jeff.Hodges@KingsMountain.com In-Reply-To: <522C8476-2311-4554-9F81-719FF41B417C@eff.org> Message-Id: Date: Sat, 14 May 2011 18:29:31 +1200 Cc: dane@ietf.org Subject: Re: [dane] DNSSEC optionality (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 14 May 2011 06:29:42 -0000 Chris Palmer writes: >In my view, DANE (or something like it) is the reason for DNSSEC to exist. Nice. That's like the 21st-century update to "PKI needs electronic commerce in order to function". Peter. From lconroy@insensate.co.uk Sat May 14 07:52:42 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFC5E06F0 for ; Sat, 14 May 2011 07:52:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0w77CX3DJ0EY for ; Sat, 14 May 2011 07:52:40 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 865F4E06E9 for ; Sat, 14 May 2011 07:52:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id C4F4C502863; Sat, 14 May 2011 15:52:36 +0100 (BST) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Px3Qp1WJUqRT; Sat, 14 May 2011 15:52:35 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id C7430502858; Sat, 14 May 2011 15:52:35 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Sat, 14 May 2011 15:52:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <69E9E4BF-C7CF-4200-8EEC-314E2D2A0313@insensate.co.uk> References: To: Peter Gutmann X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] DNSSEC optionality (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 14 May 2011 14:52:42 -0000 Hi Peter, There's enough confusion already -- That is exactly the opposite of = what I understood Chris to say. To re-phrase, "Electronic commerce (or something like it)^^ is the = reason for PKI to exist." ^^ IETF people are plumbers, so the nearest we get to apps is the = protocols those apps can use (and use case docs). all the best, Lawrence On 14 May 2011, at 07:29, Peter Gutmann wrote: > Chris Palmer writes: >=20 >> In my view, DANE (or something like it) is the reason for DNSSEC to = exist. >=20 > Nice. That's like the 21st-century update to "PKI needs electronic = commerce=20 > in order to function". >=20 > Peter. From pgut001@login01.cs.auckland.ac.nz Sat May 14 14:58:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E9DE06FD for ; Sat, 14 May 2011 14:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDF4IjTJuF41 for ; Sat, 14 May 2011 14:58:57 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id CFC3EE06B9 for ; Sat, 14 May 2011 14:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1305410337; x=1336946337; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20lconroy@insensate.co.uk,=20pgut001@cs.auckland.ac. nz|Subject:=20Re:=20[dane]=20DNSSEC=20optionality=20(was: =20Starting=20WGLC=20on:=20draft-ietf-dane-use-cases-02) |Cc:=20chris@eff.org,=20dane@ietf.org,=20Jeff.Hodges@King sMountain.com|In-Reply-To:=20<69E9E4BF-C7CF-4200-8EEC-314 E2D2A0313@insensate.co.uk>|Message-Id:=20|Date:=20Sun,=2015=20May=20 2011=2009:58:52=20+1200; bh=u9U9pRAUxoHMSUisnBHbKdy0yXcq6BA0vFE8BJyiMMg=; b=Qfl0h8ue3y3TFznWjzFpXs0vkAFdb1oijBTm/arW0Um08p+Dh5sz6Cka 1P9m28iYfeMVm8ONBOtd70IVahlH6JGMsMtCbakKuy+RllAVhA29Q8/Ob 9vDJMSOyfA0hUu2MPyAeGfeGvQlbRdkLWAR8jL+hkJFhsrHPKqiUcHTOR Y=; X-IronPort-AV: E=Sophos;i="4.64,368,1301832000"; d="scan'208";a="61783556" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 15 May 2011 09:58:53 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QLMrM-0008UN-JC; Sun, 15 May 2011 09:58:52 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QLMrM-0004l1-T8; Sun, 15 May 2011 09:58:52 +1200 From: Peter Gutmann To: lconroy@insensate.co.uk, pgut001@cs.auckland.ac.nz In-Reply-To: <69E9E4BF-C7CF-4200-8EEC-314E2D2A0313@insensate.co.uk> Message-Id: Date: Sun, 15 May 2011 09:58:52 +1200 Cc: dane@ietf.org Subject: Re: [dane] DNSSEC optionality (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 14 May 2011 21:58:58 -0000 Lawrence Conroy writes: >To re-phrase, "Electronic commerce (or something like it)^^ is the reason >for PKI to exist." I think we're saying the same thing... what I was pointing out was that throughout the 1990s we were told: "e-commerce needs PKI in order to function" Someone (I think it was Carl Ellison) then pointed out that it was really: "PKI needs e-commerce in order to function" Chris' comment seemed to be a similar reversal for DNSSEC and DANE, instead of it being "DNSSEC drives DANE" it was "DANE drives DNSSEC" (DANE works just as well without DNSSEC, in the same way that e-commerce works just as well without PKI). Peter. From rbarnes@bbn.com Mon May 16 06:46:23 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC98E06B0 for ; Mon, 16 May 2011 06:46:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63servZ3B1wi for ; Mon, 16 May 2011 06:46:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C351EE0699 for ; Mon, 16 May 2011 06:46:22 -0700 (PDT) Received: from [128.89.254.251] (port=50568 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QLy7p-0003wi-Nm; Mon, 16 May 2011 09:46:21 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4DCD5D6A.7080203@KingsMountain.com> Date: Mon, 16 May 2011 09:46:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DCD5D6A.7080203@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1082) Cc: IETF DANE WG list Subject: Re: [dane] simultaneous use cases (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 16 May 2011 13:46:23 -0000 > > Is there a use case where Alice wants to do multiple of these = operations at > > the same time. That is she wants to do both a CA constraint and a > > Certificate constraint simultaneously? >=20 > this is a good question. Possibly. >=20 > Others have thoughts? I had been imagining that these use cases would be "combinable". The = most obvious case that had occurred to me was where you would want to = assert your own CA (3.3) and lock to that CA (3.1). Do we need extra text to clarify this? Maybe in the intro to Section 3? --Richard= From rbarnes@bbn.com Mon May 16 06:52:07 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F2CE06B0 for ; Mon, 16 May 2011 06:52:07 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ap1Xh8RePXaq for ; Mon, 16 May 2011 06:52:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id CB9ECE067E for ; Mon, 16 May 2011 06:52:06 -0700 (PDT) Received: from [128.89.254.251] (port=50574 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QLyDM-00041O-3n; Mon, 16 May 2011 09:52:04 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 16 May 2011 09:52:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5AAEBE3A-BF57-4DE4-AEC0-B8867CC2C593@bbn.com> References: <4DCD61FA.10103@KingsMountain.com> <91F94E2D-114A-467D-8B38-04B341E739B1@vpnc.org> To: Yoav Nir X-Mailer: Apple Mail (2.1082) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 16 May 2011 13:52:07 -0000 >> If it does become a dane use case, then like I suggested for the CAA = record, there should >> be a valid "null record" to state that no CA should issue/be trusted. = This would be to >> avoid people using "bogus" data to accomplish the same. >=20 > If we're using the same record for CAs and applications, what would = the null record mean for applications? I think the better solution would be to just make up a cert/CA and lock = to that cert/CA, preventing any other cert/CA from validating. There's = not a need for a null record, just positive record pointing to something = else. --Richard= From Jeff.Hodges@KingsMountain.com Mon May 16 09:21:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A64E06CE for ; Mon, 16 May 2011 09:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQx7jt0ozvAN for ; Mon, 16 May 2011 09:21:51 -0700 (PDT) Received: from oproxy4-pub.bluehost.com (oproxy4-pub.bluehost.com [69.89.21.11]) by ietfa.amsl.com (Postfix) with SMTP id 64732E06C2 for ; Mon, 16 May 2011 09:21:51 -0700 (PDT) Received: (qmail 16346 invoked by uid 0); 16 May 2011 16:21:51 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 16 May 2011 16:21:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=6zAXvQgiC8q9AiAsPMmtJkwrWtPxmK/b1qMjc6/ke5m0B8j27ZZ5Fx9yPs87YNULrm+ER8eKsZJgOi2ni5UjqOmkN98yeu42pEwYwMLEoBpBx8gPDpH7lmKcavNY0tes; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.110]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QM0YI-0000h0-HE for dane@ietf.org; Mon, 16 May 2011 10:21:50 -0600 Message-ID: <4DD14F1D.9040707@KingsMountain.com> Date: Mon, 16 May 2011 09:21:49 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 16 May 2011 16:21:52 -0000 Paul Hoffman replied on Fri, 13 May 2011 13:55:04 -0700: > > I'd mused.. > >> Of course, one would have to then write a spec similar to >> draft-hallambaker-donotissue specifying how to accomplish the >> CA-pre-cert-issuance-check using DANE DNS records. And then there's the >> two-specs-solving-same-problem thing to either sort out or let dangle. > > I disagree. Saying "If Charlie wants to do X, here is a way to fulfill that > desire" is quite different than "If Charlie wants to do X, here is the only > acceptable method." I'm not saying we will actually be able to meet the use > case in the protocol document; I just don't see that it is impossible so > therefore we shouldn't even think of listing the use case. Sorry, to clarify, all I'd meant by that musing was that if one desires to actually explicitly address the CA-pre-cert-issuance-check use case in the DANE WG context, then one would need to explicitly spec it out (whether in the present DANE protocol spec, or in a separate spec), and then if so, we (the greater IETF community et al) have the two-specs-solving-same-problem thing (given that it looks like CAA will get a RRTYPE issued) to either sort out or let dangle. =JeffH From hallam@gmail.com Mon May 16 09:43:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D751BE06B0 for ; Mon, 16 May 2011 09:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ou10krrYLqgk for ; Mon, 16 May 2011 09:43:12 -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 6B1A4E06BB for ; Mon, 16 May 2011 09:43:12 -0700 (PDT) Received: by gxk19 with SMTP id 19so2007964gxk.31 for ; Mon, 16 May 2011 09:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UDdAy83WPkz874KqkJSq+8UrP/uSXyC0Wbn24igSseQ=; b=Is28MN8NdJ6XENTLxGIFFU5DfU/K1+6FKdwz04otiB5QASAihpWiApjAPvtptomvKe d87Cb69/+mwxLGmKgoIHD/pCFZRQvI9NkcScG9bDtpvt6jioXH2ip9RMRoJs4qRgQlCW Ab4PP4H3qw1LmiJWn+sBZnmlWATlXD4nJndFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WGPrPSmVv/hE76siAsZOFy2xhxfWrcgWUBTCwADAD+EG2Y0Qqse2ha835MQzbWO+Di NsJuRaBIg4JwXyZnclub1hDA1eg+tMfCHFPY1rp7iO5DkhvGrOo1GlE/8rYXRcTxu6c5 6mNWby2wJy9LjzdYMIJ6yflcXG0+Q2sroG80A= MIME-Version: 1.0 Received: by 10.150.2.21 with SMTP id 21mr3312051ybb.354.1305564191461; Mon, 16 May 2011 09:43:11 -0700 (PDT) Received: by 10.100.57.3 with HTTP; Mon, 16 May 2011 09:43:11 -0700 (PDT) In-Reply-To: <5AAEBE3A-BF57-4DE4-AEC0-B8867CC2C593@bbn.com> References: <4DCD61FA.10103@KingsMountain.com> <91F94E2D-114A-467D-8B38-04B341E739B1@vpnc.org> <5AAEBE3A-BF57-4DE4-AEC0-B8867CC2C593@bbn.com> Date: Mon, 16 May 2011 12:43:11 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=000e0cd4d87add130504a367598e Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 16 May 2011 16:43:14 -0000 --000e0cd4d87add130504a367598e Content-Type: text/plain; charset=ISO-8859-1 Actually, this was one of the two use cases for which the policy OID mechanism was originally proposed. 'Never issue' and 'only issue EV' being two cases we could not support using the path directive. I would prefer to have this be an OID specified on the IETF or CABForum OID arc. That is what they are for. Since the EV oid has to be CABForum, they might as well do the null OID. Alternatively, I could just add a 'null' directive and make it simpler still: example.com CAA 1 null The question there would become, why would you want to use such a directive? Wouldn't not wanting a certificate be a consequence of not wanting the domain to be used in any context whatsoever? So maybe there should be some use of flags to say 'don't issue, don't rely, don't contact any service at' On Mon, May 16, 2011 at 9:52 AM, Richard L. Barnes wrote: > >> If it does become a dane use case, then like I suggested for the CAA > record, there should > >> be a valid "null record" to state that no CA should issue/be trusted. > This would be to > >> avoid people using "bogus" data to accomplish the same. > > > > If we're using the same record for CAs and applications, what would the > null record mean for applications? > > I think the better solution would be to just make up a cert/CA and lock to > that cert/CA, preventing any other cert/CA from validating. There's not a > need for a null record, just positive record pointing to something else. > > --Richard > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --000e0cd4d87add130504a367598e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Actually, this was one of the two use cases for which the policy OID mechan= ism was originally proposed. 'Never issue' and 'only issue EV&#= 39; being two cases we could not support using the path directive.

I would prefer to have this be an OID specified on the IETF or C= ABForum OID arc. That is what they are for. Since the EV oid has to be CABF= orum, they might as well do the null OID.

Alternat= ively, I could just add a 'null' directive and make it simpler stil= l:


example.c= om =A0CAA 1 null

The question there would beco= me, why would you want to use such a directive? Wouldn't not wanting a = certificate be a consequence of not wanting the domain to be used in any co= ntext whatsoever? So maybe there should be some use of flags to say 'do= n't issue, don't rely, don't contact any service at'




On Mon, May 16, 2011 at 9:52 AM, Richard L. Barnes = <rbarnes@bbn.com> wrote= :
>> If it does becom= e a dane use case, then like I suggested for the CAA record, there should >> be a valid "null record" to state that no CA should issu= e/be trusted. This would be to
>> avoid people using "bogus" data to accomplish the same.<= br> >
> If we're using the same record for CAs and applications, what woul= d the null record mean for applications?

I think the better solution would be to just make up a cert/CA and lo= ck to that cert/CA, preventing any other cert/CA from validating. =A0There&= #39;s not a need for a null record, just positive record pointing to someth= ing else.

--Richard
__________________________________= _____________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
Website: http://hallambaker.com/

--000e0cd4d87add130504a367598e-- From paul@xelerance.com Mon May 16 12:47:08 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D75E07AA for ; Mon, 16 May 2011 12:47:08 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeHk44G8kukL for ; Mon, 16 May 2011 12:47:08 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF35E07A7 for ; Mon, 16 May 2011 12:47:08 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 91C725709E; Mon, 16 May 2011 15:47:04 -0400 (EDT) Date: Mon, 16 May 2011 15:47:01 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4DCD61FA.10103@KingsMountain.com> <91F94E2D-114A-467D-8B38-04B341E739B1@vpnc.org> <5AAEBE3A-BF57-4DE4-AEC0-B8867CC2C593@bbn.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 16 May 2011 19:47:08 -0000 On Mon, 16 May 2011, Phillip Hallam-Baker wrote: > Alternatively, I could just add a 'null' directive and make it simpler still: > > example.com  CAA 1 null > > The question there would become, why would you want to use such a directive? If someone is using DANE with a non-cert entity (raw key) and does not want legacy clients to be fooled into using a CA for which they have a trust anchor loaded on the client. Though dane currently has no such format, work is (slowly) progressing to add it. Paul From ietf@augustcellars.com Mon May 16 13:34:33 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC2CE07D2 for ; Mon, 16 May 2011 13:34:33 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3TJy9NdM4+J for ; Mon, 16 May 2011 13:34:32 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 90DCBE06E2 for ; Mon, 16 May 2011 13:34:32 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id 3D9776A44D; Mon, 16 May 2011 13:34:31 -0700 (PDT) From: "Jim Schaad" To: "'Richard L. Barnes'" , "'=JeffH'" References: <4DCD5D6A.7080203@KingsMountain.com> In-Reply-To: Date: Mon, 16 May 2011 14:02:19 -0700 Message-ID: <004901cc140c$8d250b40$a76f21c0$@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: AQH9ffobx65Zfj6YzAiz83g5Um5OMAGA92/clCEVCuA= Content-Language: en-us Cc: 'IETF DANE WG list' Subject: Re: [dane] simultaneous use cases (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 16 May 2011 20:34:33 -0000 I think that it might require some extra text. There are two cases and they need to be distinguished. The first is the combinable case and the second is the rollover case. If you want to roll over from specifying the EE cert to specifying a CA cert this is different than saying that both are to be enforced. At a minimum one needs to say that a combinable case exists. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Richard L. Barnes > Sent: Monday, May 16, 2011 6:46 AM > To: =JeffH > Cc: IETF DANE WG list > Subject: Re: [dane] simultaneous use cases (was: Starting WGLC on: draft- > ietf-dane-use-cases-02) > > > > Is there a use case where Alice wants to do multiple of these > > > operations at the same time. That is she wants to do both a CA > > > constraint and a Certificate constraint simultaneously? > > > > this is a good question. Possibly. > > > > Others have thoughts? > > I had been imagining that these use cases would be "combinable". The most > obvious case that had occurred to me was where you would want to assert > your own CA (3.3) and lock to that CA (3.1). > > Do we need extra text to clarify this? Maybe in the intro to Section 3? > > --Richard > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From hallam@gmail.com Mon May 16 15:25:36 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB29E0681 for ; Mon, 16 May 2011 15:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZQMYjqZz2WQ for ; Mon, 16 May 2011 15:25:34 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD01E0651 for ; Mon, 16 May 2011 15:25:34 -0700 (PDT) Received: by vxg33 with SMTP id 33so4176011vxg.31 for ; Mon, 16 May 2011 15:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=t2YpDSn+KfTkvNihCSwxCV3rP0DY5BleOwOB5oZ661E=; b=vkTCaOtp8NQ49iiEFmYu6vjP07tnMgdM8VKCzMVsfj+PF7ASKcPACBwP/ckS/UaNql ao9cwM3DLTephJP0SO1kE/rYcsPOA4f62GQZWEb5dbJPgaGhiRxY3z60nF8FPw+5Dk1+ mRBIHVVfRMIdZGfJdkjrGMyHiVj5F8IilGHng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=De4cc9WqtXTRLm/IHBC55hzEdA4BxLAhIa0eWzSX4jDb6ZewifIHZLf9JecoL3vewT vFK4jqA3QHbDSPkaNvnfjS0qjrDgBeiGjkitmxeWuTNbzXV3YP83xUfP+/1Lzr0mzNhT lIsfSDMgMxcKpdWX3cEE1B1mL8MY0Wm9+TCmg= MIME-Version: 1.0 Received: by 10.52.97.197 with SMTP id ec5mr868121vdb.112.1305584733753; Mon, 16 May 2011 15:25:33 -0700 (PDT) Received: by 10.52.113.106 with HTTP; Mon, 16 May 2011 15:25:33 -0700 (PDT) In-Reply-To: References: <4DCD61FA.10103@KingsMountain.com> <91F94E2D-114A-467D-8B38-04B341E739B1@vpnc.org> <5AAEBE3A-BF57-4DE4-AEC0-B8867CC2C593@bbn.com> Date: Mon, 16 May 2011 18:25:33 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=20cf307f390847900e04a36c2270 Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 16 May 2011 22:25:36 -0000 --20cf307f390847900e04a36c2270 Content-Type: text/plain; charset=ISO-8859-1 No, for that use case you would be publishing your own root. The possible use cases for null would be either for a domain that wants to accept connects but does not want to ever use security or for a domain that is parked without any intention of being used at all. Is the first use case one that would be desirable to support at all? On Mon, May 16, 2011 at 3:47 PM, Paul Wouters wrote: > On Mon, 16 May 2011, Phillip Hallam-Baker wrote: > > Alternatively, I could just add a 'null' directive and make it simpler >> still: >> >> example.com CAA 1 null >> >> The question there would become, why would you want to use such a >> directive? >> > > If someone is using DANE with a non-cert entity (raw key) and does not want > legacy > clients to be fooled into using a CA for which they have a trust anchor > loaded on > the client. > > Though dane currently has no such format, work is (slowly) progressing to > add it. > > Paul > -- Website: http://hallambaker.com/ --20cf307f390847900e04a36c2270 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No, for that use case you would be publishing your own root.

=
The possible use cases for null would be either for a domain that want= s to accept connects but does not want to ever use security or for a domain= that is parked without any intention of being used at all.

Is the first use case one that would be desirable to su= pport at all?


On Mon, May 16, = 2011 at 3:47 PM, Paul Wouters <paul@xelerance.com> wrote:
On Mon, 16 May 2011, Phil= lip Hallam-Baker wrote:

Alternatively, I could just add a 'null' directive and make it simp= ler still:

example.com =A0CAA 1 n= ull

The question there would become, why would you want to use such a directive= ?

If someone is using DANE with a non-cert entity (raw key) and does not want= legacy
clients to be fooled into using a CA for which they have a trust anchor loa= ded on
the client.

Though dane currently has no such format, work is (slowly) progressing to a= dd it.

Paul



--
Website: http://hallambaker.com/

--20cf307f390847900e04a36c2270-- From paul.hoffman@vpnc.org Mon May 16 20:01:36 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2798E0711 for ; Mon, 16 May 2011 20:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lU1-pghCk0SR for ; Mon, 16 May 2011 20:01:33 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E5E51E06B5 for ; Mon, 16 May 2011 20:01:32 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4H31MNd054315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 May 2011 20:01:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 16 May 2011 20:01:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DCD61FA.10103@KingsMountain.com> <91F94E2D-114A-467D-8B38-04B341E739B1@vpnc.org> <5AAEBE3A-BF57-4DE4-AEC0-B8867CC2C593@bbn.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 17 May 2011 03:01:36 -0000 On May 16, 2011, at 9:43 AM, Phillip Hallam-Baker wrote: > Actually, this was one of the two use cases for which the policy OID = mechanism was originally proposed. 'Never issue' and 'only issue EV' = being two cases we could not support using the path directive. >=20 > I would prefer to have this be an OID specified on the IETF or = CABForum OID arc. That is what they are for. Since the EV oid has to be = CABForum, they might as well do the null OID. >=20 > Alternatively, I could just add a 'null' directive and make it simpler = still: >=20 >=20 > example.com CAA 1 null >=20 > The question there would become, why would you want to use such a = directive? Wouldn't not wanting a certificate be a consequence of not = wanting the domain to be used in any context whatsoever? So maybe there = should be some use of flags to say 'don't issue, don't rely, don't = contact any service at' Just to be clear about my earlier message: I was talking about use cases = and the protocol for DANE, not for CAA. CAA is being developed outside = the IETF and is, of course, free to add or not add whatever use cases it = wants. The thread here is whether we can add such use cases for DANE; I = still think the answer is "yes". --Paul Hoffman From hallam@gmail.com Mon May 16 21:00:51 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1518CE07A1 for ; Mon, 16 May 2011 21:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmCayQMyBqWf for ; Mon, 16 May 2011 21:00:49 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 83EFCE079F for ; Mon, 16 May 2011 21:00:49 -0700 (PDT) Received: by yxk30 with SMTP id 30so44304yxk.31 for ; Mon, 16 May 2011 21:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xJGvcD7cZJTWgxNhsfqHCCajFft3OKFHrzZZC3SExjw=; b=rf0+M4NlDryJeI0bhLaestf/bWlnerWpWi4hV7+1XlwxXt1tuPFwYPnHjQcA2qh6kd whSgt7AkFFp/yr0y2Nz09G81ROCngfIXlS/zkfZwjL4v57jevnIZfry3SewZ0Z+kDYUN j8ku6PMUoGVUcLTzcc4y/Or5ONFTxTTGcDSkg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WQG/0ftUHqF2T8xigLGw1tCaGgtXDcrMI2pJP/h6bzWkWfF8ms44Jm5RGm8tA2m211 sUmDGtkuKf7MrXkw2YoxFodVJirXJgB88TP8mx8VRaEJl8CBfjoVm44c503xoBPuoEjd uOT3e4YkTwTix/t168evvCkEDlME56cy8lM9E= MIME-Version: 1.0 Received: by 10.101.189.22 with SMTP id r22mr74896anp.84.1305604848852; Mon, 16 May 2011 21:00:48 -0700 (PDT) Received: by 10.101.36.13 with HTTP; Mon, 16 May 2011 21:00:48 -0700 (PDT) In-Reply-To: References: <4DCD61FA.10103@KingsMountain.com> <91F94E2D-114A-467D-8B38-04B341E739B1@vpnc.org> <5AAEBE3A-BF57-4DE4-AEC0-B8867CC2C593@bbn.com> Date: Tue, 17 May 2011 00:00:48 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=001636c92adf3b9f9304a370d1dc Cc: IETF DANE WG list Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 17 May 2011 04:00:51 -0000 --001636c92adf3b9f9304a370d1dc Content-Type: text/plain; charset=ISO-8859-1 You are incorrect. Please do not make unfounded claims here. On Mon, May 16, 2011 at 11:01 PM, Paul Hoffman wrote: > > On May 16, 2011, at 9:43 AM, Phillip Hallam-Baker wrote: > > > Actually, this was one of the two use cases for which the policy OID > mechanism was originally proposed. 'Never issue' and 'only issue EV' being > two cases we could not support using the path directive. > > > > I would prefer to have this be an OID specified on the IETF or CABForum > OID arc. That is what they are for. Since the EV oid has to be CABForum, > they might as well do the null OID. > > > > Alternatively, I could just add a 'null' directive and make it simpler > still: > > > > > > example.com CAA 1 null > > > > The question there would become, why would you want to use such a > directive? Wouldn't not wanting a certificate be a consequence of not > wanting the domain to be used in any context whatsoever? So maybe there > should be some use of flags to say 'don't issue, don't rely, don't contact > any service at' > > Just to be clear about my earlier message: I was talking about use cases > and the protocol for DANE, not for CAA. CAA is being developed outside the > IETF and is, of course, free to add or not add whatever use cases it wants. > The thread here is whether we can add such use cases for DANE; I still think > the answer is "yes". > > --Paul Hoffman > > -- Website: http://hallambaker.com/ --001636c92adf3b9f9304a370d1dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You are incorrect.

Please do not make unfounded clai= ms here.=A0



On = Mon, May 16, 2011 at 11:01 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrot= e:

On May 16, 2011, at 9:43 AM, Phillip Hallam-Baker wrote:

> Actually, this was one of the two use cases for which the policy OID m= echanism was originally proposed. 'Never issue' and 'only issue= EV' being two cases we could not support using the path directive.
>
> I would prefer to have this be an OID specified on the IETF or CABForu= m OID arc. That is what they are for. Since the EV oid has to be CABForum, = they might as well do the null OID.
>
> Alternatively, I could just add a 'null' directive and make it= simpler still:
>
>
> example.com =A0CA= A 1 null
>
> The question there would become, why would you want to use such a dire= ctive? Wouldn't not wanting a certificate be a consequence of not wanti= ng the domain to be used in any context whatsoever? So maybe there should b= e some use of flags to say 'don't issue, don't rely, don't = contact any service at'

Just to be clear about my earlier message: I was talking about use ca= ses and the protocol for DANE, not for CAA. CAA is being developed outside = the IETF and is, of course, free to add or not add whatever use cases it wa= nts. The thread here is whether we can add such use cases for DANE; I still= think the answer is "yes".

--Paul Hoffman




--
Website: http://hallambaker.com/

--001636c92adf3b9f9304a370d1dc-- From paul.hoffman@vpnc.org Mon May 16 21:22:50 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA51CE07C5 for ; Mon, 16 May 2011 21:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lckRUSJDT31l for ; Mon, 16 May 2011 21:22:50 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D701BE07A7 for ; Mon, 16 May 2011 21:22:49 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4H4MkpQ056651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 May 2011 21:22:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 16 May 2011 21:22:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DCD61FA.10103@KingsMountain.com> <91F94E2D-114A-467D-8B38-04B341E739B1@vpnc.org> <5AAEBE3A-BF57-4DE4-AEC0-B8867CC2C593@bbn.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 17 May 2011 04:22:51 -0000 On May 16, 2011, at 9:00 PM, Phillip Hallam-Baker wrote: > You are incorrect. For the benefit of the WG, after I sent the last message, I saw that = Phill had proposed that CAA become a work item in the PKIX WG. I = apologized to him offline for sending my mail to the DANE WG before = reading all of the mail for each WG I follow. Be that as it may, my statement is still correct: CAA is not being = worked on in the IETF. It might be in the future, such as if the PKIX WG = adopts it as a work item. In such a case, the DANE WG should probably = coordinate with that work. If CAA doesn't get adopted in an IETF WG, the = DANE WG should still consider it if we do anything that might overlap = with it, even if CAA is just an experimental protocol. --Paul Hoffman From hallam@gmail.com Tue May 17 06:03:53 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1259EE071A for ; Tue, 17 May 2011 06:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFkMPsN3MPqn for ; Tue, 17 May 2011 06:03:52 -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 CDDB5E06B8 for ; Tue, 17 May 2011 06:03:51 -0700 (PDT) Received: by gxk19 with SMTP id 19so170608gxk.31 for ; Tue, 17 May 2011 06:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jC6MN+SWOIVKLkpd+mxSsNpe+GvJNFr/W0BstqS1fyM=; b=t+/DAql4psLhdirTcwCzkDzjaYmXyQy+Q4EIgX9ofRWUcR3sDcIhSDTDwiuqhJXDQV qdZiA+CI14H4rFVSWVC/mWIV8gh0jIVxwvVn/LRV/0tf99UslbbmCoOr+zGqGGAEDSjf xPaX1tYvMQEUqfxfPvWEHpuGngEvPMwebyNvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jzRkgvy7YyP9Nx3mAGMIDzGu0hmUuxF0pbjqgvom8210SJqvo8d5c04ZdvnjkkJumB MgFbGGoNKF08X4QoSrmC0uTEF0/SYYCHJuGw6Wb82W2WHzO+kVFA1xuq5GRcOouFPWjq g62uej4XZ2lB/q13UifRJIWeZifp1iZsWVXcs= MIME-Version: 1.0 Received: by 10.100.249.3 with SMTP id w3mr301416anh.40.1305637431071; Tue, 17 May 2011 06:03:51 -0700 (PDT) Received: by 10.101.36.13 with HTTP; Tue, 17 May 2011 06:03:51 -0700 (PDT) In-Reply-To: References: <4DCD61FA.10103@KingsMountain.com> <91F94E2D-114A-467D-8B38-04B341E739B1@vpnc.org> <5AAEBE3A-BF57-4DE4-AEC0-B8867CC2C593@bbn.com> Date: Tue, 17 May 2011 09:03:51 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016369fa25248d57e04a3786768 Cc: IETF DANE WG list Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 17 May 2011 13:03:53 -0000 --0016369fa25248d57e04a3786768 Content-Type: text/plain; charset=ISO-8859-1 I only noticed Paul's offlist comment after I posted my reply. But he is still wrong. Unless we have Note Well completely wrong (and need to fix it urgently) all Internet Drafts are 'In IETF Process'. Drafts can and do become RFCs without going through a Working Group. Drafts can even become standards without a WG being formed. The plan with CAA was always to make it a standards track proposal. The reason it was proposed in the way it was is that at a minimum it has to interface with PKIX and DNSEXT in IETF and CABForum outside IETF. In addition the proposal has implications for TLS, HTTP possibly IPSEC and of course DANE. When dealing with that type of situation I want to minimize the number of interfaces before proceeding. So it was designed to anticipate input from PKIX (i.e. use OIDs) and HTTP (i.e. make it congruent with a tagged header approach) and proposed in a form that allowed discussion of the DNS interface in the hope of getting that out of the way first. Although the concept for CAA was only developed late last year, I have been working on various 'properties in DNS' proposals for two years now. So CAA is presented in an extension framework that is designed to support more that just authorization records. The ultimate goal is to support a socket API of the following form TCPSocket Socket = new TCPSocket ("example.com", "_http._tcp") Which would automatically return the 'best' connection for HTTP that is offered by example.com. The reason for wanting to support such an interface is that it is really difficult to support callbacks or delegates in a scripting language and security policy attributes are probably not things that should be defined at the application level anyway. One consequence of this objective is that I have been looking at libraries for DNS interfaces in the major programming languages and we have a serious problem. None of the major platforms currently in use has a real DNS API in the standard libraries. >From here I can see three possible outcomes 1) Do nothing, let two separate properties in DNS mechanisms develop, one of which is almost certain to wither on the vine. 2) Design DANE to support general purpose 'connection properties in DNS' and rewrite CAA to express the policy and path properties in whatever framework/record DANE develops. 3) Design DANE as an extension of the CAA approach (see GSRV/ESRV for how this could work). On Tue, May 17, 2011 at 12:22 AM, Paul Hoffman wrote: > On May 16, 2011, at 9:00 PM, Phillip Hallam-Baker wrote: > > > You are incorrect. > > For the benefit of the WG, after I sent the last message, I saw that Phill > had proposed that CAA become a work item in the PKIX WG. I apologized to him > offline for sending my mail to the DANE WG before reading all of the mail > for each WG I follow. > > Be that as it may, my statement is still correct: CAA is not being worked > on in the IETF. It might be in the future, such as if the PKIX WG adopts it > as a work item. In such a case, the DANE WG should probably coordinate with > that work. If CAA doesn't get adopted in an IETF WG, the DANE WG should > still consider it if we do anything that might overlap with it, even if CAA > is just an experimental protocol. > > --Paul Hoffman > > -- Website: http://hallambaker.com/ --0016369fa25248d57e04a3786768 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I only noticed Paul's offlist comment after I posted my reply.

=
But he is still wrong. Unless we have Note Well completely wrong= (and need to fix it urgently) all Internet Drafts are 'In IETF Process= '. Drafts can and do become RFCs without going through a Working Group.= Drafts can even become standards without a WG being formed.

The plan with CAA was always to make it a standards tra= ck proposal. The reason it was proposed in the way it was is that at a mini= mum it has to interface with PKIX and DNSEXT in IETF and CABForum outside I= ETF. In addition the proposal has implications for TLS, HTTP possibly IPSEC= and of course DANE.

When dealing with that type of situation I want to mini= mize the number of interfaces before proceeding. So it was designed to anti= cipate input from PKIX (i.e. use OIDs) and HTTP (i.e. make it congruent wit= h a tagged header approach) and proposed in a form that allowed discussion = of the DNS interface in the hope of getting that out of the way first.


Although the concept for CAA was only de= veloped late last year, I have been working on various 'properties in D= NS' proposals for two years now. So CAA is presented in an extension fr= amework that is designed to support more that just authorization records.

The ultimate goal is to support a socket API of the fol= lowing form

TCPSocket Socket =3D new=A0TCPSocket ("example.com", "_http._tcp")


The reason for wanting to support such an= interface is that it is really difficult to support callbacks or delegates= in a scripting language and security policy attributes are probably not th= ings that should be defined at the application level anyway.

One consequence of this objective is that I have been l= ooking at libraries for DNS interfaces in the major programming languages a= nd we have a serious problem. None of the major platforms currently in use = has a real DNS API in the standard libraries.=A0


From here I can see three possible outcomes

1) Do nothing, let two separate properties in DNS me= chanisms develop, one of which is almost certain to wither on the vine.

2) Design DANE to support general purpose 'connecti= on properties in DNS' and rewrite CAA to express the policy and path pr= operties in whatever framework/record DANE develops.

3) Design DANE as an extension of the CAA approach (see GSRV/ESRV for = how this could work).



On Tue, May 17, 2011 at 12:22 AM, Paul Hoffman <paul.hoffman@vpnc.org= > wrote:
On May 16, 2011, at 9:00 PM, Phillip Hallam= -Baker wrote:

> You are incorrect.

For the benefit of the WG, after I sent the last message, I saw that Phill = had proposed that CAA become a work item in the PKIX WG. I apologized to hi= m offline for sending my mail to the DANE WG before reading all of the mail= for each WG I follow.

Be that as it may, my statement is still correct: CAA is not being worked o= n in the IETF. It might be in the future, such as if the PKIX WG adopts it = as a work item. In such a case, the DANE WG should probably coordinate with= that work. If CAA doesn't get adopted in an IETF WG, the DANE WG shoul= d still consider it if we do anything that might overlap with it, even if C= AA is just an experimental protocol.

--Paul Hoffman




--
Website: http://hallambaker.com/

--0016369fa25248d57e04a3786768-- From ynir@checkpoint.com Tue May 17 06:12:37 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA3DE073E for ; Tue, 17 May 2011 06:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mM-hEa+jl7ud for ; Tue, 17 May 2011 06:12:36 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 79981E06C5 for ; Tue, 17 May 2011 06:12:36 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p4HDCLML027632; Tue, 17 May 2011 16:12:30 +0300 X-CheckPoint: {4DD28127-1-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 17 May 2011 16:12:23 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 17 May 2011 16:12:22 +0300 From: Yoav Nir To: "'Richard L. Barnes'" Date: Tue, 17 May 2011 16:12:21 +0300 Thread-Topic: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) Thread-Index: AcwT0Hp2We4s/tl5TSKo62KATKnOsgAw1Pdw Message-ID: <006FEB08D9C6444AB014105C9AEB133F014D385F2063@il-ex01.ad.checkpoint.com> References: <4DCD61FA.10103@KingsMountain.com> <91F94E2D-114A-467D-8B38-04B341E739B1@vpnc.org> <5AAEBE3A-BF57-4DE4-AEC0-B8867CC2C593@bbn.com> In-Reply-To: <5AAEBE3A-BF57-4DE4-AEC0-B8867CC2C593@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02) 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, 17 May 2011 13:12:37 -0000 That would work for CAA, but you can't use the same record for the relying = party, and again you need to types of records. I don't think it makes much difference whether there is a CAA sub-type to t= he DANE type, or whether CAA is its own type.=20 -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 Sent: 16 May 2011 16:52 To: Yoav Nir Cc: Paul Wouters; Paul Hoffman; IETF DANE WG list Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf= -dane-use-cases-02) >> If it does become a dane use case, then like I suggested for the CAA=20 >> record, there should be a valid "null record" to state that no CA=20 >> should issue/be trusted. This would be to avoid people using "bogus" dat= a to accomplish the same. >=20 > If we're using the same record for CAs and applications, what would the n= ull record mean for applications? I think the better solution would be to just make up a cert/CA and lock to = that cert/CA, preventing any other cert/CA from validating. There's not a = need for a null record, just positive record pointing to something else. From warren@kumari.net Tue May 17 07:39:36 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A9DE06AD for ; Tue, 17 May 2011 07:39:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t7Bd8GhsZlE for ; Tue, 17 May 2011 07:39:35 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 42E48E0658 for ; Tue, 17 May 2011 07:39:35 -0700 (PDT) Received: from [172.19.118.214] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 4F9DD1B40423 for ; Tue, 17 May 2011 10:39:34 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Warren Kumari In-Reply-To: Date: Tue, 17 May 2011 10:39:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <05210994-45AC-4108-AEC4-DE7AFC972C21@kumari.net> References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <83BE20C5-6392-4581-864E-302941DBF862@kumari.net> To: dane@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 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, 17 May 2011 14:39:36 -0000 Hello all, Thank you all very much for your feedback, comments and (especially!) = text. Ondrej and I have discussed this and see good consensus for the = document. There were some good comments (and text) provided, and Richard = thinks that he will have some time in the next week or two to address / = incorporate them. We will then confirm that the revisions address the issues / concerns = raised and then ship it... W On May 13, 2011, at 5:59 PM, Warren Kumari wrote: > Thank you to everyone who provided comments, suggestions and = (especially!) proposed text. >=20 > WGLC is now closed, and my cochair and I will discuss the comments, = etc. (note to self: Don't end WGLC on a Friday :-P) >=20 >=20 > W >=20 >=20 > On May 13, 2011, at 1:45 PM, Christopher Morrow wrote: >=20 >> On Wed, May 4, 2011 at 1:55 AM, Christopher Morrow >> wrote: >>> On Sat, Apr 30, 2011 at 9:24 PM, Warren Kumari = wrote: >>>>=20 >>>> On Apr 29, 2011, at 12:03 PM, Warren Kumari wrote: >>>>=20 >>>>> Hi all, >>>>>=20 >>>>> I think that Richard has integrated most of the comments received = on-list into this most recent version of the doc and so, as I mentioned, = we are going to kick off WGLC... >>>>>=20 >>>>> Please get y'er comments in -- WGLC will be closing on 2011-05-13 = at 16:00UTC (noonish EDT). >>=20 >> oops, I forgot to say: "I support the doc, it'd be nice to see a >> re-spin if some of the more substantive comments need to be = included." >> -chris >>=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From pgut001@login01.cs.auckland.ac.nz Mon May 30 05:48:31 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02F2E07C0 for ; Mon, 30 May 2011 05:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pO7szO-ZWFG for ; Mon, 30 May 2011 05:48:29 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5807BE06F7 for ; Mon, 30 May 2011 05:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1306759709; x=1338295709; h=from:to:subject:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20dane@ietf.org|Subject:=20CAA:=20Isn't=20this=20com pletely=20backwards?|Message-Id:=20|Date:=20Tue,=2031=20May=202011 =2000:48:26=20+1200; bh=A1LRKp2nViK+nC1/0wxyRcJPbZSDijfhzdFbD1ZtFhQ=; b=nfT/gLtOyY5A/pj+aHUJih6NqnKPBT0xa8aP7olvAvNA1CXCQ+VPKbxv noO7u/Fq9cM7UQ962hdVu+3oAs3dV9I5p/0+qSiPNuzYQ8Wz29ZTh4eE4 fkIK4/bspHKvBkfGGHyrutn1q2/vFuRDpJrpi/0NYa38fktj7gzLVDWYZ o=; X-IronPort-AV: E=Sophos;i="4.65,290,1304251200"; d="scan'208";a="64554911" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 31 May 2011 00:48:26 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QR1tS-0001UD-GV for dane@ietf.org; Tue, 31 May 2011 00:48:26 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QR1tS-0004e5-2X for dane@ietf.org; Tue, 31 May 2011 00:48:26 +1200 From: Peter Gutmann To: dane@ietf.org Message-Id: Date: Tue, 31 May 2011 00:48:26 +1200 Subject: [dane] CAA: Isn't this completely backwards? 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, 30 May 2011 12:48:31 -0000 I had this queued up for posting a while back but it was the middle of the Comodo brouhaha so I thought it'd get lost in the noise, hopefully it's not too stale: When I first heard of CAA I thought it was great, a web site owner could indicate that only certificates from CA X should be trusted for their site: The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the certificate signing certificate(s) authorized to issue certificates for that domain. So to take a random fictitious example, if say a student in Iran got a CA to issue a cert saying they were Yahoo then the CAA entry in the DNS would indicate that only Digicert could issue a cert for Yahoo and it'd be rejected by the browser. Then I saw things like: Thus Relying Applications MUST NOT use failure to conform to currently published CAA records as a rejection criteria for certificates unless [...] OK, so that's not a good start. What's the intended use for this then? Let's see... Examples of Use. The following example informs CAs that certificates must not be issued except under [...] [DNS entry example] So the problem we have is that negligent CAs are issuing certs for domains that they shouldn't be. In other words we're trying to address the issue of CA negligence. The CAA "solution" though is even more prone to failure due to CA negligence then the existing way of doing things, if one single CA omits to check the CAA record then they'll go ahead and issue certs contrary to the CAA policy. So CAA seems to be operating in a completely backwards manner, instead of being a whitelist that relies only on the domain holder for security, it's a blacklist that replies on every single CA capable of issuing a cert to act diligently, the exact problem that (presumably) motivated CAA in the first place. (I know that CAA has all sorts of options to enable all sorts of things, I'm talking about the default, must-implement mode of operation here). What's wrong with a simple "hash-of-issuer-name" in the DNS? That's all it needs because you've now diversified your risk, the attacker has to compromise both the CA and the registrar for their attack to succeed. Peter. From fweimer@bfk.de Mon May 30 06:04:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A626EE0651 for ; Mon, 30 May 2011 06:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhB-8X85ylAw for ; Mon, 30 May 2011 06:04:51 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id A78D1E07BE for ; Mon, 30 May 2011 06:04:50 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QR29H-0005jS-1h; Mon, 30 May 2011 13:04:47 +0000 Received: by bfk.de with local id 1QR29G-0007G5-SU; Mon, 30 May 2011 13:04:46 +0000 From: Florian Weimer To: Peter Gutmann References: Date: Mon, 30 May 2011 13:04:46 +0000 In-Reply-To: (Peter Gutmann's message of "Tue, 31 May 2011 00:48:26 +1200") Message-ID: <828vtotk41.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] CAA: Isn't this completely backwards? 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, 30 May 2011 13:04:52 -0000 * Peter Gutmann: > What's wrong with a simple "hash-of-issuer-name" in the DNS? I think the attacker could still create a malicious sub-CA with the expected issuer name. Hashing the whole set of certificates delivered over TLS would probably work, but this ties your DNS pretty closely to what your TLS servers are doing. Relying on CAA to check the CA certificate, in turn, does not work because issuer DNs are not validated by the current browser PKI and are mostly garbage. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From pgut001@login01.cs.auckland.ac.nz Mon May 30 06:19:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85684E07CF for ; Mon, 30 May 2011 06:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyWehfSZ6g-k for ; Mon, 30 May 2011 06:19:44 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6E661E07C9 for ; Mon, 30 May 2011 06:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1306761585; x=1338297585; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20fweimer@bfk.de,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[dane]=20CAA:=20Isn't=20this=20complete ly=20backwards?|Cc:=20dane@ietf.org|In-Reply-To:=20<828vt otk41.fsf@mid.bfk.de>|Message-Id:=20|Date:=20Tue,=2031=20May=202011 =2001:19:41=20+1200; bh=fo7s9sDG0+fT7YteHlyZPA69q9QiSEjmtwi8+YbG1e4=; b=ZO4pn4KOfT2lR4ZhCTNbMlNgmCR7O36pkmVDgcyQHn2CaDKnApe4S/Im kKjFnbfeVwcfEFVSBZkP2N6X5p1L+1AiUMvdAfVy58/VW2NwJK1M5/n+r WbAXKEmbDAINCRYJFrI8HU44sUbvMWtPg5PSpDGn3zxxVqpiKJn2fgQBI c=; X-IronPort-AV: E=Sophos;i="4.65,290,1304251200"; d="scan'208";a="64556833" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 31 May 2011 01:19:42 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QR2Nh-0002OO-I1; Tue, 31 May 2011 01:19:41 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QR2Nh-0005tM-HV; Tue, 31 May 2011 01:19:41 +1200 From: Peter Gutmann To: fweimer@bfk.de, pgut001@cs.auckland.ac.nz In-Reply-To: <828vtotk41.fsf@mid.bfk.de> Message-Id: Date: Tue, 31 May 2011 01:19:41 +1200 Cc: dane@ietf.org Subject: Re: [dane] CAA: Isn't this completely backwards? 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, 30 May 2011 13:19:45 -0000 Florian Weimer writes: >* Peter Gutmann: >> What's wrong with a simple "hash-of-issuer-name" in the DNS? > >I think the attacker could still create a malicious sub-CA with the expected >issuer name. Sure, but this isn't meant to be a buletproof solution, just something to make an attacker's job a bit harder than the current method of going to a CA and saying "gimme a cert". All you have to do is make it at least as secure as the current weakest link, which is forging a request to the registrar to change the DNS entry (and that's a pretty low barrier for your $9.95 registrar). Peter. From hallam@gmail.com Mon May 30 16:26:58 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2C7E075B for ; Mon, 30 May 2011 16:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKXKauno4V4L for ; Mon, 30 May 2011 16:26:57 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 891EFE075A for ; Mon, 30 May 2011 16:26:57 -0700 (PDT) Received: by gwb20 with SMTP id 20so2205956gwb.31 for ; Mon, 30 May 2011 16:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tg9/M9xyXiXJN8wyaUCnrjymObm9/jhWHFMmgLTGyhw=; b=lRd/XG1vSiahR/wKjCuL7acJ642lOVTupUphYw8s7FJxzbRe+78rdTwvus1muVp2Fc Oli8iiGQ/phxrCNRaX6RAZox3fxiDrA7dAXXOJNjF3cSD8vFyAqxolPBZIhiUiH6ByHf lHQZ20lqk8U6VqeekvyYY/q2xMvMsdPYC9k8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kvFKIU6DJJ0jLf145EEBOI5Zx5Ww9KDWMjIg5U821VfKe82caX5pLlD+vvANr7c/ih MznUB/UefOF6mQ/2ALDujhPexVrUNDLNd8bIRHGicHdmwM9kwIRE6pAX2oHSs2SWM5wR uSvMmnTQJhDSWrpmfaGfvzPOb2frwbFhU7oGI= MIME-Version: 1.0 Received: by 10.100.40.19 with SMTP id n19mr3358406ann.62.1306798015733; Mon, 30 May 2011 16:26:55 -0700 (PDT) Received: by 10.101.36.13 with HTTP; Mon, 30 May 2011 16:26:55 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 May 2011 19:26:55 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=0016e64607e685601904a4869f8b Cc: dane@ietf.org Subject: Re: [dane] CAA: Isn't this completely backwards? 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, 30 May 2011 23:26:59 -0000 --0016e64607e685601904a4869f8b Content-Type: text/plain; charset=ISO-8859-1 Peter, The problem is that for the larger sites it is not that easy to determine how many Web servers are in the domain in the first place. Thus it is necessary to allow the publisher of the CAA record to work in stages IF NECESSARY. First shutting down issue by non-authorized CAs, then after assuring themselves that there will be no unanticipated effects publishing records that enable client enforcement. If you have a small site with a handful of servers then you can go straight from issue restrictions to relying application restrictions. But its still not quite a direct mapping because the information needed for relying party applications has to be actionable without additional out of context information. So for that approach you really need to be using the path directive rather than the policy directive. And if the issuing side of the scheme is working, you should not need the client enforcement at all. As with DNSSEC any failure to validate is going to be much more likely to be the result of misconfiguration than an attack. So planning a response is quite difficult. On Mon, May 30, 2011 at 8:48 AM, Peter Gutmann wrote: > I had this queued up for posting a while back but it was the middle of the > Comodo brouhaha so I thought it'd get lost in the noise, hopefully it's not > too stale: > > When I first heard of CAA I thought it was great, a web site owner could > indicate that only certificates from CA X should be trusted for their site: > > The Certification Authority Authorization (CAA) DNS Resource Record allows > a > DNS domain name holder to specify the certificate signing certificate(s) > authorized to issue certificates for that domain. > > So to take a random fictitious example, if say a student in Iran got a CA > to > issue a cert saying they were Yahoo then the CAA entry in the DNS would > indicate that only Digicert could issue a cert for Yahoo and it'd be > rejected > by the browser. > > Then I saw things like: > > Thus Relying Applications MUST NOT use failure to conform to currently > published CAA records as a rejection criteria for certificates unless > [...] > > OK, so that's not a good start. What's the intended use for this then? > Let's > see... > > Examples of Use. > > The following example informs CAs that certificates must not be issued > except under [...] > > [DNS entry example] > > So the problem we have is that negligent CAs are issuing certs for domains > that they shouldn't be. In other words we're trying to address the issue > of > CA negligence. The CAA "solution" though is even more prone to failure due > to > CA negligence then the existing way of doing things, if one single CA omits > to > check the CAA record then they'll go ahead and issue certs contrary to the > CAA > policy. > > So CAA seems to be operating in a completely backwards manner, instead of > being a whitelist that relies only on the domain holder for security, it's > a > blacklist that replies on every single CA capable of issuing a cert to act > diligently, the exact problem that (presumably) motivated CAA in the first > place. > > (I know that CAA has all sorts of options to enable all sorts of things, > I'm > talking about the default, must-implement mode of operation here). > > What's wrong with a simple "hash-of-issuer-name" in the DNS? That's all it > needs because you've now diversified your risk, the attacker has to > compromise > both the CA and the registrar for their attack to succeed. > > Peter. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --0016e64607e685601904a4869f8b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Peter,

The problem is that for the larger sites it is no= t that easy to determine how many Web servers are in the domain in the firs= t place.

Thus it is necessary to allow the publish= er of the CAA record to work in stages IF NECESSARY. First shutting down is= sue by non-authorized CAs, then after assuring themselves that there will b= e no unanticipated effects publishing records that enable client enforcemen= t.

If you have a small site with a handful of servers then= you can go straight from issue restrictions to relying application restric= tions.


But its still not quite a di= rect mapping because the information needed for relying party applications = has to be actionable without additional out of context information. So for = that approach you really need to be using the path directive rather than th= e policy directive.

And if the issuing side of the scheme is working, you s= hould not need the client enforcement at all. As with DNSSEC any failure to= validate is going to be much more likely to be the result of misconfigurat= ion than an attack. So planning a response is quite difficult.


On Mon, May 30, 2011 at 8:48 AM, Pe= ter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
I had this queued up for posting a while back but it was the middle of the<= br> Comodo brouhaha so I thought it'd get lost in the noise, hopefully it&#= 39;s not
too stale:

When I first heard of CAA I thought it was great, a web site owner could indicate that only certificates from CA X should be trusted for their site:=

=A0The Certification Authority Authorization (CAA) DNS Resource Record all= ows a
=A0DNS domain name holder to specify the certificate signing certificate(s= )
=A0authorized to issue certificates for that domain.

So to take a random fictitious example, if say a student in Iran got a CA t= o
issue a cert saying they were Yahoo then the CAA entry in the DNS would
indicate that only Digicert could issue a cert for Yahoo and it'd be re= jected
by the browser.

Then I saw things like:

=A0Thus Relying Applications MUST NOT use failure to conform to currently<= br> =A0published CAA records as a rejection criteria for certificates unless [= ...]

OK, so that's not a good start. =A0What's the intended use for this= then? =A0Let's
see...

=A0Examples of Use.

=A0The following example informs CAs that certificates must not be issued<= br> =A0except under [...]

=A0[DNS entry example]

So the problem we have is that negligent CAs are issuing certs for domains<= br> that they shouldn't be. =A0In other words we're trying to address t= he issue of
CA negligence. =A0The CAA "solution" though is even more prone to= failure due to
CA negligence then the existing way of doing things, if one single CA omits= to
check the CAA record then they'll go ahead and issue certs contrary to = the CAA
policy.

So CAA seems to be operating in a completely backwards manner, instead of being a whitelist that relies only on the domain holder for security, it= 9;s a
blacklist that replies on every single CA capable of issuing a cert to act<= br> diligently, the exact problem that (presumably) motivated CAA in the first<= br> place.

(I know that CAA has all sorts of options to enable all sorts of things, I&= #39;m
talking about the default, must-implement mode of operation here).

What's wrong with a simple "hash-of-issuer-name" in the DNS? = =A0That's all it
needs because you've now diversified your risk, the attacker has to com= promise
both the CA and the registrar for their attack to succeed.

Peter.

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



--
Website: http://hallambaker.com/

--0016e64607e685601904a4869f8b--